I’m trying to develop a good sense of how an SSL man-in-the-middle(s) (MITM) works. As I understand it, MITMs do their work in one of two ways:
- Decrypt the SSL by having a copy of the server’s private key. Strictly speaking, this is not MITM since the “MITM device” is simply eavesdropping. The SSL session is not changed
- Generate new certs on the fly. Here, the MITM device forwards the client hello, intercepts the server cert, generates and signs a new one, and forwards along to the client. The client either trusts the cert or is asked to trust it (if it’s self-signed)
There are limitations (and mitigations), though:
- The Client and Server might agree to generate and exchange keys using DHE_RSA (or a variant). The MITM wouldn’t participate in the key generation. But can’t a sophisticated enough MITM still generate session keys creating distinct ssl sessions on either side?
- Wouldn’t the same go for the Extended Master Secret? As above, if the MITM were actually computing distinct session keys, the Extended Master Secret would not help defeat the MITM
- The server might require a client certificate. But if the MITM could acquire its own client certificate and the corresponding private key, it could successfully sign Certificate Verify handshake messages
Am I understanding all of this correctly? It seems like if a MITM had access to enough key material, it could successfully decrypt any SSL session.