3 ms·

Data Center Use of Static Diffie-Hellman in TLS 1.3

35 points by based2 10y ago

sigjuice 10y ago
... eliminating the Perfect Forward Secrecy .... Seems irresponsible to a layman like me.
- phicoh 10y ago
  There are many ways to achieve the same effect. The most obvious is to install the private key of the service on the middle box and terminate the TLS connection there. More complex is to log the DH private key that is used and make that available to the middle box. And as last resort, the server can just send all plain text to the middle box. There is no such thing as one-size-fits-all security. The important thing of course, is to make sure that such a feature cannot be turned on accidentally. I don't know about EC, but in classical DH, if the server uses the same DH private key for all connections, then a client can detect that (by initiating multiple connections). So a paranoid client library can issue a warning.
abrodersen 10y ago
Browser vendors should show a security warning when encountering this behavior. Default configurations of all software must be to disallow. The burden should be on the enterprise to configure their client devices to allow MITM.
- atonse 10y ago
  This theoretically seems like a good way to alert users, but what exactly would you even tell users? Most users barely understand past "make sure the padlock is there" – and many more technical users that I've observed don't even understand SSL warnings apart from "it's still SSL, make the warning go away" – so, showing a prompt about something even more obscure like static key exchange, will be lost on all but the most advanced security people. There are already plenty of ways for enterprises to get around this, like having their own CA and deploying that as a trusted CA to their machines. Then they can issue certs that their proxies could use, and their machines would just trust those certs. Why don't they just use that method?
  - infogulch 10y ago
    The same thing you do with any other invalid configuration like SHA1 or expired certificates. Show a warning and a big red x through the padlock.
- cesarb 10y ago
  "The enterprise" already controls the servers (otherwise, they wouldn't be able to configure a static ECDH key on them). Having control of the servers is already equivalent to having full access to the plain text. This only enlarges the security boundary from the server to every machine which could possibly, now or in the future, have access to that static ECDH key. And the default would still be to use a dynamic ECDH key. Also, how would a browser know it has encountered this behavior? A key might be rotated every few minutes, so just seeing the same key twice is not enough; and the key could be derived from a static key and the TLS nonces, so seeing a different key also means nothing. That said, I think server vendors should not implement this option. It's too risky, since it could be enabled by accident, incompetence, or malice. It's better to force the few who believe they really need this option to implement it themselves.
cesarb 10y ago
The background is probably this email thread: https://www.ietf.org/mail-archive/web/tls/current/msg21278.html https://www.ietf.org/mail-archive/web/tls/current/msg21278.h... Previous discussion of that email thread: https://news.ycombinator.com/item?id=12641880 https://news.ycombinator.com/item?id=12641880 Basically, someone noticed (too late) that TLS 1.3 no longer has the RSA key exchange, which they liked because it allowed decryption of the encrypted traffic by passive middleboxes (which have a copy of the RSA private key). This draft is probably a response to that.
vorpalhex 10y ago
This is concerning. While TLS interception may be desirable by some, this is a dangerous precedent and I hope the de facto standard for all software will be to block and disallow this kind of behavior, and warn when it's been enabled ("This connection is not fully secure").
nickik 10y ago
I just saw a talk at 33C3 about TLS 1.3 and they tell the story behind this alternative TLS 1.3. Its a pretty fun talk. https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...
justaaron 10y ago
sounds so complex that I'm in diffie hell, man! *sorry, couldn't resist :D

35 points by based2 10y ago

sigjuice 10y ago

... eliminating the Perfect Forward Secrecy .... Seems irresponsible to a layman like me.

phicoh 10y ago
There are many ways to achieve the same effect. The most obvious is to install the private key of the service on the middle box and terminate the TLS connection there. More complex is to log the DH private key that is used and make that available to the middle box. And as last resort, the server can just send all plain text to the middle box. There is no such thing as one-size-fits-all security. The important thing of course, is to make sure that such a feature cannot be turned on accidentally. I don't know about EC, but in classical DH, if the server uses the same DH private key for all connections, then a client can detect that (by initiating multiple connections). So a paranoid client library can issue a warning.

abrodersen 10y ago

Browser vendors should show a security warning when encountering this behavior. Default configurations of all software must be to disallow. The burden should be on the enterprise to configure their client devices to allow MITM.

atonse 10y ago
This theoretically seems like a good way to alert users, but what exactly would you even tell users? Most users barely understand past "make sure the padlock is there" – and many more technical users that I've observed don't even understand SSL warnings apart from "it's still SSL, make the warning go away" – so, showing a prompt about something even more obscure like static key exchange, will be lost on all but the most advanced security people. There are already plenty of ways for enterprises to get around this, like having their own CA and deploying that as a trusted CA to their machines. Then they can issue certs that their proxies could use, and their machines would just trust those certs. Why don't they just use that method?
- infogulch 10y ago
  The same thing you do with any other invalid configuration like SHA1 or expired certificates. Show a warning and a big red x through the padlock.
cesarb 10y ago
"The enterprise" already controls the servers (otherwise, they wouldn't be able to configure a static ECDH key on them). Having control of the servers is already equivalent to having full access to the plain text. This only enlarges the security boundary from the server to every machine which could possibly, now or in the future, have access to that static ECDH key. And the default would still be to use a dynamic ECDH key. Also, how would a browser know it has encountered this behavior? A key might be rotated every few minutes, so just seeing the same key twice is not enough; and the key could be derived from a static key and the TLS nonces, so seeing a different key also means nothing. That said, I think server vendors should not implement this option. It's too risky, since it could be enabled by accident, incompetence, or malice. It's better to force the few who believe they really need this option to implement it themselves.

cesarb 10y ago

The background is probably this email thread: https://www.ietf.org/mail-archive/web/tls/current/msg21278.html https://www.ietf.org/mail-archive/web/tls/current/msg21278.h... Previous discussion of that email thread: https://news.ycombinator.com/item?id=12641880 https://news.ycombinator.com/item?id=12641880 Basically, someone noticed (too late) that TLS 1.3 no longer has the RSA key exchange, which they liked because it allowed decryption of the encrypted traffic by passive middleboxes (which have a copy of the RSA private key). This draft is probably a response to that.

vorpalhex 10y ago

This is concerning. While TLS interception may be desirable by some, this is a dangerous precedent and I hope the de facto standard for all software will be to block and disallow this kind of behavior, and warn when it's been enabled ("This connection is not fully secure").

nickik 10y ago

I just saw a talk at 33C3 about TLS 1.3 and they tell the story behind this alternative TLS 1.3. Its a pretty fun talk. https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...

justaaron 10y ago

sounds so complex that I'm in diffie hell, man! *sorry, couldn't resist :D