为什么浏览器默认使用 http: 而不是 https: 来输入 URL？

信息安全 tls 网页浏览器
2021-08-21 10:08:17

当我example.com在浏览器栏中输入没有任何方案并按 Enter 时，它被解释为HTTP://example.com, not HTTPS://example.com。为什么？解决这个问题的计划在哪里？

（需要明确的是，我只是在谈论来自“懒惰”用户的键入/粘贴的地址，而不是关于软件定义的操作，例如遵循相对于方案的 URLwindow.location = "url"等。显然键入/粘贴HTTP://example.com必须仍然有效。）

编辑：正如一些答案指出的那样，网站已经可以通过重定向 + HSTS 来实现这一点。核心技术收益将缩小首次连接问题（HSTS 预加载也解决了该问题，但无法扩展到所有站点）。我可以看到现在破坏事物的理由很微弱；我更感兴趣的是它是否会在 5 年后出现明显的结局？10？20？

在默认使用 https 解释的过程中，我可以看到几个问题：

  1. 仅通过 http 运行的网站的用户体验。默认为 https 会显示错误，但用户通常不知道它是否应该工作，即该站点是否根本没有通过 https 工作，或者这是降级攻击。

    如果这种情况的错误页面将包含一个简单的“您的意思是 http:...？” 链接（*），用户将习惯于在任何不起作用的网站上单击它，而我们并没有获得太多（？）。如果它不容易（例如用户必须编辑https-> http，用户将不会使用这样的浏览器。

    编辑：我应该澄清错误指示必须不同于显式转到失败的 HTTPS 地址——这种情况与其说是“失败”，不如说是“安全解释不起作用”。对于初学者来说，即使是自动“软失败”到 HTTP 并在顶部带有警告栏也是可以的。

    但我认为我们仍然获得了 3 件事：访问不安全的站点是一种有意识的行为，我们教育用户不安全的 HTTP 是不正常的，我们向站点施加压力以实施 https。

  2. http://在某些情况下不得不输入的不便。无需https://在更多情况下键入的便利性完全超过了 IMO。

  3. 与历史默认值的“兼容性”。我不确定它是否包含在某些标准中，但 IMO 很明显，我们总有一天必须改变它，所以这不是一个炫耀。

  4. 政治/经济：CA 系统存在问题，浏览器可能不愿意向网站管理员施压（如果他们没有看到其中的价值）。让我们暂时忽略金钱，假装Let's Encrypt 免费 CA已经到来。

我明白为什么现在做出改变会引起争议。让我感到困惑的是，为什么它没有被广泛讨论为明显的长期目标，虽然可能会更慢一些，但有一些分阶段的计划 a-la SHA-2 证书的弃用。我所看到的似乎假设 http 将几乎永远保持默认：

  • Chrome 隐藏http://在 URL 栏中的举动是退一步。迈向 https 默认的第一步应该是用红色显示 http；在稍后的某个时间最终移动到隐藏https://（只显示绿色挂锁）......

  • HSTS 朝着正确的方向发展，但每个站点都谨慎地选择加入。它既弱又强——即使是显式的 http url，网站也选择强制使用 https，没有用户追索错误——但 RFC 甚至没有提到 https 可能是全局默认值的想法，或者浏览器默认方案是归咎于引导 MITM问题。

  • 我已经看到 DNSSEC 被提及为类似 HSTS 的选择加入的未来载体，但再也没有看到选择退出的提议......

此外，是否有任何浏览器（或扩展程序）提供此选项？

4个回答

浏览器是面向最终用户的应用程序。虽然大多数网站都可以通过 http 访问（即使它们只是重定向到 https），但很大一部分网站无法通过 https 访问。因此，您的建议会破坏很大一部分用户的网上冲浪。它会以他们不理解的方式破裂。如果 https 失败，自动降级到 http 是没有意义的，因为攻击者可以简单地破坏与端口 443 的连接来强制降级。

一旦除了少数无关紧要的站点之外的所有站点都切换到 https 后，一个可能会切换到更安全的默认设置，但目前还不行。最终用户不会理解发生了什么，可能只是切换到备用浏览器或从互联网上的某个地方获取一些提示以恢复旧行为。

安全决策必须与用户一起完成，而不是针对用户。

好吧，我可以推测存在一些原因：

  1. HTTPS 支持不会在网站上自动配置。因此，为什么浏览器应该假设它是？
  2. 说除非使用特定方案，否则无法访问网站将超出大量用户的头脑。
  3. 在某些情况下，切换到 HTTPS 并不像看起来那么简单。以堆栈交换为例。

这些是一些流行浏览器解决此问题的时间表：

谷歌浏览器

  1. 铬 46

    Chrome 将使用与 HTTP 页面相同的中性页面图标标记“HTTPS with Minor Errors”状态。

  2. 铬 56

    将收集密码或信用卡的 HTTP 页面标记为不安全

  3. 铬 62

    Chrome 会在另外两种情况下显示“不安全”警告：当用户在 HTTP 页面上输入数据时，以及在以隐身模式访问的所有 HTTP 页面上时。

  4. 铬 68

    多功能框将对所有 HTTP 页面显示“不安全”。

  5. 铬 79

    默认情况下，Chrome 将逐渐转向阻止所有混合内容。为了最大程度地减少损坏，我们会将混合资源自动升级到 https://，因此如果站点的子资源已通过 https:// 可用，则站点将继续工作。

  6. 铬 81

    Chrome 将打印有关所有混合内容下载的控制台消息警告。

  7. 铬 84

    Chrome 会针对可执行文件（例如 .exe）的混合内容下载发出警告。

  8. 铬 85

    Chrome 将阻止混合内容的可执行文件

    Chrome 将对混合内容存档 (.zip) 和磁盘映像 (.iso) 发出警告。

  9. 铬 86

    Chrome 将阻止混合内容的可执行文件、档案和磁盘映像

    Chrome 将对除图像、音频、视频和文本格式之外的所有其他混合内容下载发出警告。

  10. 铬 87

    Chrome 会在图像、音频、视频和文本的混合内容下载时发出警告

    Chrome 将阻止所有其他混合内容下载

  11. 铬 88

    Chrome 将阻止所有混合内容下载。

火狐

  1. 火狐 51

    收集密码但不使用 HTTPS 的网页将在地址栏中显示带有红色删除线的灰色锁定图标。

  2. 火狐 70

    我们将开始显示一个带叉的锁定图标作为通过不安全协议 HTTP 和 FTP 交付的站点的永久指示符。

这里有一个更大的问题会阻止你的建议。当前配置许多 Web 服务器的方式，如果您默认使用 https，您实际上可能最终会访问错误的网站。如果您默认使用 http，则情况并非如此。

例如，假设您有 3 个站点都在同一个 IP 地址上：

http://site.a.com
http://site.b.com
https://site.c.com

在许多服务器上，如果您尝试访问https://site.a.com,（而不是 http），您实际上会查看站点 C，但出现证书错误。

我认为确实存在混淆很多用户的危险，这会使情况变得更糟。到处尝试 HTTPS 不一定是个坏主意，但是当 HTTPS 不可用时，需要为用户制定某种后备计划。

许多用户对警告标志不感兴趣，他们只想要他们的内容。在许多情况下，保护您获得的流量免受窃听或 MITM 攻击并不是绝对必要的，或者至少风险和后果远低于银行上的错误证书。

本质上，如果用户在尝试访问他们最喜欢的仅 HTTP 站点（例如报纸或博客）时收到警告信号，您将不得不教他们忽略警告，因为在这种情况下仍然可以. 告诉用户忽略警告通常是一个糟糕的主意，除非你真的确保他们真的理解忽略警告是可以的，但忽略其他人则不然。

警告是好的，但是针对风险相对较低的问题的大量警告会适得其反，因为用户可能会忽略所有警告（尤其是如果他们不完全理解它们）。

没有多少非技术用户试图理解 Firefox 警告对错误证书的影响，例如：

此连接不受信任

您已要求 Firefox 安全地连接到 some.site.example，但我们无法确认您的连接是否安全。

通常，当您尝试安全连接时，网站会提供受信任的身份证明，以证明您去对了地方。但是，无法验证此站点的身份。我该怎么办？

如果您通常可以毫无问题地连接到该站点，则此错误可能意味着有人试图冒充该站点，您不应继续。

这是许多用户不会费心阅读的三段，至少不是每次遇到它，如果它发生得太频繁的话。

与纯 HTTP 站点的主要区别在于纯 HTTP 站点不声称提供安全连接。假设您可以以类似的方式在另一条三段消息中解释这一点。这很常见，即使是精通技术的用户也会分心，在选择继续之前没有完整阅读这些解释。

许多网站使用http://重定向https://，有时使用 301（永久）状态代码或使用 HSTS。预加载的 HSTS 很棒但很少见，第一次连接时的 HSTS 是相当不错的折衷方案。

归根结底，用户始终需要在适当的时候期望连接是安全的。浏览器只能做这么多，但由用户来检查是否在使用 HTTPS 时有意义，并使用他们期望的站点。这与现实生活并没有什么特别的不同：你不需要检查你曾经交谈过的每个人的护照，但是当事情很重要时，你会这样做。

有一个引导问题无法在技术领域内传达。如果用户去http://www.gmail.com/，他们应该被重定向到https://www.gmail.com/或者https://mail.google.com/或者https://accounts.google.com/。带外知识告诉他们，他们应该在 Gmail 上使用 HTTPS，并且 Gmail 由 Google 运行。（同样的带外知识告诉他们 HTTPS 甚至存在......）

如果他们没有被重定向到由 Google 运行的 HTTPS 站点（Gmail 或登录），那么这应该对他们敲响警钟。虽然自动化机制可以为有限数量的知名站点工作，但很难想象一个系统可以普遍工作。如果做不到这一点，您仍然需要用户承担以下责任：(a) 知道何时需要 HTTPS，(b) 检查是否使用了 HTTPS，以及 (c) 检查他们是否确实在他们想要的站点上。（不幸的是，一些浏览器，尤其是移动设备上的浏览器，会使这些信息不那么明显。）

在我看来，教用户这三点比教他们阅读他们可能选择忽略的警告的详细信息更容易。

当然，您可以想象未来所有站点都使用 HTTPS 的世界。我还不完全相信这是必要的。糟糕的网站也可以获得证书，因此用户仍然有责任检查他们是否在他们打算访问的网站上。

试图教导纯 HTTP 是“不正常的”只是将问题推到一个新的水平。一个全 HTTPS 网络可能是服务提供商的负担，但不一定能提供您期望的好处。

其它你可能感兴趣的问题
上一篇购买二手/翻新电脑有哪些风险？我怎样才能减轻这些风险？ 下一篇有没有办法确保我的政府不会换掉 SSL 证书？