原文地址:https://blog.cloudflare.com/esni/
翻译水平有限,有不通顺的语句,请见谅。
原作者:Matthew Prince 写于 24 Sep 2018

Cloudflare于2010年9月27日上线. 从那以后, 我们便把9月27日作为我们的生日. 本周四,我们将迎来8岁生日.

从我们的第一个生日开始,我们就利用这个机会推出新的产品或服务. 多年来,我们得出的结论是,庆祝我们生日的正确方式,不是推出可以让我们赚钱的新产品,而是用一些礼物回报给我们的用户和互联网。我的联合创始人,米歇尔,在昨天的一篇很棒的博文中写到了这个传统

就个人而言,我在Cloudflare度过的最自豪的一刻是在2014年的生日那天,我们为所有用户免费提供HTTPS支持。当时,人们一字一句(literally and repeatedly)说我们疯了。坦诚来讲,在内部,我们对于我们是否疯狂进行了重要的辩论,因为我们的客户从免费帐户升级到付费帐户的主要原因是其中的加密功能。

但当时的做法是正确的。从一开始,网络中没有内置加密的模块,这在我们现在看来就是一个错误。今天,差不多四年之后,由于像Let’s Encrypt这样的大型项目,Google、Apple、Microsoft和Mozilla的浏览器团队的领导,以及越来越多的托管和SaaS服务内置免费的HTTPS支持,网络的加密比率接近了80%。我很自豪,因为帮助推动这一趋势的领导者是我们。

今天,是我希望从未来回顾并为此感到自豪的另一天,因为今天我们希望帮助启动另一种新的趋势,使加密的网络更加私密和安全。要理解这一点,您必须了解为什么当前存在的加密网络仍会泄露您的大量浏览历史记录。

你的浏览记录有多私密

我们所期待的是,当你在通过HTTPS访问一个网站时,没有人在你和连接的另一端之间监听你在执行的操作。

通过HTTPS访问站点时的期望是,没有人在您和您的连接终止的位置之间进行监听,可以看到您正在执行的操作。在某种程度上,这是真的。如果您访问银行的网站,HTTPS可以有效地让发送到站点或从站点发送的内容(例如,您的用户名和密码或是银行帐户的余额)防止泄露给您的ISP或监控您的网络连接的其他任何人。

虽然发送到HTTPS站点或从HTTPS站点接收的内容受到保护,但事实是,您仍可以通过多种方式轻松查看访问的站点。传统上,其中一种方式是通过DNS。默认情况下,DNS查询是未加密的,因此您的ISP或其他任何人都可以查看您在网上访问的内容。这就是为什么在四月,我们推出了1.1.1.1 - 一个免费(并且访问快到让人尖叫)的公共DNS解析服务器,支持DNS over TLS(在TLS安全通信中查询DNS)和DNS over HTTPS(在HTTPS安全通信中查询DNS)。

1.1.1.1取得了巨大成功,并且我们显着提高了通过加密连接发送DNS查询的百分比。然而,有批评者正确地指出,您访问的网站的身份信息仍然可能以其他方式泄漏。最有问题的是被称为服务器名称指示(Server Name Indication,SNI)的扩展。

为什么是SNI?

从根本上说,SNI的存在是为了让您可以在一个IP地址上托管多个加密网站。早期的浏览器不包括SNI扩展。因此,当请求要求建立HTTPS连接时,Web服务器没有足够的信息可以继续,只能回收Web服务器正在侦听的每个IP地址的单个SSL证书。

此问题的一个解决方案是创建具有多个主题备用名称(Subject Alternative Name,SAN)的证书。这些证书将加密多个域的流量,这些域可以全部托管在同一个IP上。这就是Cloudflare处理来自不支持SNI的旧浏览器的HTTPS流量的方式。我们将这一功能限制仅我们的付费客户可用,当然,原因是SAN不是一个很好的解决方案:它们使管理麻烦,如果它们包含太多域,可能会降低性能。

更具可扩展性的解决方案是SNI。对我来说,一个有意义的类比是,想象一个邮政信封。信封内的内容受到保护,邮递员无法看到。但是,信封外面的街道地址,使邮递员能够将信封带到正确目的地。在因特网上,Web服务器的IP地址相当于街道地址。

但是,如果您住在一个多个单元的建筑物中,仅靠街道地址不足以将信封送到正确的收件人。你需要附上公寓号码或收件人姓名来补充街道地址。这相当于SNI。如果Web服务器托管多个域,SNI则会确保将请求路由到正确的站点,使正确的SSL证书可以返回,以便能够加密和解密任何内容。

Nosey 网络

SNI的规范是在2003年由IETF推出的,浏览器在接下来的未来几年内推出了支持。当时,这似乎是一个可以接受的权衡(tradeoff)。因为绝大多数互联网流量都未加密。添加一个更容易支持加密的TLS扩展似乎是一个很好的权衡,即使该扩展本身没有加密。

但是,今天,由于HTTPS占据了所有网络流量的近80%,因此SNI会泄露您上网的每个站点,您的ISP以及其他任何人都可以在线上监听,这已成为一个明显的隐私漏洞。了解您访问的网站可以非常准确地了解您的身份,同时带来隐私和安全风险。

在美国,根据奥巴马执政结束时期通过的FCC规则,ISP收集客户浏览数据的能力受到短暂限制。然而,互联网服务供应商(ISP)游说国会,2017年4月,特朗普总统签署了一项国会决议,废除了这些保护措施。随着互联网服务提供商越来越多地收购媒体公司广告定位业务,以便能够从流经他们网站的数据中挖掘利益,对他们来说是一项越来越有吸引力的事情,但是对我们所有人来说却是越来越令人不安的隐私威胁。

修复SNI隐私漏洞

5月3日,在我们发布1.1.1.1后大约一个月,我正在阅读有关我们新服务的评论。虽然评论赞扬了1.1.1.1是面向隐私的事实,但它有些虚伪地断定这一切都是无用的,因为ISP仍然可以通过监控SNI监视你。我沮丧地发了一封电子邮件给一些Cloudflare的工程师和Mozilla的高级团队,我们正和这些团队致力于一个推动加密DNS的项目。我的邮件大意如下:

我的产品需求(PRD)很简单:如果Firefox连接到Cloudflare的IP地址,我们会给你一个公钥,用于加密SNI信息,然后再发送给我们。它如何扩展到其他提供商?不知道,但我们必须从某处开始。粗略的共识,并运行的代码,可以吗(Rough consensus and running code, right)?

事实证明这比那复杂一点。然而,今天我很自豪地宣布,加密SNI(ESNI)在Cloudflare的网络上正常运行。本周的晚些时候,我们预计Mozilla的Firefox,Nightly分支,将成为第一个支持这项新协议的浏览器。在接下来的几个月里,该计划将成为主流。它不仅仅是Mozilla。所有主流的浏览器制造商都非常感兴趣,我希望他们都能随着时间的推移增加对ESNI的支持。

希望推进另一种趋势

虽然我们是首个支持ESNI的组织,但我们并不是单兵作战。在ESNI上,我们与来自Apple、Fastl、Mozilla以及整个行业的其他团队开展了合作,他们同我们一样关注互联网隐私。虽然Cloudflare是第一个支持ESNI的内容(分发)网络,但ESNI并不是一个专属协议。它正作为一项IETF的RFC草案运作,我们希望其他人也能帮助我们正式确定草案并实施标准。如果您对ESNI背后的技术细节感到好奇,可以从我的同事Alessandro Ghedini刚刚发布的精彩博客文章 (本站渣翻地址:加密SNI的工作原理)中了解更多信息。最后,本周稍晚,当浏览器开始启动支持时,您可以在我们便捷的ESNI测试工具上进行测试。

四年前,我很自豪我们有助于创造了一种潮流,这种潮流使得目前几乎所有的网络得以被安全加密。今天,我希望我们再次帮助开启一个潮流 - 这一次使加密的网络更加私密和安全。