Hacker News Reader

Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.)

> 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?)

> Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.)

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.

> doesn't improve the security of your systems

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.

> Having PFS increases security for your end users.

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.

Not to mention that you have to trust the endpoint to ship their session keys. If one "forgets" or the key is "lost in the mail", there's no way to prove that message wasn't problematic.

Assume that non-PFS ciphersuites had remained in TLS: You still have to trust the endpoint to not negotiate a PFS ciphersuite.

Yes, but a failure to do so would be considered a compromise, as opposed to a simple network failure.

It’s a pipe dream. The webpage or application can easily include its own encryption that can’t be broken by these proxies.

If your stance is ‘no opaque data leaves my network’ your only option is an air gap.

Engineering is all about making trade-offs (“perfect is the enemy of the good and all”) and security engineering is no different. The same logic could be used to say that you don't need an edge firewall because each client should have one but it's much easier to simplify the baseline.

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.

A cute excuse until one of your popular sites starts to do this. Now it happens to be that Google hates these proxies as they are a popular target for repressive governments, who technically can’t be distinguished from a snooping ‘enterprise’.

The reality is that world kept turning without these proxies and it will keep turning once they are made obsolete.

It's not a pipe dream if your only goal is to be compliant with a formal rule or regulatory structure that requires it. The reason we need stuff like ETS is really because there are organizations that otherwise could not allow any outbound HTTPS sessions.

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.

They control the devices on their side of the firewall, so they can log whatever they want before the data sent enters the encrypted tunnel, and after the data received exits it.

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.

> 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.

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?

You can ban the use of such applications a lot easier than you can ban HTTPS. This means that simply using those tools is grounds for legal action, which might suffice. Especially if the concern for confidentiality is not for internal reasons, but for legal reasons.

It's not just companies that want to MitM their traffic: consumers want this too. Otherwise all the IoT devices in a house will no longer be trustable: Alexa can start uploading everything it hears, even if you never said "hey alexa!". And because of forward secrecy, you can't verify what it did or did not send: it all looks the same.

This expands to any IoT device with proprietary software on it, which by 2023 will be quite a lot of things.