So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?
No opaque data leaves my network
Then this is the only way you can have outbound HTTPS connections. And for e.g. a bank, certain legal firms, or any company that has a lot of sensitive data they either don't want to be leaked, or at least want the option of detecting when it is leaked, that is a somewhat reasonable stance. In the case of banks, this is needed for regulatory compliance regarding insider trading. For legal companies, I imagine this is about ensuring certain confidentiality. I could see the same thing for companies dealing with trade-secrets.
The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them.
This method is considered better than terminating TLS early at a proxy and setting up a separate tunnel to the clients because breaking PFS is passive, rather than active. Thus it is a lot less resource intensive, a lot less vulnerable (no internet facing box that, if broken, has all communication in plaintext), and introduces no extra latency.
It is essentially a 'better' way to do an authorized MitM on everything on your network, and some companies want this authorized MitM. Like any authorized MitM, it introduces a third party who can compromise security, which is not generally desirable, but some companies don't mind being that third party to their own employees.
> The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them.
There still has to be some control over the endpoints. Otherwise, what prevents them from negotiating an algorithm in TLS 1.2 that has PFS?
And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there? (So, it is still encrypted internally, but the node can inspect the data in an authorized manner.) (You seem to address it, but I'm not sure what you mean: yeah, having a centralized box decrypting your traffic means that an attacker that gets access to that can see a lot. But what were you doing in TLS 1.2 w/ a non-PFS ciphersuite that didn't involve a machine w/ the ability to decrypt everything?)
When you have communication between two endpoints, over your own network, transmitting session keys OoB doesn't improve the security of your systems, but does increase the complexity.
> And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there?
Aside from adding a ton of latency and extra performance overhead, you now have a new operational endpoint that you have to trust. That doesn't fit the trust model. They key point here is the data is getting logged and then decrypted offline, by a totally separate system.
Having PFS increases security for your end users. (Minus your storing of the session keys, of course; if whatever you need the session keys for doesn't require you to store them forever, then it still seems like a benefit.) Being able to use standard, well-audited libraries instead of a proprietary piece of "enterprise" code is a benefit.
> Aside from adding a ton of latency and extra performance overhead
The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware.
> you now have a new operational endpoint that you have to trust
No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.)
If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.
The context of ETS/eTLS is that you yourself are the end user.
> The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware.
Uh-huh. I like that you believe that, but with a lot of HFT systems, even the latency of going from the NIC to the CPU is too much. Adding a hop in between that decodes and then reencodes, the the inherent buffering involved, is way, way too much latency.
> No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.) > > If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.
Yeah... see, that's the part you aren't getting. The old model was also not terminating through a proxy with TLS 1.2. That actually doesn't address the needs of the trusted system.
If your stance is ‘no opaque data leaves my network’ your only option is an air gap.
If nothing else, it would make the remaining traffic stand out more since you wouldn't be spending time auditing normal apps which decode cleanly and it's highly likely that someone trying to circumvent such a system would be required to do things which stand out more than routine usage.
As a simple example, an organization which does that kind of monitoring is unlikely to allow users to install arbitrary applications or visit any site on the web. With a standard setup, someone trying to exfiltrate data could just hit a popular site like Github, Gmail, Dropbox, etc. but if they need to use some custom encryption or steganography code they're either forced to install it somewhere far less common (i.e. more likely to stand out) or installing something locally where client monitoring can report an unusual browser extension or application.
The reality is that world kept turning without these proxies and it will keep turning once they are made obsolete.
There are people who need to check off boxes in order to comply with certain rules. Their security reality is not actually all that important.
ETS just means they don't have to spend money on replacing their man-in-the-middle monitoring gear with client-local solutions on every workstation and server.
It al seems pretty silly though. Regulators aren't idiots; they know that HTTPS is everywhere now, and that TLS 1.3 means that third parties listening in on connections are going to be thing of the past, so the regulations will change to reflect that.
Doesn't it still require altering the TLS implementation to use the static DH keys instead of following the TLS 1.3 standard of using random keys?
This expands to any IoT device with proprietary software on it, which by 2023 will be quite a lot of things.
The point is to have the decryption done on a system that is isolated from the production environment (and is consequently isolated from security compromises).
And if you are in a corporate environment using a company computer you forfeit your privacy anyway. You can always go somewhere else or do your banking and Facebook on a different machine / not on company time.
The issue is that TLS 1.3 deprecates the key exchange that makes this possible, essentially making (perfect) forward secrecy a requirement since the only inlcuded ciphers do so. The only way to monitor/inspect TLS traffic in this situation is to MITM the traffic rather than simply record encrypted sessions.
If you want to compromise the endpoint, compromise the endpoint. Install your own MITM certificates and terminate the connection in the middle, or install client-side malware. Either way, there should always be a giant warning sign on the client that end-to-end security is compromised.
The assumptions that TLS 1.3 is based around are in direct conflict with the requirements of the secure environment they operate in.
This isn't some evil thing... a cryptographic protocol is a part of a trusted system, and whether it is appropriate for a particular context has to do with the design of the trusted system.
Disabling PFS and thus enabling the decryption of all TLS sessions should be a conscious decision rather than something that was there 'by default' (and could easily be abused).
You can cover some of the same concern by implementing an agent on every connected computing device but this brings much greater complexity as you are monitoring potentially hundreds to thousands more places and still have to worry if you have complete coverage.
Consider an analogy of going through international customs. Do you employ customs officials at the border who are allowed to sample and inspect private belongings to verify laws are being followed? Or do you employ an official to help pack the belongings of each individual who you think may eventually cross the border? The second example is a bit stretched but hopefully illustrates the scale problem.
Without telling the person who's things were packed that they were packed by the official.
Adobe Creative Cloud
Amazon Work Spaces
Docusign
GitHub
Google Drive
GoToMeeting
iCloud
Microsoft Office 365 Outlook.com
Microsoft Skype for Business
Salesforce.com
I'm a bit surprised by Skype for Business (horrible product BTW, it's a gamble to even be able to sign in on a fresh install) though, the rest I would expect people to use web versions of.
I would think that (perhaps coincidentally), the organizations that require these kinds of insights are not the ones that are relying on services that do cert pinning. And if they do, they can but the marketing department/the server running THAT wonky old software from the 90s in a separate subnet.