使用 https 时防止中间人攻击
我正在写一个类似于 omegle 的小应用程序。我有一个用Java编写的http服务器和一个html文档客户端。主要的通信方式是通过http请求（长轮询）。
我通过使用 https 协议实现了某种安全性，并且为连接到服务器的每个客户端都有一个 securityid。当客户端连接时，服务器会为其提供一个 securityid，客户端在需要请求时必须始终将其发回。
我担心这里的中间人攻击，您对如何保护应用程序免受此类攻击有什么建议吗？
请注意，此应用程序是出于理论目的而构建的，不会出于实际原因而使用它，因此您的解决方案不一定是实用的。
I am writing a little app similar to omegle. I have a http server written in Java and a client which is a html document. The main way of communication is by http requests (long polling).
I've implemented some sort of security by using the https protocol and I have a securityid for every client that connects to the server. When the client connects, the server gives it a securityid which the client must always send back when it wants a request.
I am afraid of the man in the middle attack here, do you have any suggestions how I could protect the app from such an attack.
Note that this app is build for theoretical purposes, it won't be ever used for practical reasons so your solutions don't have to be necessarily practical.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
HTTPS不仅可以进行加密，还可以对服务器进行身份验证。当客户端连接时，服务器会显示其域具有有效且可信的证书。该证书不能简单地被中间人欺骗或重播。
HTTPS does not only do encryption, but also authentication of the server. When a client connects, the server shows it has a valid and trustable certificate for its domain. This certificate can not simply be spoofed or replayed by a man-in-the-middle.
仅仅启用 HTTPS 是不够的，因为网络带来了太多的复杂性。
一方面，请确保在 cookie 上设置安全标志，否则它们可能会被盗。
确保用户仅通过在地址栏中键入
https://来访问该网站也是一个好主意，这是确保使用有效证书进行 HTTPS 会话的唯一方法。当您输入https://时，浏览器将拒绝您访问该网站，除非服务器为如果您只输入
攻击者重定向到某个具有相似名称的 unicode 域（即：看起来相同，但具有不同的二进制字符串，因此是不同的域），然后攻击者为该域提供了有效的证书（因为他拥有该证书），用户可能不会注意到这一点...
攻击者可以模拟服务器，但是如果没有 HTTPS，他会建立自己与真实服务器的安全连接，并成为您和服务器之间的明文代理，他现在可以捕获您的所有流量并做任何他想做的事情，因为他拥有您的会话。
Simply enabling HTTPS is not good enough because the web brings too many complications.
For one thing, make sure you set the secure flag on the cookies, or else they can be stolen.
It's also a good idea to ensure users only access the site via typing
https://<yourdomain>in the address bar, this is the only way to ensure an HTTPS session is made with a valid certificate. When you typehttps://<yourdomain>, the browser will refuse to let you on the site unless the server provides a valid certificate for<yourdomain>.If you just type
<yourdomain>without https:// in front, the browser wont care what happens. This has two implications I can think of off the top of my head:The attacker redirects to some unicode domain with a similar name (ie: looks the same but has a different binary string and is thus a different domain) and then the attacker provides a valid certificate for that domain (since he owns it), the user probably wouldn't notice this...
The attacker could emulate the server but without HTTPS, he would make his own secured connection to the real server and become a cleartext proxy between you and the server, he can now capture all your traffic and do anything he wants because he owns your session.