如何使用不受信任的主机跨防火墙代理安全连接？
我面临一个有趣的网络安全挑战，我无法找出最佳的攻击方法。
我需要提供一种方法，允许防火墙后面的两台计算机（A 和 B）仅使用互联网上的通用“代理”不受信任服务器（例如 RackSpace）相互建立安全连接。 （服务器被认为是不可信的，因为防火墙后面的客户不会信任它，因为它位于开放服务器上）我无法调整防火墙设置以允许网络直接相互连接，因为连接在之前是未知的时间。
这与远程桌面帮助工具（crossloop、copilot 等）处理的 NAT 到 NAT 连接问题非常相似。
我真正想要找到的是一种在两台主机之间打开 SSL 连接并让公共服务器代理连接的方法。最好当主机 A 尝试连接到主机 B 时，它应该必须提供一个令牌，代理可以在建立连接之前与主机 B 进行检查。
更糟糕的是，连接机制需要支持两种类型的通信。首先，对 REST Web 服务的 HTTP 请求/响应，以及第二个持久套接字连接，以允许实时消息传递。
我查看了我所知道的技术，例如使用证书的 OpenSSL、OAuth 等，但我没有看到任何可以完全满足我需要的技术。
以前有其他人处理过类似的事情吗？有什么指点吗？
I have an interesting network security challenge that I can't figure out the best way to attack.
I need to provide a way to allow two computers (A and B) that are behind firewalls to make a secure connection to each other using only a common "broker" untrusted server on the internet (somewhere like RackSpace). (the server is considered untrusted because the customers behind the firewalls won't trust it since it is on an open server) I can not adjust the firewall settings to allow the networks to directly connect to each other because the connections are no known ahead of time.
This is very similar to a NAT to NAT connection problem like that handled by remote desktop help tools (crossloop, copilot, etc).
What I would really like to find is a way to open an SSL connection between the two hosts and have the public server broker the connection. Preferably when host A tries to connect to host B, it should have to provide a token that the broker can check with host B before establishing the connection.
To add another wrinkle to this, the connection mechanism needs to support two types of communication. First, HTTP request/response to a REST web service and second persistent socket connection(s) to allow for real-time message passing.
I have looked at the techniques I know about like OpenSSL using certificates, OAuth, etc, but I don't see anything that quite does what I need.
Has anyone else handled something like this before? Any pointers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用普通 SSL 解决您的问题。
只需让不受信任的服务器将客户端主机之间的连接转发为不透明的 TCP 连接即可。然后，客户端通过转发的 TCP 隧道建立端到端 SSL 连接 - 使用 OpenSSL，一个客户端调用
SSL_accept()，另一个客户端调用SSL_connect()。使用证书（可能包括客户端证书）来验证 SSL 连接的另一端是否是您所期望的。
（这在概念上类似于 HTTPS 连接在 Web 代理上的工作方式 - 浏览器只是说“将我连接到此目的地”，并与所需端点建立 SSL 连接。代理只是前后转发加密的 SSL 数据，并且由于它没有正确证书的私钥，因此它无法模拟所需的端点）。
You can solve your problem with plain SSL.
Just have the untrusted server forward connections between the client hosts as opaque TCP connections. The clients then establish an end-to-end SSL connection over that forwarded TCP tunnel - with OpenSSL, one client calls
SSL_accept()and the other callsSSL_connect().Use certificates, probably including client certificates, to verify that the other end of the SSL connection is who you expect it to be.
(This is conceptually similar to the way that HTTPS connections work over web proxies - the browser just says "connect me to this destination", and establishes an SSL connection with the desired endpoint. The proxy just forwards encrypted SSL data backwards and forwards, and since it doesn't have the private key for the right certificate, it can't impersonate the desired endpoint).
一般来说，SSL 是基于数据包的协议（为了解决您的任务）。如果您可以让主机来回转发数据包，您就可以轻松拥有 SSL 保护的通信通道。您需要的一件事是我们的 SSL/TLS 组件，它允许任何传输不仅仅是套接字。即该组件告诉您的代码“将此数据包发送到另一端”或“您有什么要我接收的吗？”并且您的代码与中间服务器进行通信。
In general, SSL is packet-based protocol (for the purpose of solving your task). If you can have the host forward the packets back and forth, you can easily have SSL-secured communication channel. One thing you need is something like our SSL/TLS components, which allow any transport and not just sockets. I.e. the component tells your code "send this packet to the other side" or "do you have anything for me to receive?" and your code communicates with your intermediate server.