6

I have been reading a number of articles that state it is not possible for an inspection proxy to simply drop-out/disengage from a TLS 1.3 connection in the same way that is possible in TLS 1.2. Such articles never seem to explain exactly why that is the case, for example some simply say "its because the certificate is encrypted".

In this IETF paper it gets a bit closer to explaining but I do not really understand what it means or exactly why it is not possible

This technique is not functional with TLS 1.3 since the transcript hash over the handshake messages is part of the key derivation procedure.

Can someone please explain this to me?

Thanks

Community
  • 1
rlon134
  • 75
  • 4
  • 5
    Proxies were never supposed to do what some TLS1.2 proxies did. TLS1.3 fixed it to force proxies to MiTM the connection properly, i.e. to create two separate different connections with different session keys, one between client and proxy and one between proxy and server. In this mode the proxy cannot stop proxying without killing the connection. You should read sections V-A and V-B in https://hal.inria.fr/hal-01102259/file/triple-handshakes-and-cookie-cutters-oakland14.pdf – Z.T. Mar 05 '21 at 15:32

1 Answers1

5

In TLS 1.2, the master secret, which is used for deriving keys, is derived from the pre-master secret and some additional data. With RSA key exchange, the TLS middlebox can simply act as the client and send the pre-master secret that was derived to the remote server. With Diffie-Hellman key exchange, the TLS middlebox sends non-prime parameters (which are usually insecure) based on the server's key exchange parameters such that the computation of the pre-master secret is the same. As Z.T. mentioned, this is described in the Triple Handshake paper.

In TLS 1.3, the keys are derived from the master secret and a hash of the handshake using HKDF. Because HKDF is a PRF (a pseudo-random function family), it is functionally impossible to generate the same set of keys when the handshake hashes are different (which they must be if the TLS middlebox and the server present different certificates), even if the keying material is the same.

This was done intentionally for two reasons:

  1. This makes it much harder to conduct any sort of attack on TLS, since the entire handshake, as well as the actual key exchange, influence the derived keys. It's no longer possible to specifically craft keying material to intentionally derive the same set of traffic keys, which has been used in previous attacks.
  2. Many folks involved in TLS do not like middleboxes, since they rightly see them as an intentional attack on the end-to-end security of the protocol, and this makes them more difficult to implement.
bk2204
  • 7,828
  • 16
  • 15
  • 3
    1.2 _can_ implement rfc7627 extended master secret and rfc7919 predefined (safe) DHE groups to get the same effect as 1.3 -- but if you're going to change the implementation you might as well implement 1.3. – dave_thompson_085 Mar 06 '21 at 01:16
  • A huge reason why TLS people hate middleboxes is because they have caused so many problems with deploying TLS and updating the protocol. See all the ways TLS1.3 pretends to look like TLS1.2 just because of middleboxes. Middleboxes pretended they fully understood extensions they did not understand and broke things. TLS1.3 made everything after ClientHello encrypted to prevent that. It's not just for privacy, it's also for interoperability, by ensuring middleboxes can't mess up. – Z.T. Mar 06 '21 at 16:59
  • Thanks, understand now. Is there a RFC that describes the way the handshake hash is input into the HKDF, I cannot find that in 8446? – rlon134 Mar 09 '21 at 09:25
  • Yes, it's described in §7.1 of RFC 8446, page 93. – bk2204 Mar 09 '21 at 23:17
  • Perfect thank you. – rlon134 Mar 10 '21 at 08:58