Limitations of TLS Inspection when using Diffie-Hellman

Question

It is my understanding that TLS Inspection can be carried out of two different ways:

• 1st Approach: Using a proxy server which negotiates TLS with both ends.
  • In this scenario, there would be 2 different TLS channels (Client <-> Proxy <-> Server)
  • If non-standard TLS implementations are used by the client/server or specific requirements need to be met in TLS negotiation, the Proxy would need to have specific features enabling that.
• 2nd Approach: Using an intermediate element containing the secrets needed to decrypt TLS shared key negotiation (e.g. private key associated to server's certificate) with the ability to re-encrypt (by using server's certificate) and forward the traffic to the server.
  • In this scenario, Client and Server would not see the intermediate server and it would essentially be a unique TLS channel, even if the intermediate element can see and block suspicious traffic.
  • Intermediate element would not need to implement further features, as it only acts by listening and forwarding/blocking.

When a cryptosuite implementing DH or ECDH is used over a TLS communication, is it possible to make use of the 2nd Approach? From what I know, Key Exchange in DH makes infeasible for an "eavesdropper" to figure what the shared secret is, as RSA private keys are only used as a mean to authenticate the server.

Depending on the cryptosuite used, would TLS Inspection be restricted to the 1st Approach?

Answer 1

Both of your approaches essentially describe the same thing: There is some intermediary system which terminates TLS and you have essentially two TLS connections: one from this middlebox to the client and one from the middlebox to the server.

The only difference is that in your second scenario the middlebox has access to the certificate and private key of the server and thus can fully impersonate the server without changes to the client. While you don't describe the first case in more detail my guess is that in this case certificates gets created dynamically by the proxy and signed by a CA explicitly trusted by the client. This first case can be usually found at a firewall which should give a client access to many sites on the internet while the second case is used to protect a specific server (for example by using a web application firewall).

Since in both cases you have two separate and independent TLS connections there is nothing special with DH, i.e. both connections can use DH key exchange.

But, there is a third scenario where an intrusion detection system (IDS) gets the traffic exchanged between client and server and should passively detect attacks against this server, i.e. without being the TLS endpoint. In this case there is only a single end-to-end TLS connection between client and server. And to decrypt the traffic for analysis the IDS needs traditionally have access to the private key server - but this works only with RSA key exchange. To make such passive analysis possible with DH the IDS would need to have access to the master secret of each new connection, i.e. somehow the server must provide the IDS with this information. And this is far more complex than just providing the IDS with the static private key of the certificate.