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?