Evading authenticated diffie hellman with MITM

Question

I understand that in a non-authenticated Diffie-Hellman setup, a man-in-the-middle attack can occur. Now i'm curious about the feasibility of the following scenario:

Let's assume a situation where www.example.com exclusively supports authenticated Diffie-Hellman.

1. The victim attempts to establish contact with https://www.example.com/.
2. A man-in-the-middle attacker intervenes, retrieves the certificate from example.com, and sends it back to the victim.
3. The victim successfully authenticates the server because the certificate is valid
4. The attacker proposes only unauthenticated Diffie-Hellman to the victim as method of encryption.
5. The victim agrees to the proposal, resulting in an SSL connection being established between the victim and the attacker.
6. The attacker initiates an SSL connection with example.com, which is authenticated due to the initial assumption.
7. Requests made by the victim traverse these two connections.

In this manner, the man-in-the-middle attacker maintains two connections simultaneously.

Answer 1

For TLS versions up to (including) 1.2, there are three DH versions: anonymous (ADH), fixed and ephemeral (DHE - see here for a quick description).

TLSv1.3 supports only DHE, so by default, your scenario does not work with TLSv1.3.

For <TLSv1.3, as @dave_thompson_085 has already pointed out, ADH can be selected (or provided as an option) in the 'ClientHello' message of the TLS protocol. 'ClientHello' is the first message that initiates the TLS negotiation between the client and the server (see a quick description here). After that point you can't change the DH version used.

In your scenario, an authenticated DH version is selected during step 1 (the server sends its certificate to the client after it receives the 'ClientHello' message from the client - the attacker just forwards the packets between the client and the server); you cannot change the DH version in step 4 (because the TLS negotiation has moved on from the initial 'ClientHello' message).

Alternative scenario 1: client sends the 'ClientHello' with e.g. DHE selected (ADH can be an option too, it doesn't matter in this scenario), the attacker intercepts the message, sends the 'ClientHello' to the server with ADH selected, the server rejects it (because you said it only accepts authenticated DH)

Alternative scenario 2: client sends the 'ClientHello' with e.g. DHE selected (but does not allow ADH as an option), the attacker intercepts the message, sends the 'ClientHello' to the server with ADH selected (let's assume the server allows it), server returns a message with the ADH suite selected, the client rejects it (because it does not support ADH) and closes the connection

Alternative scenario 3: client sends the 'ClientHello' with e.g. DHE (but provides the option to use ADH), the attacker intercepts the message and initiates a full MitM attack by establishing two ADH connections, one with the server and one with the client. Assuming that the server accepts ADH, this is the only scenario that can work (of course, this is well documented, so no surprises here).

So, aside from the case where both the client and server accept ADH, every other scenario is not feasible.

Answer 2

The attacker proposes only unauthenticated Diffie-Hellman to the victim as method of encryption. The victim agrees to the proposal [of anonymous DH], resulting in an SSL connection being established between the victim and the attacker.

Standard TLS clients won't accept anonymous Diffie-Hellman (by default). The DH_anon ciphersuites are disabled by default and should only be allowed if you only want opportunistic encryption:

Using this mode [DH_anon] therefore is of limited use: These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.)

These ciphersuites are insecure.

A man-in-the-middle attacker intervenes, retrieves the certificate from example.com, and sends it back to the victim. The victim successfully authenticates the server because the certificate is valid

If the target, accepts DH_anon the attacker does not event need to use any certificate. Because, DH_anon is not authenticated it does not use any certificate:

The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message.