security - 如何将HTTPS重定向到不安全的WS？

Question

为了安全起见，我可能没有做正确的事，所以请告知我。

用户访问该站点（并被迫使用HTTPS）。有效证书。他们通过WSS连接到“中间人”服务器。第三方组织将普通的WS服务器公开到Internet，并将其公共地址/端口广播到“中间人”服务器，然后将其广播给用户。

因此，该HTTPS站点上的用户将获得一个URL，例如ws://203.48.15.199:3422。有什么办法可以允许这种连接发生？

一种这样的方法是允许“中间人”也成为代理-每个第三方服务器地址在启用WSS的中端服务器上分配一个路径。用户将连接到wss://example.com/somepath，而我将其简单地代理回给第三方，不安全的websocket。缺点是我必须维护该代理，这违背了允许第三方甚至运行自己的服务器的目的。

有任何想法吗？

Answer 1

有什么办法可以允许这种连接发生？


这是active mixed content的形式。所有最新的浏览器such as Firefox和Google Chrome都禁止此类内容，就像它们禁止安全页面（HTTPS加载页面）加载不安全的JavaScript一样。

推理是相当直接的：首先破坏了HTTPS的目的。

解决此问题的“正确”方法是也强制所有第3方在其网络套接字上使用HTTPS并避免整个问题。


  一种这样的方法是允许“中间人”也可以作为代理


是。您可以为要允许代理的第三方设置代理服务器。互联网上散布着许多nginx的例子。一个简单的示例可能是：

# untested configuration

server {
  listen 443 ssl;
  ssl_certificate /etc/ssl/certs/cert.pem;
  ssl_certificate_key /etc/ssl/private/cert.key;

  location /3rdpartyproxy {
    proxy_pass http://203.48.15.199:3422;
    proxy_http_version 1.1;
    proxy_set_header Upgrade websocket;
    proxy_set_header Connection upgrade;
  }
}

这样的事情可能会起作用，但是请记住，这并不符合用户的最大利益。您的代理与第三方之间的连接仍然不安全，并且容易受到常规HTTP所具有的所有相同攻击的攻击。

需要注意的另一件事是确保其他方没有错误使用您的代理。我见过有人用动态路径设置代理，并将该流量代理到任何地方。就像是：

ws://myproxy.example/203.48.15.199/3422

然后配置Web服务器以将其代理到URL中的内容。这似乎是一个不错的解决方案，因为它将根据URL的不同来执行正确的操作。它的主要缺点是，除非您对代理进行某种身份验证，否则任何人都可以使用它在任何地方代理流量。

总结一下：


您不能在https：页面上使用ws:。
最好的解决方案是将负担转移到第三方。设置正确的HTTPS。这是最有益的，因为它完全可以满足HTTPS的目的。
在可以代理它。需要注意的是，从代理服务器到第三者仍然不安全，现在需要管理代理服务器。 Nginx使这变得相当容易。
如果您使用代理路由，请确保其配置方式不被滥用。



  如果我需要SSL，这是否意味着他们将无法仅发布要连接的IP？


获取HTTPS证书需要一个域名。更具体地说，可以获取IP地址证书，但这与众不同，并且比获取域名证书要付出更多的努力。


  这又是多少负担？


这主要是一个见解，但这将意味着选择一个域名，进行注册，并向注册服务商支付维持注册的费用。费用各不相同，但是如果一个域名没有什么特别的，通常一个域名的年费不到15美元。


  公开HTTPS的过程可以完全自动化吗？


现在，获取HTTPS证书几乎可以自动进行。 Let's Encrypt免费提供HTTPS证书（真的，免费，没有字符串，现在是非常流行的证书颁发机构）。他们的方法有些不同。他们颁发3个月的证书，但使用名为CertBot的软件来自动更新和安装证书。由于该过程是完全自动化的，因此证书有效期的持续时间并不重要，因为所有这些都将在后台自动更新。

还有其他使用此功能的Web服务器。 Apache supports ACME（“让我们加密”使用的协议）现在本机使用。 Caddy是另一个将HTTPS配置完全简化到极致的Web服务器。

对于您的第三方，您可以考虑给他们提供一些示例，这些示例已经为各种Web服务器正确设置了HTTPS。


  我希望对“ IP地址证书”的可能性多加说明，因为我觉得您对此感到有些困惑。


证书的IP地址是可以的，但对于公共访问的网站却极为罕见。 https://1.1.1.1是最近的示例。

最终，CA必须验证依赖方（请求证书的个人或组织）可以证明对IP地址的控制。 CA/B Requirements的第3.2.2.5节描述了如何完成此操作，但实际上，这要由CA来验证IP地址的所有权。因此，“域验证”证书不适用于具有IP地址的证书。取而代之的是，至少需要“组织验证”证书或OV。 OV证书的颁发更加严格，无法自动执行。除了证明IP地址的所有权外，您还需要提供依赖方身份的文件，例如个人的驾驶执照或组织的税收文件。


“让我们加密”不会为IP地址颁发证书，因此您可能必须找到将颁发证书的其他CA，并可能需要为它们付费。为IP地址注册域名可能会更具成本效益。
我不知道有任何CA会以类似Let's Encrypt / CertBot的自动方式为IP地址颁发证书。
使用域名可提供更大的灵活性。如果需要更改IP地址，则只需更新DNS中的A / AAAA记录即可。如果证书用于IP地址，则将需要颁发新证书。
对于某些软件和浏览器，证书中的IP地址存在历史兼容性问题。