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

Question

我可能没有做正确的事情，安全方面，所以请告诉我。

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

因此，用户在此 HTTPS 站点上获取诸如 之类的 url ws://203.48.15.199:3422。有什么办法可以允许这种连接发生吗？

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

有任何想法吗？

Answer 1

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

这是一种活跃的混合内容形式。所有最新的浏览器（例如 Firefox和 Google Chrome）都禁止此类内容，就像它们禁止安全页面（HTTPS 加载的页面）加载不安全的 JavaScript 一样。

推理相当简单：它首先破坏了 HTTPS 的目的。

解决此问题的“正确”方法是强制所有第三方在其 Websocket 上使用 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;
  }
}

类似的方法可能有效，但请记住，这不符合用户的最佳利益。您的代理和第 3 方之间的连接仍然不安全，并且容易受到与常规 HTTP 相同的攻击。

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

ws://myproxy.example/203.48.15.199/3422

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

总结一下：

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

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

获取HTTPS证书需要域名。更具体地说，获取 IP 地址的证书是可能的，但这非常不寻常，而且比获取域名的证书要费力得多。

又是多少的负担呢？

这主要是一个意见问题，但这意味着选择一个域名，注册它，并支付费用以维持向注册商的注册。费用各不相同，但如果域名没有什么特别之处，通常每年花费不到 15 美元。

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

现在获取 HTTPS 证书基本上可以自动化。Let's Encrypt免费提供 HTTPS 证书（真的，免费，无字符串，现在是广受欢迎的证书颁发机构）。他们的方法有点不同。他们颁发 3 个月的证书，但使用名为CertBot的软件来自动更新和安装证书。由于该过程完全自动化，因此证书的有效期并不重要，因为它只是在后台自动更新。

还有其他网络服务器使用更进一步。Apache现在原生支持 ACME（Let's Encrypt 使用的协议）。Caddy是另一个将 HTTPS 配置做到极致简单的 Web 服务器。

对于您的第 3 方，您可以考虑向他们提供为各种 Web 服务器正确设置 HTTPS 的配置示例。

我希望对“IP 地址证书”的可能性有更多的描述，因为我觉得你掩盖了它。

证书的 IP 地址是可能的，但对于可公开访问的网站来说极其罕见。https://1.1.1.1是最近的一个例子。

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

1. Let's Encrypt 不会为 IP 地址颁发证书，因此您可能必须找到其他 CA 来颁发证书，并且可能需要付费。为 IP 地址注册域名可能会更具成本效益。

2. 我不知道有哪个 CA 会像 Let's Encrypt / CertBot 这样以自动方式为 IP 地址颁发证书。

3. 使用域名可以提供更大的灵活性。如果需要更改 IP 地址，只需更新 DNS 中的 A/AAAA 记录即可。如果证书用于 IP 地址，则需要颁发新证书。

4. 某些软件和浏览器的证书中的 IP 地址历史上存在兼容性问题。