专用网络访问通道更新：推出弃用试用功能

Titouan Rigoudy
Titouan Rigoudy
Yifan Luo
Yifan Luo
GitHub

更新

  • 2023 年 3 月 23 日：时间表已更新，在 Chrome 117 之前不会弃用。

  • 2023 年 1 月 19 日：时间表已更新，我们不会在 Chrome 114 之前弃用该 API。

  • 2022 年 8 月 12 日：时间表已更新，弃用将从 Chrome 109 开始。

  • 2022 年 2 月 10 日：更新后的文章已发布在专用网络访问：引入预请求

  • 2021 年 8 月 25 日：更新了时间表公告，并推出了弃用试用计划。

按照专用网络访问规范，Chrome 将弃用从不安全网站访问专用网络端点的功能。目的是保护用户免受针对专用网络上的路由器和其他设备的跨站请求伪造 (CSRF) 攻击。这些攻击已影响数十万用户，攻击者可以将他们重定向到恶意服务器。

Chrome 将引入以下更改：

  • 从 Chrome 94 开始，阻止来自不安全公共网站的私有网络请求。
  • 推出弃用试用，该试用将在 Chrome 中结束
    1. 它允许开发者为所选来源申请延期，在弃用试用期间不受影响。
  • 推出了一项 Chrome 政策，可让受管理的 Chrome 部署永久绕过弃用。适用于 Chrome 92。

如果您需要更多时间来减轻弃用情况的影响，请登记弃用试用。

如果您对用户拥有管理控制权，则可以使用 Chrome 政策重新启用此功能。

为减轻新限制的影响，请使用以下策略之一：

时间轴

  • 2020 年 11 月：欢迎向我们反馈即将发生的变化。
  • 2021 年 3 月：在审核反馈并进行主动联系后，我们宣布即将进行的变更。该规范已从 CORS-RFC1918 重命名为“专用网络访问”。
  • 2021 年 4 月：Chrome 90 发布为稳定版，并显示废弃警告。
  • 2021 年 6 月：Chrome 92 发布 Beta 版，禁止来自不安全情境的专用网络请求。在开发者反馈需要更多时间进行调整后，我们将弃用时间推迟到了 Chrome 93，并附带了弃用试用。
  • 2021 年 7 月：根据开发者的进一步反馈，Chrome 94 的弃用及附带的试用已推迟。此外，不公开网站不再受弃用的影响。
  • 2021 年 8 月：推出 Chrome 94 Beta 版。Web 开发者可以开始注册参与弃用试用。
  • 2021 年 9 月：Chrome 94 发布为稳定版。网站开发者应已注册废弃计划试用，并已将试用令牌部署到生产环境。
  • 2022 年 12 月：发送了源试用调查问卷并收到了反馈。弃用试用期已延长至 Chrome 113。
  • 2023 年 3 月：弃用试用期延长至 Chrome 116，并将在 Chrome 117 中结束。我们正在开发基于权限的备用机制，计划在 Chrome 114 中进行初始发布。
  • 2023 年 5 月（暂定）：Chrome 114 中推出基于权限的机制。 网站可以使用此标志退出弃用试用。
  • 2023 年 9 月：Chrome 117 发布为稳定版，弃用试用结束。 Chrome 会屏蔽来自非安全公共上下文的所有私有网络请求。

什么是专用网络访问

专用网络访问（以前称为 CORS-RFC1918）会限制网站向专用网络上的服务器发送请求的功能。它仅允许从安全上下文发出此类请求。该规范还扩展了跨源资源共享 (CORS) 协议，因此网站现在必须先向专用网络上的服务器明确请求授权，然后才能发送任意请求。

专用网络请求是指目标服务器的 IP 地址比用于提取请求发起者的 IP 地址更私密的请求。例如，从公共网站 (https://example.com) 到私有网站 (http://router.local) 的请求，或从私有网站到 localhost 的请求。

专用网络访问 (CORS-RFC1918) 中公共网络、专用网络和本地网络之间的关系。
专用网络访问 (CORS-RFC1918) 中的公共网络、专用网络和本地网络之间的关系。

如需了解详情，请参阅期待收到反馈：专用网络的 CORS (RFC1918)。

什么是弃用试用

废弃试验（以前称为反向起源试验）是一种起源试验，用于简化 Web 功能的废弃。通过弃用试用，Chrome 可以弃用某些 Web 功能，并阻止网站对这些功能形成新的依赖项，同时为当前依赖这些功能的网站留出额外的时间来迁移。

在弃用试用期间，默认情况下，所有网站都无法使用已废弃的功能。如果开发者仍需要使用受影响的功能，则必须注册弃用试用计划并为指定的网站来源获取令牌，然后修改其网站以在 HTTP 标头或元标记中提供这些令牌（本例除外）。如果网站提供与其来源匹配的有效令牌，Chrome 将允许在有限的时间内使用已废弃的功能。

如需了解详情，请参阅 Chrome 源试用使用入门和源试用 Web 开发者指南。

Chrome 中的变化

Chrome 94

从 Chrome 94 开始，系统将禁止非安全的公共情境（广义上，指未通过 HTTPS 或专用 IP 地址提供的网站）向专用网络发出请求。此功能之前计划在 Chrome 92 中推出，因此弃用消息可能仍会提及较早的里程碑。

在弃用此功能的同时，我们还推出了弃用试用计划，让网站使用已弃用的功能的 Web 开发者可以通过注册令牌，在 Chrome 116 之前继续使用该功能。请参阅下文，了解如何在您的网站上注册并启用试用版。

您可以利用一对 Chrome 政策，无限期地完全或针对特定来源停用弃用。这样，受管理的 Chrome 安装（例如公司环境中的安装）就可以避免出现故障。

Chrome 117

弃用试用期结束。所有网站都必须从已废弃的功能迁移，或者将其用户的政策配置为继续启用该功能。

对于受影响的网站，第一步很可能是争取一些时间，以便在部署适当的修复程序之前解决问题：方法是注册弃用试用计划或使用政策。然后，建议的操作会因每个受影响网站的情况而异。

注册以试用弃用功能

  1. 点击“从非安全情境获取私有网络访问权限”源试用版的注册，为参与试用的来源获取试用令牌。
  2. 将特定于来源的 Origin-Trial: $token 添加到响应标头。仅当生成的文档使用已弃用的功能时，才需要为主要资源和导航响应设置此响应标头。将此标头附加到子资源响应是没用的（但无害）。

由于必须先启用或停用此试用版，然后文档才能发出任何请求，因此无法通过 <meta> 代码启用此试用版。此类标记仅在发出子资源请求后从响应正文中解析。这对无法控制响应标头的网站（例如由第三方提供的 github.io 静态网站）来说是一个挑战。

如需了解详情，请参阅网站开发者指南：源地址试用。

启用政策

如果您对用户拥有管理控制权，则可以使用以下任一政策重新启用已弃用的功能：

如需详细了解如何为用户管理政策，请参阅这篇帮助中心文章。

访问 localhost

如果您的网站需要向本地主机发出请求，您只需将网站升级到 HTTPS 即可。

针对 http://localhost（或 http://127.*.*.*、http://[::1]）的请求不会被混合内容屏蔽，即使从安全上下文发出的请求也是如此。

请注意，WebKit 引擎及其基于该引擎的浏览器（最值得注意的是 Safari）在此处偏离了 W3C 混合内容规范，禁止将这些请求视为混合内容。它们也不会实现私有网络访问，因此网站可能希望将使用此类浏览器的客户端重定向到网站的纯文本 HTTP 版本，此类浏览器仍可向 localhost 发出请求。

访问专用 IP 地址

如果您的网站需要向使用专用 IP 地址的目标服务器发出请求，那么仅将发起方网站升级到 HTTPS 是不起作用的。混合内容会阻止安全上下文通过纯文本 HTTP 发出请求，因此新安全的网站仍会发现自己无法发出请求。您可以通过以下几种方法解决此问题：

  • 将两端都升级到 HTTPS。
  • 使用 WebTransport 安全地连接到目标服务器。
  • 反转嵌入关系。

将两端都升级到 HTTPS

此解决方案需要控制用户的 DNS 解析，例如在内网环境中可能会出现这种情况，或者用户从您控制的 DHCP 服务器获取其域名服务器的地址。此外，您还需要拥有一个公共网域名。

通过 HTTPS 提供私有网站的主要问题是，公钥基础架构证书授权机构 (PKI CA) 仅向具有公共域名的网站提供 TLS 证书。如需解决此问题，请执行以下操作：

  1. 注册一个公共域名（例如 intranet.example），并发布将该域名指向您选择的公共服务器的 DNS 记录。
  2. 获取 intranet.example 的 TLS 证书。
  3. 在专用网络中，配置 DNS 以将 intranet.example 解析为目标服务器的专用 IP 地址。
  4. 将您的私有服务器配置为使用 intranet.example 的 TLS 证书。这样，您的用户就可以访问位于 https://intranet.example 的专用服务器。

然后，您可以将发起请求的网站升级为 HTTPS，并继续像以前一样发出请求。

此解决方案具有前瞻性，可降低您对网络的信任度，从而扩大在私有网络中使用端到端加密的范围。

WebTransport

此解决方案不需要控制用户的 DNS 解析。它需要目标服务器运行最小的 WebTransport 服务器（经过一些修改的 HTTP/3 服务器）。

您可以使用 WebTransport 及其证书固定机制，绕过缺少由受信任 CA 签名的有效 TLS 证书的问题。这允许与可能具有自签名证书的私有设备建立安全连接。WebTransport 连接允许进行双向数据传输，但不允许提取请求。从 Web 应用的角度来看，您可以将此方法与服务工件结合使用，以便在连接上透明地代理 HTTP 请求。在服务器端，相应的转换层可以将 WebTransport 消息转换为 HTTP 请求。

我们知道这需要做大量工作，但应该比基于 WebRTC 构建要容易得多；我们还希望将部分必要的投资实现为可重复使用的库。我们还认为，考虑到随着时间的推移，随着平台逐渐以更强有力的方式鼓励使用 HTTPS，不安全的情境可能会失去对越来越多网络平台功能的访问权限，因此尤其值得采取行动。无论是否使用专用网络访问，这可能都是明智的投资。

我们预计将在 Chrome 96 中推出基于 HTTP/3 的 WebTransport（已开始源试用），并提供缓解措施来防范密钥共享和其他不合规的安全做法，包括：

  • 固定证书的最长到期时间较短。
  • 一种特定于浏览器的机制，用于撤消某些遭到滥用的密钥。

在 WebTransport 全面推出后，我们至少要等到两个里程碑之后，才会发布安全上下文限制。弃用试用将根据需要延长。

反向嵌入

此解决方案不需要对网络进行任何管理控制，并且可以在目标服务器不够强大而无法运行 HTTPS 时使用。

可以从专用服务器提供应用的框架，而不是从公共 Web 应用提取专用子资源，然后该服务器会从公共服务器（如 CDN）提取其所有子资源（如脚本或图片）。然后，生成的 Web 应用可以向私有服务器发出请求，因为它们被视为同源。它甚至可以向具有专用 IP 地址（但不是 localhost）的其他服务器发出请求，不过这种情况可能会在长期内发生变化。

通过仅在专用服务器上托管框架，您可以通过将新资源推送到公共服务器来更新 Web 应用，就像更新公共 Web 应用一样。另一方面，生成的 Web 应用不是安全上下文，因此无法访问 Web 的一些更强大的功能。

未来计划

将专用网络请求限制为安全情境只是推出专用网络访问功能的第一步。Chrome 正在努力在未来几个月内实现规范的其余部分。敬请关注最新动态！

限制来自私有网站的 localhost 访问

Chrome 94 中的更改仅会影响访问专用 IP 地址或 localhost 的公开网站。有关访问专用网络的规范还将从专用网站向 localhost 发出的请求归类为有问题的请求。Chrome 最终也会弃用这些 Cookie。但是，这带来了一组略有不同的挑战，因为许多私有网站没有域名，这使得弃用试用令牌的使用变得复杂。

CORS 预检请求

专用网络访问的第二部分是使用 CORS 预检请求限制从安全上下文发起的专用网络请求。其基本思想是，即使请求是从安全上下文发起的，目标服务器也需要向发起者提供明确的授予。只有在授予成功后，系统才会发送请求。

简而言之，CORS 预检请求是一个 HTTP OPTIONS 请求，其中包含一些指示后续请求的性质的 Access-Control-Request-* 标头。然后，服务器可以通过使用 Access-Control-Allow-* 标头响应 200 OK 来决定是否授予精细访问权限。

如需详细了解，请参阅规范。

限制导航提取

Chrome 将弃用对私有网络的子资源请求，并最终将阻止此类请求。这不会影响对专用网络的导航，后者还可用于 CSRF 攻击。

专用网络访问规范不会区分这两种提取，它们最终会受到相同的限制。

封面照片：Unsplash 用户 Markus Spiske 提供