How does the Diffie-Hellman algorithm prevent MITM attack?
I have tried to search about it but i couldn't find any understandable reasons.
$\begingroup$
$\endgroup$
-
$\begingroup$ Have you looked at the Wikipedia page? It should be pretty clear $\endgroup$ – Natanael Aug 4 '19 at 16:35
-
$\begingroup$ Would you please post the link here? $\endgroup$ – Mas HJ Aug 4 '19 at 16:37
-
1$\begingroup$ Possible duplicate of Definition of Short Authentication String $\endgroup$ – kelalaka Aug 4 '19 at 19:06
-
1$\begingroup$ @kelalaka This very much does not appear to be a duplicate of that question. This question is clearly about plain DH, where the answer is "It does not." $\endgroup$ – Maeher Sep 5 '19 at 11:43
$\begingroup$
$\endgroup$
The problem lies in the trust of the public key. If an attacker can simply replace one of the exchanged public keys with his own then an active MITM attack is possible. The attacker simply replaces both public keys with his own and proceeds to create two channels that rely on the shared secrets. For ephemeral key pairs - as commonly used - the key pairs are short lived and the public key is not trusted so DH key agreement is then inherently insecure against MITM attacks.
This is the default for all TLS 1.3 cipher suites and all TLS 1.2 suites that start with DHE or ECDHE. These suites therefore have to rely on other methods of authentication to mitigate the MITM attacks.
So the common ephemeral-ephemeral Diffie-Hellman scheme does not protect against MITM attacks, and your premise is false.
Some DH protocols where both parties are authenticated may actually prevent MITM attacks. In static-static DH the public keys of both parties may be trusted and therefore the DH will provide entity authentication of both sides, rendering MITM impossible.
This is not a common method of operation at all. It seems TLS can offer static-static DH, but it seems a rare find. Because the key pairs are always identical the protocol relies on an additional nonce - applied during or after the key agreement - to make sure that the resulting shared secret changes on every execution of the DH key agreement protocol. The scheme where the nonce is applied during key agreement is not offered by many implementations.
If just one key pair is static and the public key is trusted then the party verifying the validity of the public key will see the invalid public key, and break off the handshake of the protocol used. Ephemeral-static DH is therefore also invulnerable against MITM attacks, even if just one party gets authenticated. Of course the party that accepts the ephemeral public key will still not have any idea who he's talking to. This is e.g. not a problem on internet sites as they don't care about who reads them - they offer additional password authentication where required.
Ephemeral-static key agreement is present in the TLS cipher suites starting with DH_ and ECDH_. This method of authentication is however not present in TLS 1.3 anymore. The authenticated DH protocol requires an DH-based certificate to be able to trust the public key. These kind of certificates are hard to come by. In practice only certificates that use RSA or ECDSA for authentication are used, rendering these suites useless.
Ephemeral means temporary, or fleeting. Ephemeral key pairs should be generated on each invocation of DH, and the private key should be destroyed to achieve so called forward secrecy. Some servers cheat - because key pair generation can be relatively CPU expensive - and reuse the key pairs for a longer time or even until the server is rebooted.
answered Aug 17 '19 at 9:39
-
1$\begingroup$ TLS through 1.2 DH_x or ECDH_x suites can be static-static if server requests client auth (rare) and client has (EC)DH cert. Classic-DH cert is very rare, but (X9.63) ECDH uses the same cert format as (X9.62) ECDSA, so ECDH cert only requires KeyUsage extension, see e.g. crt.sh/?id=939752960 . static-static makes TLS premaster the same but master and working keys differ. And FWIW SSHv2 always uses DHE or ECDHE, with both server half and agreement result signed by 'host' static pubkey. $\endgroup$ – dave_thompson_085 Aug 18 '19 at 8:09
-
$\begingroup$ Yeah, so ECDSA and DH key pairs are obviously the same. Is it common to set the key usage extension? I'm a bit flabbergasted, I had firmly in my mind that client auth was always separate from server auth in TLS - certainly I didn't know that there was any room in the protocol for them to be identical. And yes, I presume you can introduce randomness in key derivation as well, I'll change my answer later in the day; I was using TLS as example, but it seems I have to implement TLS 1.2 as well to become an expert on it! $\endgroup$ – Maarten Bodewes♦ Aug 18 '19 at 12:12
-
$\begingroup$ I don't know how common are EC certs with KU=keyagree. The wikipedia example is the only one I found among the certs I have saved on my PC as a result of looking at various issues or questions, which is not at all scientific. There are researchers who scan all IPv4 or the top million or so sites looking for things like shared=broken RSA factors, MD5 signatures, insecure IoT things, etc. and they would have better data. FWIW I haven't implemented TLS but have spent lots of time groveling over traces and checking RFCs to investigate problems. $\endgroup$ – dave_thompson_085 Aug 19 '19 at 6:54
-
$\begingroup$ Yeah, but it would only be set to perform static-static if a valid client cert would be offered. Generally that would be performed for specific instances, such as login to a organization's intranet from the internet. So I don't expect them to list operational static-static DH capable TLS systems. Due to the usual small key sizes for DH, I expect that the ones out there are EC based systems, if any. $\endgroup$ – Maarten Bodewes♦ Aug 19 '19 at 9:34
$\begingroup$
$\endgroup$
The answer depends on the attack your are interested in.
For passive attackers who are eavesdropping on the exchanging of information, the attacker has to solve an instance of the Diffie-Hellman problem which is believed to be difficult.
For active attackers who can tamper with the information exchanging, "textbook" Diffie-Hellman is not safe. To prevent this class of attacks you would need to use an authenticated key exchange (AKE).
$\begingroup$
$\endgroup$
How DH Key Exchange works:
Server sends group parameters i.e. g which is generator and a large prime p.Server choose a random a and calculate g^a mod p. This value is signed with the private key from the server's certificate, an MiTM cannot change this value. Also Discrete logarithm Problem states that give above value and g and p, it is tough to a. These value are sent to client in ServerKeyEchange. Similarly client also choose b and send g^b mod p. Both client and server now have shared secret of g^ab mod p.
MiTM cannot get these value unless p is small like 768 bits of lesser for which we know its already broken(LogJam attack). Another point is server value of g^a mod p is signed so MiTM cannot tamper with it. Further in future a and b value chosen by Server & Client respectively can be thrown and a new value a' b' are chosen , this provide perfect forward secrecy. So even if somehow MiTM break g^ a mod p for a , he cannot do again and again as the value keep changing.
