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?