众所周知，Cloudflare一直是TLS 1.3的大力支持者，TLS 1.3是TLS协议的最新版本，可提高速度和安全性，因为我们从2016年开始向客户提供该协议。然而，在很长一段时间内，TLS1.3一直是一个正在进行的工作，这意味着在我们的客户的仪表板中默认禁用该功能，至少在解决协议中的所有问题之前。随着规范最终接近正式发布，经过几年的工作（以及28个草案版本），我们很高兴地宣布，Cloudflare上的tls1.3功能已经过了测试版，将在默认情况下为所有新区域启用。来自YouTube视频的自定义图像由OWN提供对于我们的免费和专业客户没有太大的变化，他们已经默认从一开始就启用了TLS1.3。我们还决定在默认情况下为这些计划禁用0-RTT特性（它以前也是默认启用的），因为它具有固有的安全属性。仍然可以从仪表板或API显式地启用它（关于0-RTT的更多信息，请参阅另一篇博客文章）。我们的企业和企业客户现在也将在默认情况下为新区域启用TLS1.3（但将继续禁用0-RTT）。对于那些还没有做出明确选择（也就是说，他们没有手动打开或关闭该功能）的现有商业客户，我们还将追溯性地启用tls1.3。中间盒怎么了？早在去年12月，我们就在博客上讨论了TLS1.3为什么还没有被广泛采用的原因，主要原因是不兼容的中间盒，即设计用于监视和有时拦截HTTPS流量的网络设备。由于TLS协议已经很长一段时间没有更新（TLS 1.2早在2008年发布，与TLS 1.1相比变化非常小），这些设备对协议的错误假设意味着TLS 1.3中一些更具侵入性的更改打破了这些假设，导致了中间盒的不当行为，在最坏的情况下会导致通过它们的TLS连接断开。从那时起，新的议定书草案被讨论和公布，提供了额外的措施（在已经通过的措施之上，如"支持的版本"扩展），以减轻中间盒造成的影响。怎么用？，你会问。诀窍是修改tls1.3协议，使其看起来更像以前的TLS版本，但不影响新版本提供的改进的性能和安全优势。例如，ChangeCipherSpec握手消息，在以前的协议版本中用于通知接收方后续记录将被加密，最初从TLS 1.3中删除，因为在简化握手算法后，它在协议中不再起作用，但是为了避免混淆希望在网络上看到消息的中间盒，重新引入了它，即使接收端点将忽略它。另一个争论的焦点是，一些中间盒希望看到服务器发送的证书消息（通常是为了标识终端服务器，有时是出于邪恶的目的），但是由于tls1.3将该消息移动到握手的加密部分，所以它对窥探器是不可见的。其中的诀窍是使tls1.3握手看起来像是恢复以前的连接，这意味着，即使在以前的TLS版本中，纯文本通信中也会省略证书消息。这是通过在ClientHello消息中填充先前不推荐使用的"session_id"字段来实现的。采用这些变化意味着，虽然协议本身失去了一点原有的优雅（但在不损失任何安全性和性能的前提下），主流浏览器最终可以为所有用户默认启用tls1.3：在版本65中默认启用Chrome的tls1.3，而Firefox在版本60中默认启用tls1.3。采用我们现在可以回到我们的度量标准，看看这一切对于TLS1.3的一般采用意味着什么。早在去年12月，到Cloudflare网站的TLS连接中，只有0.06%使用TLS1.3。现在，有5-6%的人这样做，而且这个数字还在稳步上升：值得注意的是，目前的火狐beta版（v61）从草案23（Chrome也使用）改为使用draft 28。这两个草案版本是不兼容的，因为在草案23发布后的一段时间内采用了一些细微的改动，但是Cloudflare可以同时使用这两个版本，所以一旦firefox61稳定下来，采用率就不会下降。一旦最终的tls1.3版本（即草案28）成为正式的RFC，我们也将支持它与之前的草案版本一起，以避免留下更新缓慢的客户端。结论规范、实施和部署TLS 1.3所需的大量工作终于开始取得成果，而且毫无疑问，在一段时间内，采用率将保持稳定增长：2017年底，我们的CTO预测，到2018年底，超过50%的HTTPS连接将通过TLS 1.3进行，鉴于最近的事态发展，我们仍然相信这是一个可以达到的目标。