I'm having doubts about the mechanics of a man in the middle attack during a Diffie–Hellman key exchange. I have heard that it can happen during the key agreement communication. But in the presence of CA (Certificate Authority) the receiver can authenticate the sender as he received the sender's public key. Therefore, how is a man in the middle attack possible?
How does the man in the middle attack work in Diffie–Hellman
diffie-hellmanpublic-key-encryption
Related Solutions
The two aren't really comparable. DH is a key-exchange algorithm, nothing more and nothing less. SSL attempts to establish that the server you're connecting to is really who it says it is. To do that, it uses a certificate that can be traced back to somebody you (are supposed to be able to) trust.
DH, by itself, only keeps others from reading the transmitted data. SSL is intended to establish considerably more than that (but can use DH to keep others from reading the stream).
Just for an obvious example, using DH (by itself) a Man in the middle attack is fairly simple. If I can get you to connect to my server instead of the one you intended to, I can use DH to establish a "secure" session with you. I then connect to the server you originally intended to. Every packet I get from you, I decrypt, re-encrypt with a key I used to connect to that server, and send on to that server. I do the same with all its response packets. To you, everything looks like it came directly from the original server, and the purchase you made (for example) works just like normal. The only thing that changes is that I also store your credit card number, and when you try to fill your car with fuel the next day, the charge is declined, because in the meantime I've spent all your credit.
The authentication in SSL is at least intended to prevent that from happening. If your browser tried to connect to (for example) www.amazon.com, it should give you a warning if my SSL certificate doesn't specify that it was issued to www.amazon.com -- and a CA shouldn't issue such a certificate to anybody but Amazon.
DH, by itself, doesn't really even guarantee most of what I've said above. By itself, DH is just a way to exchange a key (or, perhaps it could be phrased as "exchange information necessary for both parties to create identical keys, without ever exchanging the key itself in the clear"). After both parties have the key, they can (and presumably will) use it to encrypt/decrypt data -- but that encryption is actually separate from DH itself.
Offering the Wikipedia answer:
In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish two distinct Diffie–Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed between them.
A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack. Variants of Diffie-Hellman, such as STS, may be used instead to avoid these types of attacks.
You may consider impressing your professor by discussing the variants of Diffie-Hellman that are more secure. For now, given you've noted the original implementation, this will do.
Best of luck!
Best Solution
I think you're confusing the basic Diffe-Hellman, which is a key exchange protocol, with the 'authenticated version' which uses a certificate authority (CA).
Nice explanation of how the basic Diffe-Hellman is vulnerable to man-in-the-middle from RSA Labs.
and it follows with the authenticated version, also known as the Station-to-Station protocol:
So the basic version is susceptible to a man-in-the-middle attack, the authenticated version that uses public key certificates is not.