关于SSL中使用DH的问题

 

常见的SSL协议描述中没有看到进行密钥协商时是否使用DH的明确描述。下面是一个老外的见解。

 

大意是说证书能够保证通信者的身份可信任，防止中间人攻击。

DH密钥交换算法，则能保证防止第三方监听，虽然DH本身存在受“中间人攻击”的缺陷。如果结合证书，就可以完美解决这个问题。

 

如果不使用DH，有一种情形是，如果服务器证书的私钥泄漏，那么攻击者，只要通过监听通信，就可以轻松拿到双方协商的通信密钥。

如果使用DH密钥协商，那么即便服务器私钥泄漏，攻击者必须进行中间人攻击，才有可能成功。这一定程度上增大了攻击难度。

 

 

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 anybodybut Amazon.