Diffie-Hellman in place of SSL?

kmnan picture kmnan · Oct 27, 2009 · Viewed 11.3k times · Source

Can a Diffie-Hellman key exchange algorithm be used to encrypt client-server communication on a web-page in place of SSL? If it can, what are the disadvantages (i.e. why does the standard use SSL which requires a certificate authority)? My understanding is that Diffie-Hellman can be used to secretly establish a shared key which then can be use to encrypt any further communication.

Answer

Jerry Coffin picture Jerry Coffin · Oct 27, 2009

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.