Concerning the use of DH in SSL

 

The common SSL protocol descriptions do not clearly describe whether to use DH for key negotiation. The following is a foreign opinion.

 

The purpose is to ensure that the certificate can be trusted by the sender and prevent man-in-the-middle attacks.

The DH key exchange algorithm can prevent third-party listening, although DH itself is vulnerable to man-in-the-middle attacks. If you combine the certificate, you can solve this problem perfectly.

 

If DH is not used, an attacker can easily obtain the negotiated communication key by listening for communication if the private key of the server certificate is leaked.

If DH key negotiation is used, even if the server's private key leaks, attackers must conduct man-in-the-middle attacks to succeed. This increases the attack difficulty to some extent.

 

 

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. 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 shoshould 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 certificateAnybodyBut Amazon.