Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ETS protocol does not provide per-session forward secrecy

nvd.nist.gov

Post reply on HN
Print view View original

31–39 of 39 posts

Re: ETS protocol does not provide per-session forward secrecy

#31

Post by rocqua »

galadran wrote: post #26
rocqua wrote: post #21

Earlier quoted context omitted.

> These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this is no longer enough, you have to share a secret for every session. Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and…

> Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and it doesn't introduce extra latency. Moreover, this system allows for post-hoc DPI rather than requiring that it happens on-line. Great point! As you say, it scales much worse and introduces additional points of failure though. > There ar…

> Absolutely true, but this does lead to a qualititve advantage for open standard / open source solutions where you externalise the costs of additional implementations.

This subject doesn't seem like the most attractive for open-source solutions. Especially when it comes to supporting legacy enterprise systems. This feels more like a case of a consortium of companies creating a standards body.

> looking at the deployment issues middlesboxes have caused for TLS1.3 and QUIC (snip) My point is that software is much cheaper and more flexible (in the long run) than hardware.

I don't think middle-boxes as ETS intends them need hardware acceleration. As such, they could just as easily be implemented in software. This would give the same software-flexibility as modifying endpoints, with the advantage of only needing to support a few systems in your network rather than every single one.

I'd expect the same ossification and bad behavior in software middleboxes as we have had so far. But honestly, I see the same thing happening by supporting this on the end-points.

I'd summarize my position as follows:

If we want to support inspection of traffic by network owners, I see real advantages to selectively breaking forward secrecy for them. But that is a big if. We might be better off just telling those network owners to suck it up and MitM everything.

Re: ETS protocol does not provide per-session forward secrecy

#33

Post by ratling »

gruez wrote: post #11
Nextgrid wrote: post #4

As far as I understand this garbage protocol is designed to be compatible with TLS 1.3 clients. Can clients detect the use of this, and if detected refuse to connect with a scary warning? That should kill this abomination fairly effectively.

Afaik the protocol is merely TLS 1.3 with fixed DH parameters. In that case it's pretty easy to detect: keep a client side list of DH parameters used by servers (hashed, limited to the last n connections), and terminate any connections that shows reuse.

You're essentially losing PFS if you do this, since those keys are now available. This would work, though it would probably have to be at the application level.

Re: ETS protocol does not provide per-session forward secrecy

#34

Post by dogma1138 »

stefan_ wrote: post #30
dogma1138 wrote: post #28

Earlier quoted context omitted.

Decrypting traffic on the client isn’t always possible due to how modern browsers operate. Decrypting traffic on clients is also much harder due to the multiple types of clients you have and the fact that there is no easy way to MITM every connection the the client. The security threat model by definition defines clients as untrustworthy hence relying on them for decryption is a flawed approach. If you are going to b…

You control the client. There are companies making many many millions patching Excel to do fancier charts , I'm sure whatever vendor you got now desperately trying to steer the consortiums can instead figure out how to hook the crypto library in the one browser you install on clients. Yeah, it's a hard problem. If you don't know half the things your clients are doing, it's much easier to pretend all the security cons…

Again you do not trust your clients in this threat model because you can’t.

It’s simple a client makes an external TCP connection if that connection uses TLS the its MITMed on the network level and captured this happens to all connections if the client does not accept the handshake because for example the CA for the MITM box isn’t trusted or the client uses certificate pinning the client can simply refuse to proceed with the connection.

If the connection cannot be captured and inspected for any reason it’s simply terminated and the attempt is logged for future investigation.

There is no reason to break TLS on the client or compromise the browser it’s worse in every way and cannot be trusted.

Re: ETS protocol does not provide per-session forward secrecy

#35

Post by zaroth »

Dylan16807 wrote: post #25
zaroth wrote: post #23

Earlier quoted context omitted.

Forward secrecy is mostly a myth anyway when the “ephemeral” keys used to generate the session are kept in memory for weeks, months, or years already (e.g. HAProxy)

Sure, if you want to pretend that an easily-fixed bug makes security a myth.

It doesn't matter how easy the bug is to fix, if 90 out of 100 sites don't fix it. In this case it's less of a bug than it is a thorn, because rotating the keys requires knowing when they can actually expire, which requires state that the process holding the keys usually doesn't carry.

But my point was more along the lines that PFS was never a guaranteed contract with the client, only a possibility offered by certain key exchange protocols, and even then, easy enough to get wrong that most people did.

Re: ETS protocol does not provide per-session forward secrecy

#36

Post by unparagoned »

stefan_ wrote: post #30
dogma1138 wrote: post #28

Earlier quoted context omitted.

Decrypting traffic on the client isn’t always possible due to how modern browsers operate. Decrypting traffic on clients is also much harder due to the multiple types of clients you have and the fact that there is no easy way to MITM every connection the the client. The security threat model by definition defines clients as untrustworthy hence relying on them for decryption is a flawed approach. If you are going to b…

You control the client. There are companies making many many millions patching Excel to do fancier charts , I'm sure whatever vendor you got now desperately trying to steer the consortiums can instead figure out how to hook the crypto library in the one browser you install on clients. Yeah, it's a hard problem. If you don't know half the things your clients are doing, it's much easier to pretend all the security cons…

If this was back in the days I'd everyone running ie maybe. But now they're is less control over clients and their browsers. Mitm is much easier, toy just install a certificate on the browser. Going client side means you need to change and modify every browser and piece of software with internet access. Or install some slow crappy firewall type thing and try and monitor things locally....

Re: ETS protocol does not provide per-session forward secrecy

#37

Post by gruez »

ratling wrote: post #33
gruez wrote: post #11

Earlier quoted context omitted.

Afaik the protocol is merely TLS 1.3 with fixed DH parameters. In that case it's pretty easy to detect: keep a client side list of DH parameters used by servers (hashed, limited to the last n connections), and terminate any connections that shows reuse.

You're essentially losing PFS if you do this, since those keys are now available. This would work, though it would probably have to be at the application level.

>(hashed, limited to the last n connections)

Re: ETS protocol does not provide per-session forward secrecy

#38

Post by watersb »

galadran wrote: post #16

The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey. These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this…

DPI = Deep Packet Inspection

Re: ETS protocol does not provide per-session forward secrecy

#39

Post by tastroder »

dogma1138 wrote: post #14
tastroder wrote: post #7

Earlier quoted context omitted.

Why wouldn't they? That group is trying to standardize a protocol that effectively negates a whole lot of progress and even tried to piggy back on the TLS name. Their stated requirements boil down to snake oil and laziness. If companies or groups thereof want to use security measures that aren't on par with the state of the art and intentionally ignore recent learnings, they of course still have that capability but I…

Because companies in some sectors are required by law to inspect all traffic, while TLS 1.3 doesn’t prevent it in principle it makes it unfeasible to do so in practice given the number of sessions created in a large organization. I work for such organization which actually took a fairly reasonable stance and told BOA to piss off when they asked us to join them in petitioning the IETF to make exemptions to PFS in TLS…

Cool, doesn't really sound like we're disagreeing on the question "Why do people hate eTLS?" right? I sincerely hope regulation for your sector will change to reflect changing technical circumstances (though I realize how much of a long process that'd be). Your steps sound like a sane way to handle it, I get that you're currently forced to not use it and appreciate that you motion against weakening the protocol for the rest of the world. (Thanks for that btw.)
Post reply on HN