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.