服务器上的密文
是否有任何协议可以允许 2 位访问者通过我的网站安全地进行通信，而我却无法阅读他们的消息？
Are there any protocols which would allow 2 visitors to communicate securely through my website, without the possibility of me reading their messages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
向 Google 请求端到端加密，例如 PGP/GPG。对于基于客户端浏览器的实现，您可能需要查看JavaScript 中的 GPG 加密。
我只是用谷歌搜索了一下，无法判断它是否真的安全（不会将您的私钥发送给任何人）。我只想给你一个开始的要点。
编辑：看起来它确实将客户端私钥发送到您的服务器以执行基于服务器的加密。这不是您想要的。但我确信 GPG 的 JavaScript 实现是可能的，尽管我不知道是否有人已经做到了。
Ask Google for End-to-End encryption like PGP/GPG. For a client-side browser-based implementation you might want to check out GPG encryption in JavaScript.
I just googled it and cannot tell if its really secure (not sending your private key to anyone). I just want to give you a point to start with.
EDIT: Looks like it does send the clients private key to your server to perform a server-based encryption. This is not what you want. But I am sure that a JavaScript implementation of GPG is possible even though I don't know if somebody has done it yet.
是的;例如，如果您的服务器是受 SSL/TLS 保护的通信中的链接，就会发生这种情况。
参与者使用公钥加密方案来商定秘密的对称密钥；然后用于加密他们的通信。
参与者也可以简单地使用目标接收者的公钥加密他们的消息。这样，只有预期的接收者才能解密该消息。这不是一个非常先进的方案，并且可能很容易受到攻击。 （除此之外，如果窃听者可以准确地猜测发送的内容，他可以使用预期接收者的公钥加密该消息，并查看结果是否与发送的内容匹配）。
有很多关于加密协议的文献；首先，这里有一篇关于密钥协议协议的维基百科文章。
Yes; for example, this is what would happen if your server was a link in a communication protected by SSL/TLS.
The participants use a public-key encryption scheme to agree upon a secret, symmetric key; that is then used to encrypt their communication.
It's also possible for the participants to simply encrypt their messages with the public key of the intended receiver. That way, only the intended receiver can decrypt the message. This is not a very advanced scheme and probably vulnerable. (Among others, if an eavesdropper can guess exactly what is sent, he can encrypt that message with the intended recipient's public key and see if the result matches with what is being sent).
There is a lot of literature available on cryptographic protocols; for starters, here's a Wikipedia article on Key Agreement Protocols.
如果我们谈论的是不可能，那么 SL Barth 答案的第二部分将实现这一目标，但密钥交换必须通过其他方式完成。这可以是电话或电子邮件，甚至是另一个网站，但如果是通过您的网站完成的，那么它会向 中间人攻击。您可以告诉您的用户这样做，但您实际上无法帮助他们这样做。
某处可能有一个 javascript 库可以实现 GPG 加密，因此您所要做的就是确保每条消息在发送到您的 Web 服务器之前都在浏览器中进行了加密。您可以根据需要存储消息，它们是加密的。只有拥有正确私钥的用户才能解密它。
世界各地的网站使用的 SSL 和 TLS 很容易受到中间人攻击。我们很少听说此类攻击的原因是，大多数中间人都是值得信赖的，因此攻击根本不会发生。最近吊销 DigiNotar 等公司的 CA 证书正是因为伊朗政府被发现充当中间人解密其公民的 SSL 流量。
如果您愿意防止好奇的系统管理员随意窥探，则也可以通过您的网站完成密钥交换。
还有一件事：安全很难。
即使您使用众所周知的加密技术来执行此操作，实施中出现缺陷的可能性也将非常接近 1。这并不意味着那些好奇的系统管理员将能够意外读取消息，但这确实意味着坚定而熟练的对手将能够找到进入的方法。只要您能负担得起，您就应该聘请专家来重新设计或至少检查您的协议和实施。
If we're talking about not possible then the second part to S.L. Barth's answer will achieve this with the exception that the key exchange must be done by some other means. This can be the phone or email or even another website but if it's done via your website then it's open to a man-in-the-middle attack. You can tell your users to do this, you just can't actually help them do it.
There is probably a javascript library somewhere that will implement GPG encryption so that all you have to do is make sure that every message is encrypted in the browser before it's sent to your web server. You can store the messages as long as you like, they're encrypted. Only the user with the correct private key will be able to decrypt it.
SSL and TLS as they are used by websites everywhere are vulnerable to man-in-the-middle attacks. The reason we don't hear much about these sorts of attacks is that most of the people in the middle are trustworthy so the attacks simply don't happen. The recent revoking of the CA certificates of DigiNotar and others was precisely because the Iranian Government were caught acting as a man-in-the-middle and decrypting their own citizen's SSL traffic.
If you're happy with preventing casual snooping by curious sysadmins, the key exchange can be done through your website as well.
One more thing: Security is hard.
Even if you do this with well-known encryption techniques, the chances of there being a flaw in the implementation will be very close to 1. This doesn't mean that those curious sysadmins will be able to accidentally read messages but it does mean that a determined and skilled adversary will be able to find a way in. As soon as you can afford it you should hire an expert to redesign or at the very least examine your protocol and implementation.
一般来说，只有当用户有某种方式相互识别（或至少在一个方向上）时，用户之间的这种安全链接才可能实现，而您无法读取和/或修改他们的消息。
这可能是共享秘密（如密码）或一个人已知的公钥（或由一个人已知的 CA 认证），其中另一个人拥有相应的私钥。
在此之上可以构建一个安全协议（使用密钥交换，然后使用双向 MAC 进行对称加密），就像 TLS 一样。 （另一种经常用于即时消息传递的方式是 OTR，非记录消息传递< /a> 协议。）
如果没有办法识别另一个端点，您最终会得到一种允许中间人攻击的方法。没有证书的 SSL/TLS 或带有中间人知道相应私钥的证书的 SSL/TLS 是不安全的，就像所有其他类似的加密方案一样。
另一个问题是您所说的我网站的访问者。这看起来就像您将在 JavaScript 中实现从您的网站交付的客户端加密技术。不要这样做……如果访问者不相信你不会读取他们的数据，他们也不应该相信你会向他们提供非恶意的 JavaScript，这可能会实现一些与你声称的不同的东西，再次允许MITM，甚至直接将数据副本发送给您。
有关此问题的更多详细信息，请参阅 Javascript 加密技术被认为有害（从稍微不同的角度） 。
In general, such a secure link between your users without you being able to read and/or modify their messages is only possible if they have some way of identifying each other (or at least in one direction).
This might be a shared secret (like a passphrase) or a public key known to one (or certified by a CA known to one), where the other one has the corresponding private key.
On this one can build a secure protocol (using a key exchange and then symmetric encryption with MACs in both directions), like TLS does. (Another way, used often for instant messaging, is OTR, the Off-the-Record messaging protocol.)
Without a way to identify the other end point, you end up with a way of allowing man-in-the-middle attacks. SSL/TLS without certificates, or with certificates where the man-in-the-middle knows the corresponding private key, is insecure, as is every other similar encryption scheme.
Another issue is that you said visitors of my website. This looks like you would implement client-side cryptography in JavaScript, delivered from your website. Don't do this ... if the visitors do not trust you not to read their data, they also should not trust you to feed them non-malicious JavaScript, which might implement something else than you are claiming it does, again allowing a MITM, or even directly sending a copy of the data to you.
More details about this are discussed in Javascript Cryptography Considered Harmful (from a slightly different perspective).