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 is the shared secret, as 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?