服务器受损时如何防止中间人攻击？
想象一下，服务器正在向其合作伙伴提供用户的公钥，以使加密通信成为可能。但是，服务器无法访问私钥。
无论如何 - 想象服务器被黑客攻击并且它不发送请求的公钥：
Alice 请求 Bob 的公钥
服务器发送Eve的公钥鲍勃请求爱丽丝的公钥
服务器发送Eve的公钥爱丽丝向鲍勃发送消息
服务器解包消息，读取它并重新打包 ->发送给鲍勃...鲍勃向爱丽丝发送消息
服务器解包消息，读取它并重新打包 ->发送给爱丽丝...
我的问题是 - 如何防止这种滥用？ Alice 如何确定她正在使用 Bob 的公钥，反之亦然？
Imagine that a server is serving public keys of the users to their partners to make encrypted communication possible. However, the server does NOT have access to the private keys..
Anyway - imagine the server is hacked and it sends not the requested public keys:
Alice requests Bob's public key
Server sends Eve's public keyBob requests Alice's public key
Server sends Eve's public keyAlice sends a message to Bob
Server unpacks message, reads it and repacks it -> sends to Bob...Bob sends a message to Alice
Server unpacks message, reads it and repacks it -> sends to Alice...
My question is - how to prevent such abuse? How can Alice be sure that she's using Bob's public key and vice versa?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据你刚才提出的方案，你不能。这里的关键（没有双关语）是，如果用于验证密钥有效性的方法受到损害，您就会失败。
SSL 尝试通过创建签名链来避免这种情况 - 一些（非常仔细地保护并通过其他方法验证）密钥签署另一个密钥，签署另一个密钥，签署 Alice 的密钥。通过验证链中的每个步骤，您（原则上）可以知道该链是有效的 - 但如果链中任何步骤的私钥被泄露，您就会失败。
PGP（又名 GPG）尝试以不同但相似的方式解决问题 - 密钥可以由任意数量的其他密钥签名，形成一个图（称为 信任网络）。您选择一些已确认有效的密钥（例如，亲自验证它们），并将它们标记为可信。然后，通过少于 N 个步骤（和/或来自不同可信根的 M 个不同路径）可到达的任何密钥也被认为是有效的。
如果你真的很偏执，你当然可以亲自把钥匙交给对方。当然，他们必须确保这不是伪装成您的人...
也就是说，验证密钥有效性的唯一真正万无一失的方法是自己生成它...除非您的硬件/操作系统/编译器/大脑受到损害也 ：）
Under the scheme you just proposed, you can't. The key here (no pun intended) is if the method used to verify the validity of the keys is compromised, you lose.
SSL tries to avoid this by creating a signature chain - some (very carefully guarded, and verified by other methods) key signs another key, signs another key, signs Alice's key. By verifying each step in the chain you can (in principle) know that the chain is valid - but if the private key along any step in the chain is compromised, you lose.
PGP (aka GPG) tries to solve the problem in a different, but similar way - keys can be signed by any number of other keys, forming a graph (called the web of trust). You select some keys that you have confirmed valid by, for example, verifying them in person, and mark them as trusted. Then any keys reachable by less than N steps (and/or from M distinct paths from different trusted roots) are also considered valid.
If you're really paranoid, you can, of course, physically hand the key to the other person. Of course, they have to be sure it's not someone disguised as you...
That said, the only truly foolproof way of verifying the validity of a key is generating it yourself... unless your hardware/OS/compiler/brain is compromised too :)
这里缺少的关键部分是身份验证。 Alice 需要一种方法来知道她确实在使用 Bob 的公钥。一种方法是亲自交换密钥，但这并不总是可行。
这就是信任网的用途。如果其他方确信该密钥属于用户，则可以对该用户的公钥进行签名。如果您信任的足够 (3) 个其他联系人签署了 Bob 的公钥，您就可以相对确定这是他的密钥。
The crucial part missing here is authentication. Alice needs a way to know that she is really using Bobs public key. One way would be to exchange the keys personally but that is not always possible.
That is what the Web of Trust is for. Other parties can sign the public key of a user if they are sure that this key belongs to him. If enough (3) of your other contacts (which you trust) signed the public key of Bob, you can be relatively sure that it is his key.
这是公钥加密的主要问题。您没有任何方法来验证您收到的公钥实际上是您的预期收件人的公钥。 HTTPS/SSL 解决此问题的方法是使用受信任的证书颁发机构。证书颁发机构使用相关方的私钥对公钥进行签名，以保证公钥自提供给证书颁发机构以来未曾更改。即使这样，也只能保证您请求时提供给您的密钥与最初提供给证书颁发机构的密钥相同。但是，如果提供这些证书的服务器遭到破坏，您仍然会遇到麻烦。如果服务器本身受到损害，即使按照上面的建议让服务器对密钥进行签名也不是万无一失的。最终，如果必须维护密钥分发服务器的安全性才能使该系统正常工作。
This is the primary problem with public key encryption. You don't have any way to verify that the public key you receive is actually the public key for your intended recipient. The way HTTPS/SSL gets around this is through the use of trusted certificate authorities. The certificate authority signs the public key of the party in question with their private key, guaranteeing that the public key hasn't been changed since it was provided to the certificate authority. Even then, it is only guaranteed that the key provided to you when you request it is the same key that was originally provided to the certificate authority. However, if the server providing those certificates is compromised, you're still in trouble. Even having the server sign the keys as suggested above isn't fool proof if the sever itself is compromised. Ultimately, the security if your key distribution server must be maintained for this system to work.
PGP（良好隐私）常见问题解答解释了此问题。
我还建议阅读 Bruce Schneier 的优秀著作“应用密码学”，以实现“友好且易于理解” ”这些话题的讨论。
The FAQ for PGP (Pretty Good Privacy) explains this issue.
I would also recommend reading Bruce Schneier's excellent book "Applied Cryptography" for "friendly and digestible" discussions of these topics.