7 ms·

ETS protocol does not provide per-session forward secrecy

65 points by jfreax 8y ago

chupa-chups 8y ago
Hilarious :)
sschueller 8y ago
Just remember, if it has the extra word "Enterprise" in it, it's probably an insecure, convoluted, undocumented, slow, etc. version of the original...
Nextgrid 8y ago
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.
- gruez 8y ago
  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.
  - ratling 8y ago
    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.
    - gruez 8y ago
      >(hashed, limited to the last n connections)
kabwj 8y ago
Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.
- Nextgrid 8y ago
  From what I can see this protocol is compatible with TLS 1.3 clients. It makes clients believe perfect forward secrecy is in effect while in fact it isn’t. The risk isn’t much about internal networks, it’s when this starts leaking onto the open internet. Also the fact they call themselves “eTLS” to use TLS’ reputation when actually it’s a voluntarily degraded version of TLS.
  - kabwj 8y ago
    There’s no way to guarantee forward secrecy to a client. If regular TLS promises that, the committee is lying and they know it.
    - zrm 8y ago
      There are constructions that provide forward secrecy when both the client and server follow them. This is what TLS aims to provide. If the server doesn't faithfully implement the protocol, of course it will not provide the expected security guarantees. But then it isn't the committee who is lying, it's the server by claiming to implement TLS and then not.
      - zaroth 8y ago
        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)
        Dylan16807 8y ago
        Sure, if you want to pretend that an easily-fixed bug makes security a myth.
leiroigh 8y ago
I don't get the complaints. As far as I understood (and ietf appears to agree), eTLS is not a protocol, it is a (server-side) implementation variant of TLS. And it is a universal construction: For any cryptographic protocol, one party can replace its random number generator by a deterministic CSPRNG and store or leak seeds. This is undetectable from outside. There you go, backdoor for later reversal of forward secrecy: Forward secrecy is obtained in the moment you erase from memory the internal state of your CSPRNG, and the server can just not do that, without violating any protocol assumptions. Specifying how to implement this in practice is worthwhile; it is not a weakening or violation of TLS, instead it is an interesting description of inherent properties of TLS. The naming (eTLS) might be unfortunate. Better to just make it an RFC on "Cryptographic backdoors for TLS".
- deleted 8y ago
  [deleted]
dogma1138 8y ago
This is hilarious for the sheer irony of a fix to one compliance issue creating a different compliance issue.
galadran 8y ago
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 is no longer enough, you have to share a secret for every session. This necessitates some kind of software running on each endpoint to transmit these secrets. But wait, the moment you have to have software running on every endpoint, why do you need a special box? Why not do it all in software? This represents a huge threat to the DPI market. No box means no lock in, no mandatory upgrades, no support contracts. Sure, software can have these things too, but it's inherently a more open, competitive market where you are vulnerable to open source invasion. Solutions like eTLS are just a last ditch gnashing of teeth from DPI box sellers, trying to prevent a lucrative market from disappearing. Once you move everything to software: a) competition in general gets better and b) open source starts to take over, c) security will improve.
- natch 8y ago
  Had to duckgo it: DPI = deep packet inspection.
- warkdarrior 8y ago
  From a security perspective, it is better to have the endpoints just share the session secret with a DPI box, instead of running the DPI software on the endpoint. If the endpoint in compromised, in the first scenario, the most the attacker can do it not share the session secret. This is easily detectable. In the second scenario, the attacker can pretend that the endpoint-local DPI software is still being run, while completely going around it.
  - galadran 8y ago
    Sorry if my point wasn't clear. I do mean that there should be DPI software running somewhere external, the point is just that you don't need dedicated hardware to do it. I completely agree doing everything on the endpoint isn't going to end well.
jaclaz 8y ago
The EFF article is actually interesting: https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s... previous discussion: https://news.ycombinator.com/item?id=19255227 https://news.ycombinator.com/item?id=19255227
ratling 8y ago
LOL they changed the name again. This is eTLS (aka not actually TLS but lets jump on the name).

65 points by jfreax 8y ago

Hilarious :)

Just remember, if it has the extra word "Enterprise" in it, it's probably an insecure, convoluted, undocumented, slow, etc. version of the original...

Nextgrid 8y ago

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.

gruez 8y ago
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.
- ratling 8y ago
  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.
  - gruez 8y ago
    >(hashed, limited to the last n connections)

kabwj 8y ago

Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.

Nextgrid 8y ago
From what I can see this protocol is compatible with TLS 1.3 clients. It makes clients believe perfect forward secrecy is in effect while in fact it isn’t. The risk isn’t much about internal networks, it’s when this starts leaking onto the open internet. Also the fact they call themselves “eTLS” to use TLS’ reputation when actually it’s a voluntarily degraded version of TLS.
- kabwj 8y ago
  There’s no way to guarantee forward secrecy to a client. If regular TLS promises that, the committee is lying and they know it.
  - zrm 8y ago
    There are constructions that provide forward secrecy when both the client and server follow them. This is what TLS aims to provide. If the server doesn't faithfully implement the protocol, of course it will not provide the expected security guarantees. But then it isn't the committee who is lying, it's the server by claiming to implement TLS and then not.
    - zaroth 8y ago
      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)
      - Dylan16807 8y ago
        Sure, if you want to pretend that an easily-fixed bug makes security a myth.

leiroigh 8y ago

I don't get the complaints. As far as I understood (and ietf appears to agree), eTLS is not a protocol, it is a (server-side) implementation variant of TLS. And it is a universal construction: For any cryptographic protocol, one party can replace its random number generator by a deterministic CSPRNG and store or leak seeds. This is undetectable from outside. There you go, backdoor for later reversal of forward secrecy: Forward secrecy is obtained in the moment you erase from memory the internal state of your CSPRNG, and the server can just not do that, without violating any protocol assumptions. Specifying how to implement this in practice is worthwhile; it is not a weakening or violation of TLS, instead it is an interesting description of inherent properties of TLS. The naming (eTLS) might be unfortunate. Better to just make it an RFC on "Cryptographic backdoors for TLS".

deleted 8y ago
[deleted]

dogma1138 8y ago

This is hilarious for the sheer irony of a fix to one compliance issue creating a different compliance issue.

galadran 8y ago

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 is no longer enough, you have to share a secret for every session. This necessitates some kind of software running on each endpoint to transmit these secrets. But wait, the moment you have to have software running on every endpoint, why do you need a special box? Why not do it all in software? This represents a huge threat to the DPI market. No box means no lock in, no mandatory upgrades, no support contracts. Sure, software can have these things too, but it's inherently a more open, competitive market where you are vulnerable to open source invasion. Solutions like eTLS are just a last ditch gnashing of teeth from DPI box sellers, trying to prevent a lucrative market from disappearing. Once you move everything to software: a) competition in general gets better and b) open source starts to take over, c) security will improve.

natch 8y ago
Had to duckgo it: DPI = deep packet inspection.
warkdarrior 8y ago
From a security perspective, it is better to have the endpoints just share the session secret with a DPI box, instead of running the DPI software on the endpoint. If the endpoint in compromised, in the first scenario, the most the attacker can do it not share the session secret. This is easily detectable. In the second scenario, the attacker can pretend that the endpoint-local DPI software is still being run, while completely going around it.
- galadran 8y ago
  Sorry if my point wasn't clear. I do mean that there should be DPI software running somewhere external, the point is just that you don't need dedicated hardware to do it. I completely agree doing everything on the endpoint isn't going to end well.

jaclaz 8y ago

The EFF article is actually interesting: https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s... previous discussion: https://news.ycombinator.com/item?id=19255227 https://news.ycombinator.com/item?id=19255227

ratling 8y ago

LOL they changed the name again. This is eTLS (aka not actually TLS but lets jump on the name).