Hacker News Reader

Comment by CodeMichael | Hacker News Reader

If I'm not mistaken this means no "authorized" MITM

  - Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.

View on HN

It does not. There are some passive decryption tools that will no longer work because they functioned by having non-forward-secure connections and the server's private key installed in the decrypter. (But one can just not support TLS 1.3 at the server to keep them working.)

MITM proxies, which are trusted by the client and which terminate and recreate the TLS connection, will continue to function. (Assuming they implemented TLS 1.2 correctly, which some didn't.)

Does that assume that all of the components (browser and server) support 1.2 as well? In a theoretical future state if I disable 1.2 on my browser doesn't that mean I won't trust a MITM box.

> Does that assume that all of the components (browser and server) support 1.2 as well?

No: a client, server, and MITM proxy can all be exclusively TLS 1.3 and everything will still work(+).

(+) as much as it did with TLS 1.2, anyway.

Did banks and other network operators who require monitoring their traffic just deem the MITM proxies too expensive or complex, or what was the reason for their protest?

The main complaint seems to be that the proxy can no longer use the Triple Handshake attack to inspect only part of the connection and pass the rest through, it's instead forced to do a full MITM all the time: https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00

Except they'll just start checking SNI instead to see what sites you're browsing. Getting rid of triple handshakes is good from a theoretical perspective, but it does nothing at all to increase your privacy against middle-boxes.

With SNI, they can't easily see whether you're looking at https://en.wikipedia.org/wiki/Cat or at https://en.wikipedia.org/wiki/Pornography (just looking at the size is not enough; Wikipedia has millions of pages, thousands of then are changed every day, it has a variable-sized HTML comment, and the HTML size also changes when you're logged in), while with the triple handshake attack, they can see the full HTTP request and response headers, while avoiding most of the cost of being "in the middle" during the actual content transfer.

https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 is the current state of the effort to encrypt SNI. It's a good overview of which obvious ideas can't work and why, plus some complicated ideas that might work, with two of them expanded to a state where it's reasonable to start developing opinions about them as engineers or cryptographers.

Ultimately the destination is that one of these two (or potentially some upset newcomer if it's written up and presented soon) becomes the agreed way to do SNI encryption, and perhaps in 2019-2020 we start seeing clients & servers that can really do it.

For the short term it remains unclear which of the following three things will happen, both generally and in particular environments:

1. (Bad) Organisations bite the bullet and MitM Proxy everything, expenditure on MitM proxies sky-rockets, lawyers spend lots of time & money in court arguing that they _had_ to MitM proxy everything even though it violated employees legal rights.

2. (Good) Organisations suck it up and get rid of MitM proxies almost everywhere, preferring edge solutions that actually still work with TLS 1.3 without needing to spend loads of cash on MitM proxies for everything.

3. (Meh) Organisations refuse to use TLS 1.3, insisting on downgrading everything to TLS 1.2 and crossing their fingers that never becomes obsolete or insecure (see also Windows XP)

"Assuming they implemented TLS 1.2 correctly, which some didn't." -> BlueCoat?

Basically everybody selling middleboxes screwed up, some worse than others but even the workaround in TLS 1.3 could best be understood as a hint that most middleboxes are ineffective garbage.

Nota bene: TLS debugging via SSLKEYLOGFILE and similar mechanisms is of course not affected.

Yes and no. Passive eavesdropping where the eavesdroppers has been given the servers' RSA keys no longer works, but that's about it. This was mainly something that banks did for very, very defective reasons.

Other types of MiTM still work, such as an active MiTM through a malicious root certificate.

This is not true. The client can simply skip the certificate verification, making the connection unauthenticated. Raw Public Keys (which are basically simplified X.509 certificates), can also lead to unauthenticated connections.

In fact, Appendix C5[1] reads:

   Previous versions of TLS offered explicitly unauthenticated cipher
   suites based on anonymous Diffie-Hellman.  These modes have been
   deprecated in TLS 1.3.  However, it is still possible to negotiate
   parameters that do not provide verifiable server authentication by
   several methods, including:

   -  Raw public keys [RFC7250].

   -  Using a public key contained in a certificate but without
      validation of the certificate chain or any of its contents.

[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix...

Reply on news.ycombinator.com