Diffie-Hellman 代替 SSL？
能否使用 Diffie-Hellman 密钥交换算法代替 SSL 来加密网页上的客户端-服务器通信？如果可以，有什么缺点（即为什么标准使用需要证书颁发机构的 SSL）？我的理解是，Diffie-Hellman 可用于秘密建立共享密钥，然后可用于加密任何进一步的通信。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
两者其实没有可比性。 DH 是一种密钥交换算法，仅此而已。 SSL 尝试确定您所连接的服务器确实是它所说的服务器。为此，它使用一个可以追溯到您（应该能够）信任的人的证书。
DH 本身仅阻止其他人读取传输的数据。 SSL 的目的远不止于此（但可以使用 DH 来阻止其他人读取流）。
仅举一个明显的例子，使用 DH（单独）进行中间人攻击相当简单。如果我可以让您连接到我的服务器而不是您想要的服务器，我可以使用 DH 与您建立“安全”会话。然后我连接到您最初想要连接的服务器。我从你那里得到的每个数据包，都会用我用来连接到该服务器的密钥进行解密、重新加密，然后发送到该服务器。我对其所有响应数据包执行相同的操作。对您来说，一切看起来都像是直接来自原始服务器，并且您所做的购买（例如）就像正常情况一样。唯一改变的是，我还存储了您的信用卡号，当您第二天尝试给汽车加油时，收费会被拒绝，因为在此期间我已经花掉了您所有的积分。
SSL 中的身份验证至少旨在防止这种情况发生。如果您的浏览器尝试连接到（例如）www.amazon.com，并且我的 SSL 证书没有指定它是颁发给 www.amazon.com，那么它应该向您发出警告 - 并且 CA 不应颁发该证书除了亚马逊之外，任何人都可以得到这样的证书。
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 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.
实际上 Diffie-Hellman 是 SSL 的一部分。
但某一部分并不能取代其他部分。
来自此处 SSL Diffie-Hellman用于：
Actually Diffie-Hellman is a part of SSL.
But one part does not replace others.
From here SSL Diffie-Hellman is used for:
您可以将匿名 Diffie-Hellman 密钥协议与 SSL 结合使用。这提供了通道上的隐私，但不进行身份验证。
当然，如果没有身份验证，您确实无法拥有隐私，因为您的私人频道可能会连接到“中间人”。这就是不鼓励使用匿名 DH 密码套件的原因。
如果由于缺少证书而无法在真正需要的地方使用 SSL，请从 startcom.org 获取免费证书。< /a>
You can use anonymous Diffie-Hellman key agreement with SSL. This provides privacy on the channel, but no authentication.
Of course, without authentication, you really can't have privacy, because your private channel could be connected to a "man-in-the-middle". That's why the anonymous DH cipher suites are discouraged.
If the lack of a certificate is stopping you from using SSL where it's really needed, get a free one from startcom.org.
Diffie-Hellman 密钥交换仅用于密钥交换。它不会为您提供身份验证（您正在与谁交谈），您需要证书和 PKI。
所以是的，你可以进行加密，但你不知道你在和谁说话
Diffie-Hellman key exchange is only for keyexchange. It does not give you authenticitation (who you're talking to), you need certificates and a PKI for that.
So yes you can do encryption, but you dont know with who you're talking to
DH 密钥交换本身不能进行加密。它用于建立会话密钥，但不进行加密。因此，在这个层面上，这个问题是错误陈述的，或者暴露出缺乏精确性或缺乏理解（我怀疑这次的问题是精确性）。
问题是：
正如已经指出的，SSL 使用 DH 密钥交换来建立会话密钥。但是，它还确保另一端的程序是您信任的人（直接或间接）。如果你不需要担心对方是否可信，你可以只使用简单的DH密钥交换，然后发送加密数据，而不需要证书。但除非您验证这一点，否则您将无法确定您正在与谁交谈 - 并且 SSL 等使用的证书有助于该验证。
The DH key exchange cannot, of itself, do encryption. It is used to establish a session key, but not to do the encryption. So, at this level, the question is mis-stated or reveals either lack of precision or lack of understanding (I suspect precision is the problem this time).
The question is:
As already pointed out, SSL uses a DH key exchange to establish a session key. However, it also ensures that the program on the other end is someone you trust (directly or indirectly). If you don't need to worry about whether the other person is trustworthy, you could just use a simple DH key exchange and then send encrypted data without needing certificates. But you won't be sure who you are talking to unless you validate that - and the certificates used by SSL etc helps with that validation.