i'm trying to learn how commercial (for example PaloAlto or Fortigate) middleboxes intercept and decrypt TLS 1.3 traffic. To do that I started observing the TLS traffic between the client, middlebox and the server. Now I drew my conclusions out of this and I would like to verify if that is correct. Maybe you could give me some hints :)

These are my results:

The first thing I noticed is, that during TLS 1.3 handshake the ephemeral key in the Client Hello is exchanged by the middlebox before the packet is sent to the actual server. This is also the case for the Server Hello. I presume this is done to establish two encrypted channels with the help of DHKE, one between client and middlebox and another one between server and middlebox. This will allow the middlebox to decrypt any further encrypted traffic from client or server. Before forwarding the packet to the actual destination I assume the middlebox will re-encrypt it with the key associated to the other encrypted channel.

Is this assumption correct so far?

In another Step of the TLS 1.3 handshake the Certificate and Certificate Verify message will be sent by the server to verify authenticity. My assumption is, if the middlebox just forwards these message this will result in an error due to the fact that the verification of the signature would not succeed. In my understanding this due to the fact that the server generated hash value is different to the hash the client will compute. I assume this is the case because the client will compute the hash based on its public ephemeral key in Client Hello. However the server has the Client Hello message where the middlebox changed the public ephemeral key and thus the hash will be different.

...Is this assumption correct?

To overcome this issue the middlebox may no use its own CA and intercept the Certificate and CertificateVerify message. With its own CA the device will construct a new certificiate. Now the middlebox will compute the hash of the exchanged Handshakes message that have been exchange between middlebox and client (so no ephemeral keys have been changed) and sign it with its own private key. The client will now compute the same hash as the middlebox the TLS handshake continues, unless the client does not trust the CA-certificate of the middlebox.

...Is this assumption correct?

  • $\begingroup$ Welcome to crypto-SE. A nice thing is that you can edit a question or answer to improve it! Update: kudos for doing just that. Also: should "may no" be "may now"? $\endgroup$
    – fgrieu
    Commented Nov 23, 2023 at 10:02
  • $\begingroup$ I think this is more into our venerable site Information Security $\endgroup$
    – kelalaka
    Commented Nov 23, 2023 at 12:29
  • 2
    $\begingroup$ TLS MITM (no matter if TLS 1.3 or lower) is simply two separate TLS connection (client-proxy, proxy-server) with their own certificates. Encryption keys and ciphers and other TLS parameters are completely independent between these connections. The proxy dynamically creates a certificate based on the original server certificate, but issued by the proxy CA - which needs to be trusted by the client. See security.stackexchange.com/questions/133254/… $\endgroup$ Commented Nov 23, 2023 at 16:54
  • $\begingroup$ Yeah, two connections, not one; only the data in the connection is forwarded. $\endgroup$
    – Maarten Bodewes
    Commented Nov 25, 2023 at 15:06


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.