为什么浏览器仍旧没启用TLS.1.3（三）

之前就有文章介绍关于HTTPS拦截，测量了多少“安全”HTTPS连接实际上被浏览器或Web服务器之间的检查软件或硬件截获和解密。也有被动检查代理机制解析TLS和块或转移基于可见光数据连接，如ISP使用主机名信息（SNI）从TLS连接块“禁止”网站。

为了检查流量，这些网络设备需要实现一些或全部TLS。支持TLS的每个新设备都引入了一个TLS实现，该实现对协议应该如何操作进行了假设。实现越多，就越有可能发生僵化。

在2017年2月，Chrome和Firefox都开始为其客户提供TLS 1.3。结果出乎意料的糟糕。TLS 1.3连接的百分比远高于预期。对于一些用户来说，不管网站是什么，TLS 1.2是有效的，但是TLS 1.3没有。

TLS 1.3草案18的成功率

Firefox & Cloudflare

97.8% for TLS 1.2

96.1% for TLS 1.3

Chrome & Gmail

98.3% for TLS 1.2

92.3% for TLS 1.3

经过一番调查，发现一些广泛部署的中间件，无论是截取和被动类型，都造成连接失败。

由于TLS在整个历史过程中看起来都是一样的，一些网络设备对协议如何随着时间演进做出了假设。面对违反这些假设的新版本时，这些设备会以不同的方式出现故障。

在TLS 1.3中更改的TLS一些功能仅仅是表面的。像SSLv3以来，协议中的ChangeCipherSpec，session_id和压缩字段被删除。这些字段被认为是TLS对某些中间件的基本特征，并删除它们导致连接失败。

如果一个协议在足够长的时间内以类似的格式被使用，那么围绕该协议构建工具的人将会假设这个格式是不变的。这通常不是开发人员意向的选择，而是在实践中如何使用协议的意想不到的结果。网络设备的开发人员可能不了解互联网上使用的每一种协议，因此他们经常对网络上看到的东西进行测试。如果一个协议的某部分被认为是灵活的，在实践中永远不会改变，有人会认为它是一个常量。这更可能是创建更多的实现。

把所有的责任都归咎于这些中间件的具体实施者是不诚实的。即使他们创建了TLS的错误实现，但是另一种思考方式是TLS的原始设计本身就存在这些类型的故障。实现者按照协议的实际实现，而不是协议设计者的意图或规范的文本。在复杂的生态系统中，有多个实现者，未使用的接头会生锈。

TLS 1.3工作

上个月在新加坡举行的IETF会议上，针对TLS 1.3提出了一项新的改革方案，帮助解决这个问题。这些变化是基于来自Facebook的Kyle Nekritz的想法:让TLS 1.3看起来像TLS 1.2到middlebox。此更改重新引入了删除的协议的许多部分(session_id、ChangeCipherSpec、一个空压缩字段)，并引入了一些其他的更改，使TLS 1.3看起来像TLS 1.2，在所有的方法中都是对破碎的中框的影响。

BoringSSL开发了这些变化的几次迭代，并在Chrome上测试了几个月。Facebook也进行了一些类似的实验，两个团队在同一组变化上进行了聚合。

Chrome实验成功率

TLS 1.2 – 98.6%

Experimental changes (PR 1091 on Github) – 98.8%

Firefox实验成功率

TLS 1.2 – 98.42%

Experimental changes (PR 1091 on Github) – 98.37%

这些实验表明，可以将TLS 1.3修改为与middlebox兼容。他们还展示了骨化现象。正如前面所描述的那样，唯一可能在客户端“hello”中关闭问题，即版本协商。这导致了草案16，将版本协商移到了扩展。作为客户端和服务器之间的中介，middlebox还关心服务器的hello消息。这条信息有更多的铰链，被认为是灵活的，但结果却不是。几乎所有这些都已经生锈了。新“middlebox”的变化将这一现实考虑在内。这些实验变化被纳入TLS 1.3草案的规范中。

本文由GDCA翻译于cloudflare