是否有任何理由不在网站上强制执行 HTTPS？

Question

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

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

Answer 1

在这个时代，TLS + HSTS 是您的站点由可信赖的专业人员管理的标志，他们知道他们在做什么。这是一个新兴的可信度最低标准，谷歌表示他们将为这样做的网站提供正面排名就证明了这一点。

另一方面是最大的兼容性。仍然有老客户，尤其是在美国、欧洲或中国以外的世界部分地区。普通HTTP将始终工作（虽然并不总是工作良好，这是另一回事）。

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

取决于什么对你更重要。

Answer 2

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

• Web 缓存无法缓存通过 HTTPS 传输的图像。
• 世界上的某些地区的国际连接速度非常低，因此请依赖缓存。
• 托管来自其他域的图像需要您无法期望小型只读网站的运营商拥有的技能。

Answer 3

维护者声称 TLS 必须是可选的。为什么？

要真正知道这个问题的答案，你必须问他们。然而，我们可以做出一些猜测。

在企业环境中，IT 部门通常会安装防火墙来检查传入和传出的流量是否存在恶意软件、可疑的类似 CnC 的活动、被认为不适合工作的内容（例如色情内容）等。当流量被加密时，这会变得更加困难。基本上有三种可能的反应：

1. 放弃监控此流量。
2. 在用户的机器上安装根 CA，以便您可以执行 MitM 解密和检查。
3. 批发块加密流量。

对于关心的系统管理员来说，这些选项都不是特别有吸引力。攻击公司网络的威胁有很多，保护公司免受威胁是他们的工作。但是，完全阻止大量站点会激起用户的愤怒，安装根 CA 可能会让人觉得有点卑鄙，因为它为用户引入了隐私和安全方面的考虑。我记得在他们第一次打开 HSTS 时看到（抱歉，找不到线程）一个系统管理员请愿书 reddit，因为他正是在这种情况下，并且不想仅仅因为他被业务所迫而阻止所有 reddit阻止以色情为重点的 subreddits。

技术的车轮不断向前发展，您会发现许多人认为这种保护是过时的，应该逐步淘汰。但是仍然有很多人在实践它，也许你的神秘维护者关心的就是他们。

Answer 4

使用 TLS 有几个很好的理由

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

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

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

• 自Google I/O 2014以来，Google 采取了多项措施来鼓励所有网站使用 HTTPS：

  • 谷歌一直在帮助网站管理员配置他们的服务器更安全，但也使用HTTPS 作为排名信号。
  • 最近，谷歌浏览器已开始将 HTTP 站点标记为不安全，这是将所有 HTTP 站点标记为不安全的长期计划的一部分。
  • Google Chrome Developers 团队的 Mythbusting 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 Everywhere扩展解决：

网络上的许多站点对 HTTPS 加密提供了一些有限的支持，但使其难以使用。例如，它们可能默认使用未加密的 HTTP，或者使用返回未加密站点的链接填充加密页面。

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

Answer 5

这一切都取决于您的安全要求、用户选择和隐式降级的风险。在服务器端禁用旧密码在很大程度上是必要的，因为浏览器会以用户体验/方便的名义很高兴地陷入绝对可怕的客户端密码。确保您的任何依赖于安全通道的用户都无法通过不安全的方法访问，当然，这也是非常合理的。

不允许我明确降级到不安全的 HTTP 当我认为你的博客文章关于为什么你喜欢 Python 而不是 Ruby（不是说你喜欢，只是一个通用的例子）不是我介意幽灵或公众知道的事情我访问只是无缘无故地妨碍了我，假设 HTTPS 对我来说是微不足道的。

今天，有些嵌入式系统无法开箱即用地使用 TLS，或者那些卡在旧实现上的系统（我认为这是非常糟糕的，但作为 [insert Embedded设备在这里]，我有时无法改变这一点）。

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

这是一个示例，其中唯一的 HTTPS 移动实际上会损害人们的利益：如果您没有最新的预构建包，并且想通过从源代码构建来自己解决问题，那么您将被锁定。幸运的是，在 LibreSSL 的情况下，您可以回退到显式请求 HTTP。当然，这不会使您免于已经重写您的流量的攻击者，能够用受损版本替换源包并重写 HTTP 正文中的所有校验和，描述可在您浏览的网页上下载的包，但它在许多情况下仍然很有用更常见的情况。

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

就个人而言，我会问：您的内容是否可以让人们合法地决定“我可以访问公共知识”？非技术人员不小心将您的内容降级到 HTTP 是否存在真正的风险？权衡您的安全要求、为您的用户实施的隐私要求和隐式降级风险，以及了解风险的用户在逐案基础上做出明智选择的能力。可以说，对于您的网站，没有充分的理由不强制实施 HTTPS，这是完全合理的 - 但我认为可以公平地说，那里仍然存在纯 HTTP 的良好用例。