Google 如何在其 .app TLD 上强制使用 HTTPS？答案

【问题标题】：How does Google force HTTPS on their .app TLD?Google 如何在其 .app TLD 上强制使用 HTTPS？
【发布时间】：2018-05-09 16:36:29
【问题描述】：

在 2018 年 I/O 大会上，Google 宣布了他们的新 .app 顶级域名，他们表示它只会是 HTTPS。

我认为 DNS 只是将域名映射到 IP。

他们如何强制使用 HTTPS？

【问题讨论】：

标签： dns

【解决方案1】：

（这里有点题外话）

称为HSTS预加载，见https://hstspreload.org/

HSTS（HTTP 严格传输安全）是服务器回复客户端的一种方式：请仅通过 HTTPS 与我联系（参见https://www.troyhunt.com/the-6-step-happy-path-to-https/ 示例）。它增强了安全性，但仍然不能解决一个问题：与给定服务器的第一次连接可以在浏览器知道它应该使用 HTTPS 之前通过 HTTP 进行。

因此出现了 HSTS 的“预加载”。

基本上这是所有主要浏览器代码中的硬编码列表（请参阅https://caniuse.com/#feat=stricttransportsecurity 了解取决于浏览器和版本的兼容性，或参阅底部的代码链接[1]）说明哪些域/TLD 启用了 HSTS，这意味着根本不允许对它们进行 HTTP 连接。

注意：

任何人都可以按照一些要求向此列表提交姓名，请参阅https://hstspreload.org/#submission-requirements
Google（从 Chrome 开始，但现在在浏览器中传播）欢迎包含 TLD 而不仅仅是主机名，请参阅文档末尾https://hstspreload.org/（“TLD 预加载”）

他们已经在过去添加了.DEV（TLD 本身尚未启用，但 Google 将“很快”推出它）破坏了许多开发人员设置他们使用（错误）.DEV 域名的位置命名他们的本地资源，一旦他们的浏览器使用更新的 HSTS 预加载列表更新，他们拒绝在没有 HTTPS 的情况下连接到他们的本地 .DEV 主机。您可以在这里和其他地方（例如：https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/）找到许多关于开发人员反对这一点的恐怖故事，也可能有人为此提供糟糕的解决方案（例如禁用 HSTS 预加载，这是一个非常糟糕的主意）。

此外，当您购买.APP 域名（.DEV 的域名相同）时，Google（作为.APP 的注册机构）在结帐@987654337 时确保与所有注册商签订合同@域名购买，显示一条显眼的消息，上面写着：“.APP 是一个安全的顶级域名，网站只能使用 SSL 证书（原文如此）；确保购买 SSL 证书”（SSL 证书是直截了当的） Google 的文档，读起来很伤心，因为这是一个双重错误的术语，它应该是“X.509 证书”，或者为了不吓到任何人，至少是“用于 TLS 通信的证书” "，现在应该没人再使用 SSL...)。

顺便说一句，.APP 昨天 5 月 8 日以标准价格向公众开放。

当然，所有这些都只与网页浏览有关。您可以在 .APP 域名之上设置任何其他类型的服务，例如电子邮件，而无需任何强制 TLS（这在当今当然不是一个好主意，但没有什么可以阻止您这样做）。对于电子邮件，目前正在讨论基本上是 HSTS，但对于 MTA，请参阅https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

[1] 查看一些带有 HSTS 预加载列表的源代码：

或者您可以使用https://hstspreload.com/ 的 API 来了解某个名称是否在列表中

【讨论】：

【解决方案2】：

这只是一项政策。域名就是域名，DNS 只关心如何将名称转换为其他资源，例如 IP 地址。从技术上讲，任何 IP 地址都可以与任何 IP 协议一起使用（有 256 个可供选择，其中一个是 TCP）和适用时，任何端口号（有 65536 个可供选择，其中两个分别是 HTTP 和 HTTPS） .无法通过 DNS 对此进行限制，但 TLD 注册商当然可以尝试通过策略规则进行此操作。

通过反复试验，我轻松找到了一个不强制使用 HTTPS 的 .app 域：

curl -v -L http://foo.app/

这会导致几个重定向，但没有一个重定向到 HTTPS，最终响应是来自 GoDaddy 地址的 HTTP 响应。

【讨论】：

您遗漏了部分问题，因为这与 DNS 无关，而是与特定的应用程序协议 HTTP(S) 相关。此外，命令行 Web 客户端可能没有使用 HSTS 预加载列表（我没有仔细检查）。他们可能应该...
承认 Google 的政策规则将 Google 作为浏览器供应商的角色与完全独立的 DNS 注册商角色结合在一起。然而，HSTS 预加载列表特定于单个应用程序，因此让任何人认为 .app 仅是 HTTPS 只是因为 Google 拥有 TLD 会产生误导。不是说你的答案是错误的，但是我赞成它。
这确实是一个具体案例，因为谷歌也是浏览器的作者，但是，看我的回答和链接，Firefox、Edge、Safari 也使用完全相同的列表，所以症状将是无论您使用什么浏览器，都一样。只有命令行客户端的行为可能不同。即使 Google 不拥有 chrome，他们也可以要求将其 TLD 添加到列表中，并被所有浏览器考虑在内。但是感谢您的支持:-)（甚至 Tor 也使用它：gitweb.torproject.org/tor-browser.git/plain/security/manager/…）
不仅仅是命令行客户端，还有大量的服务器到服务器的流量，更不用说被称为“物联网”的安全灾难......
我同意。 HSTS 仍然是一个较新的添加，因此它可能会逐渐添加到更多软件中。否则与此处针对 TLS 公开的问题相同：cs.utexas.edu/~shmat/shmat_ccs12.pdf；但是“内部”客户端——不是人工驱动的——可以在一开始就使用 https:// URL 进行硬编码，因此即使没有 HSTS 也能解决问题。