SSL and Diffie-Hellman

Question

So I was reading this and was surprised by the answer of Remus. Because I thought it was exactly the other way around.

So, as for my question. Why is a program using the diffie-hellman key exchange to settle on a shared key to encrypt/decrypt messages (generally) less secure than SSL?

Edit: I know SSL uses a digital certificate but as my program only communicates with itself (client-server) that doesn't matter anyway, right?

Answer 1

Remus post mainly cautions against creating your own crypto protocols (because you probably will make some fatal mistake) and instead use the existing solution SSL.

You can write a secure network protocol using only Diffie-Hellman as asymmetric crypto together with some symmetric crypto. My favourite secure network protocol works like that. A program using DH isn't weaker than SSL per se, but a program where a non crypto expert designed the protocol most likely is.

But if you design your own protocol, you will need to learn a bit of crypto to do it correctly. You probably want expert review for your design and code as well, in case you made a mistake somewhere. But getting that review isn't easy unless your product is famous enough or you pay them.

The SSL handshake does two major things:

1. It uses the certificate to verify that the server is authorized to represent the domain you want to communicate with.

   In the most common case a Certificate Authority vouches that the owner of a certain keypair is the rightful owner of a certain domain (this takes the form of a certificate). This part is only as secure as the weakest recognized CA.

   If you only need to communicate only with a single server, you can hardcode the server's fingerprint cutting out the whole CA and PKI part. This approach is similar to the way you typically handle SSH fingerprints.

2. It generates a session key

Strong SSL suites use the certificate for authenticating the server and DH to generate the session key. Weaker suites use the certificate for both.

Naive DH based protocols will probably forget to authenticate the server, allowing an active attacker to MitM the connection. You need to authenticate the server somehow, even if it's simply by hardcoding the server's public key in your client.

Answer 2

Remus isn't commenting on the pros and cons of a particular encryption algorithm.

He is instead commenting on the need to avoid writing your own crypto protocols. I agree with him 100%.

Writing encryption protocols is very difficult and fraught with peril. Any number of exceptionally subtle bugs can easily creep in and make your entire system insecure. Even experts often get things wrong and need to patch things at future dates.

It's also a sign of platform maturity that it's so easy with WCF other platform components to use the stock tools.