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.

enter image description here

  • Welcome to the community. You either missed something or I lack the understanding where the "evasion" happens?.. Aug 16 at 18:54
  • @SirMuffington My intention was for it to imply evading authenticated Diffie-Hellman through a proposal by a MITM. I have now edited the title to make it clearer
    – SempriGno
    Aug 16 at 18:59
  • 3
    MitM can't authenticate to client using the real cert, and can't 'propose unauthenticated' after sending any cert because in 1.2 and below (the protocols where unauth exists at all) the ciphersuite is chosen before any cert is sent. Anyway no real client accepts 'anonymous'. Server auth is for the benefit of the client, not the server; MitM can simply connect to the server (with auth DHE) without any client doing anything or even existing, so I don't see how you've 'evaded' anything. Aug 17 at 1:09
  • Maybe this is a better fit for crypto.stackexchange.com/questions
    – 123
    Aug 17 at 19:15

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .