时间戳

首页 > 解决方案 > 如何将 HTTPS 重定向到不安全的 WS？

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

问题描述

出于安全考虑，我可能做的不对，所以请务必通知我。

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

因此，用户在这个 HTTPS 站点上会获得一个 url，例如ws://203.48.15.199:3422. 有什么办法可以让这种联系发生吗？

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

有任何想法吗？

标签： securitysslhttpswebsocket

解决方案

有什么办法可以让这种联系发生吗？

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

推理相当直截了当：它首先破坏了 HTTPS 的目的。

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

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

是的。您可以为要允许代理的第 3 方设置代理服务器。互联网上散布着许多这样的 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. 最好的解决方案是将负担转移到第 3 方。设置正确的 HTTPS。这是最有益的，因为它完全符合 HTTPS 的目的。
  3. 在可以代理它。需要注意的是，从您的代理到第三方仍然不安全，您现在需要管理代理服务器。Nginx 使这变得相当容易。
  4. 如果您使用代理路由，请确保它的配置方式不会被滥用。

如果我需要 SSL，这是否意味着他们不能只发布要连接的 IP？

获取 HTTPS 证书需要域名。更具体地说，为 IP 地址获取证书是可能的，但它非常不同寻常，而且比为域名获取证书要付出更多的努力。

又多了多少负担？

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

暴露 HTTPS 的过程可以完全自动化吗？

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

还有其他使用的 Web 服务器更进一步。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 会以自动方式为 IP 地址颁发证书，例如 Let's Encrypt / CertBot。

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

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

推荐阅读