☰

有什么理由不在网站上强制实施 HTTPS 吗？

tag-icon • tag-icon ssl hsts
有什么理由不在网站上强制实施 HTTPS 吗？

我经常访问的一个网站最终决定在其服务器上启用 TLS，但不像其他许多网站那样强制要求这样做。维护者声称 TLS必须是可选的。为什么？

我在自己的网站上长期设置了强制 TLS 和 HSTS，并禁用了较弱的密码套件。使用 HTTP 301 确保明文访问被阻止，以阻止 TLS 保护版本。这会对我的网站产生负面影响吗？

答案1

使用 TLS 有几个很好的理由

（并且只有少数边缘理由不这样做）。

  • 如果站点有任何身份验证，则使用 HTTP 暴露来窃取会话和密码。

  • 即使在静态的、仅仅是信息的网站，使用 TLS 也能确保没有人篡改数据。

  • 自从2014 年 Google I/O 大会，Google 已采取多项措施鼓励所有网站使用 HTTPS：

  • Mozilla 安全博客还宣布弃用非安全 HTTP通过制作所有新功能仅适用于安全网站和逐步淘汰对不安全网站的浏览器功能的访问，尤其是对用户安全和隐私构成风险的功能。

实施 TLS 也有几个很好的理由

如果你已经拥有一个广受信任的证书，为什么不一直使用它呢？几乎所有当前的浏览器都支持 TLS 并安装了根证书。多年来我真正看到的唯一兼容性问题是 Android 设备和缺少中级证书颁发机构因为 Android 只直接信任根 CA。只需配置服务器将证书链发送回根 CA，即可轻松防止这种情况。

如果你的维护者仍然希望允许没有直接的 HTTP 连接301 Moved Permanently，比如为了确保从一些非常老的浏览器或移动设备进行访问，浏览器根本无法知道你配置了 HTTPS。此外，您不应该部署HTTP 严格传输安全 (HSTS)没有301 Moved Permanently：

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

为两种协议配置的各种站点的问题已被认识到Tor 项目和电子前沿基金会并由多浏览器处理无处不在的 HTTPS扩大：

网络上的许多网站都提供有限的 HTTPS 加密支持，但使用起来却很困难。例如，它们可能默认使用未加密的 HTTP，或者在加密页面中填充指向未加密网站的链接。

混合内容这也是一个巨大的问题，因为可能通过修改通过非安全 HTTP 连接加载的 JavaScript 或 CSS 对 HTTPS 站点进行 XSS 攻击。因此，现在所有主流浏览器都会警告用户有关混合内容的页面，并拒绝自动加载。这使网站维护变得困难无需301HTTP 重定向：您必须确保每个 HTTP 页面仅加载 HTTP 内容（CSS、JS、图像等），并且每个 HTTPS 页面仅加载 HTTPS 内容。如果两个页面的内容相同，则很难实现这一点。

答案2

在当今时代，TLS + HSTS 标志着您的网站是由值得信赖的专业人士管理的。这是可信度的新兴最低标准，正如 Google 表示将为这样做的网站提供积极的排名所证明的那样。

另一端是最大程度的兼容性。仍有较旧的客户端，特别是在美国、欧洲或中国以外的地区。纯 HTTP 始终有效（尽管并非总是有效出色地；那是另一个故事）。

TLS + HSTS：优化搜索引擎排名
普通 HTTP：优化兼容性

取决于什么对你更重要。

答案3

有一个很好的理由只读网站不使用 HTTPS。

  • Web 缓存无法缓存通过 HTTPS 传输的图像。
  • 世界上有些地区的国际连接速度非常低，因此依赖于缓存。
  • 托管来自其他域名的图片需要一定的技能，这是你不能指望小型运营商的只读网站。

答案4

这一切都取决于您的安全要求、用户选择和隐性降级的风险。禁用服务器端的旧密码在很大程度上是必要的，因为浏览器会以用户体验/便利的名义欣然接受客户端绝对糟糕的密码。确保您的密码不会依靠当然，通过安全通道向用户发送信息使得不安全的方法无法联系到用户也是非常合理的。

不允许我明确降级到不安全的 HTTP，因为我认为你关于为什么你更喜欢 Python 而不是 Ruby（并不是说你喜欢，只是一个普通的例子）的博客文章并不是我介意让间谍或公众知道我访问过的东西，这只是毫无理由地妨碍我，假设 HTTPS 对我来说是微不足道的。

如今，有些嵌入式系统无法开箱即用地使用 TLS，或者仍然停留在旧的实现上（我认为这种情况非常糟糕，但作为 [在此处插入嵌入式设备] 的高级用户，我有时无法改变这种情况）。

这是一个有趣的实验：尝试通过 HTTPS 从上游 OpenBSD 站点下载最新版本的 LibreSSL，该站点具有足够旧的 TLS/SSL 实现。您将无法下载。前几天，我在一台装有 2012 年左右的旧 OpenSSL 版本的设备上尝试过，因为我想将这个嵌入式系统从源代码升级到更安全的新东西 - 我没有预构建的软件包。我尝试时出现的错误消息并不完全直观，但我认为这是因为我的旧 OpenSSL 不支持正确的东西。

这是一个仅使用 HTTPS 的举动实际上会损害人们利益的例子：如果您没有最近预构建的软件包，并且想通过从源代码构建来自己解决问题，那么您就被锁定了。幸运的是，在 LibreSSL 的情况下，您可以回退到明确请求 HTTP。当然，这不会使您免受已经重写您的流量的攻击者的攻击，攻击者能够用受损版本替换源包并重写 HTTP 主体中描述您浏览的网页上可供下载的软件包的所有校验和，但在更常见的情况下它仍然有用。

我们大多数人都不会因为一次不安全的下载就被 APT（高级持久线程：国家情报机构和其他资源极其丰富的网络威胁的安全术语）控制。有时我只想将wget一些纯文本文档或一个小程序（例如，我自己在 GitHub 上的小实用程序/脚本）放到一个不支持最新密码套件的盒子上，我可以快速审核其源代码。

就我个人而言，我想问的是：您的内容是否足以让某人合法地决定“我可以访问公共知识”？非技术人员意外降级到 HTTP 以获取您的内容是否真的存在风险？权衡您的安全要求、强制用户隐私要求和隐性降级风险，以及了解风险的用户逐案做出明智选择的能力。完全可以合理地说，对于您的网站，没有理由不强制执行 HTTPS - 但我认为可以公平地说，纯 HTTP 仍然有很好的用例。

相关内容