Understanding SSL man-in-the-middle and its limitations

Question

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:

1. 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
2. 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:

1. 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?
2. 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
3. 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.

Answer 1

I think you got some of the concepts right but there are also some misunderstandings or inaccuracies.

• Decrypting the traffic in a passive man in the middle attack (i.e. only sniffing) by using the servers private key is only possible when RSA key exchange is used. It can not be done with Diffie-Hellman key exchange. Contrary to RSA key exchange the DH key exchange also causes forward secrecy which means that previously sniffed connections can not be decrypted once the attacker got the private key of the certificate.
• An active man in the middle attack consists of a SSL session from client to MITM and from MITM to server. These are fully separate sessions which have different keys and can also use a different cipher, protocol version etc. If the MITM attacker has the servers original private key he can impersonate the server perfectly by using the original certificate. Otherwise a fake certificate need to be used (often created dynamically). The attack succeeds only in the latter case if the client already trusts the CA issuing the fake certificate or the client does not do proper certificate validation.
• Client certificates are similar to server certificates: either the attacker has the private key of the original certificate and thus can use it or the server needs to somehow trust the attackers fake certificate respectively fails to properly validate the certificate.

Answer 2

The most obvious threat with MITM is where the interaction is simplified such as between a website and a browser. In most instances the user simply types in the URL and expects to see a notification that the connection is secure. If the presented site matches their expectation they go about their business.

Amusingly MITM is used wholesale by security gateways to perform content filtering on HTTPS connections. In these cases the gateway acts as a proxy for all outbound traffic; the HTTPS connection is between the client and the gateway. In corporate environments the IT department typically pushed out the Root CA for the gateway to all in house machines which allows the client to access the gateway's certificate and show the connection as secure. The gateway then decrypts the request, filters as appropriate, and makes it's own secure connection to the server. This also applies to secure SMTP connections and any other protocol that is force proxied.

One giveaway in the above scenario is that the certificate used by the gateway usually identifies the connection as being with a gateway provider (be it Sophos, Checkpoint, Fortinet, etc).

In the case of malicious actors the goal is surreptitious interception. For this to be successful the actor will have compromised a generically trusted root CA. Through that compromise the actor can issue a new certificate with all of the expected details for the server.

Assume that hotel guests (Alice) are staying in an unfriendly locale. They want to use the services of Bob.com. Actor Malory is attempting the MITM.

Malory connects to Bob.com and copies all of the business details of Bob.com's SSL certificate. Malory has previously compromised WeTrust Root CA which is built in to Windows, macos, ios, and Android.

Malory inserts herself in the hotel's network (can be either a physical tap, a port reroute at the switch, or even a simple DHCP attack). Malory redirects all traffic through her transparent proxy looking for access to Bob.com.

When Alice accesses Bob.com Malory's proxy presents itself to Alice as Bob.com using the forged certificate. Meanwhile Malory connects to Bob.com and forwards requests/pulls/pushes/puts/etc between the two. Unless Alice looks at the issuer of the Root CA and knows who Bob.com's SSL certificate issuer is (and also provided that Bob.com's SSL certificate issuer is not the same as the one compromised by Malory) she would have no way of detecting the MITM.

MITM is about inserting oneself into the key exchange, not cracking the encryption and using simple wireshark/netflow traffic monitoring.