为什么各大浏览器还未发布支持TLS 1.3 (1)

发布日期：2018-01-10

在像互联网这样复杂的生态系统中升级安全协议是很困难的，你需要更新客户端和服务器，还要确保两者之间的所有设施都能继续正常运转。目前，互联网正处于这一升级过程之中。

TLS 1.3应用率

传输层安全(TLS)协议是一种确保web浏览机密性的协议。目前，TLS协议正在经历其诞生以来的第一次重大修改。去年，Cloudflare公司成为第一个在服务器端默认支持TLS 1.3的主要供应商商。我们期待客户端供应商们也会紧随其后，在所有主流浏览器中支持该版本。但是，自Cloudflare公司的TLS 1.3发布以来，已经有一年多的时间了，还没有一个主要浏览器默认启用了TLS 1.3。

简单来说，还没有部署TLS 1.3的原因就在于中间设备：即那些用于监控和(有时用于)拦截企业环境和移动网络中的HTTPS通信的网络设备。其中一些中间设备错误地部署了TLS 1.2，而现在，这正在阻止了各大浏览器发布支持TLS 1.3的版本。然而，仅仅指责网络设备供应商就太虚伪了，这件事情的深层真相是，最初设计TLS 1.3的时候，它与互联网长期以来的发展方式并不兼容。本文将深入探讨产生这个问题的原因和过程。为了给这次讨论提供数据支持，Cloudflare编写了一个工具，可以检查你的网络是否与TLS 1.3兼容：https://tls13.mitm.watch

版本协商机制过去是如何在TLS中工作的

传输层安全协议(TLS)是使HTTPS实现安全web浏览的主力。TLS协议是由上世纪90年代后期的安全套接层协议(SSL)改写而来的。TLS协议目前有三个版本：1.0、1.1和1.2，该协议非常灵活，可以以不同的方式发展。较小的更改可以合并为“扩展”(例如OCSP和证书透明系统)，而更大的、更基础性的更改通常需要发布一个新版本。到目前为止，TLS 1.3是该协议有史以来最大的变化，完全改变了原有的加密方式，并引入了0-RTT等特性。

并不是每个客户端和服务器都支持同一版本的TLS协议，这使得升级协议变得不可能——因此大多数主机同时支持多个版本。为了在连接时上使用同一版本的协议，客户端和服务器必须协商一致。TLS协议版本的协商非常简单。客户端将其支持的协议的最新版本告知服务器，而服务器则以双方都支持的协议最新版本最新版本进行应答。

TLS协议的版本用两个字节的值表示。由于TLS是由SSLv3改写而来的，所以从字面上看，TLS协议中只有次级版本号增加了：

SSLv3是3.0版本，

TLS 1.0是3.1版本，

TLS 1.1是3.2版本，

TLS 1.2是3.3版本，等等。

当使用TLS协议连接到服务器时，客户端在连接开始时发送其所支持的最高版本：

(3, 3) → server

一个支持相同版本协议的服务器回复一条以相同的两字节版本号开始的消息。

(3, 3) → server

client ← (3, 3)

或者，如果服务器只支持旧版本的协议，它可以用旧版本进行回复。例如，如果服务器只能支持TLS 1.0，那么它就可以这样回复：

(3, 3) → server

client ← (3, 1)

如果客户端支持由服务器返回的协议版本，那么双方将继续使用该版本的TLS协议，并建立一个安全连接。而如果客户端和服务器没有共同支持的版本，那么连接将会失败。

这次协商的目的是为了兼容未来。如果客户端发送的协议版本比服务器所支持的版本要高，那么服务器应该仍然可以以其支持的任何版本来回应。例如，如果一个客户端发送(3，8)到一个支持TLS 1.2的服务器，那么该服务器应该只会返回(3，3)，并仍然按照TLS 1.2协议进行握手。

很简单，对吧?但实际上，有些服务器并没能正确地实现这一点，而这导致了一系列事件，这些事件让web用户暴露在严重的安全漏洞之下。

POODLE漏洞与降级之跳

对TLS的最后一次重大升级是引入了TLS 1.2。在TLS 1.2部署到浏览器的过程中发现，某些TLS 1.0服务器没有正确地完成版本协商。当一个以TLS进行连接的客户端宣布支持TLS 1.2的时候，有缺陷的服务器将会断开连接，而不是与客户端协商一个它所支持的TLS版本(如TLS 1.0)。

浏览器处理这种情况可以有三个选择：

1、启用TLS 1.2，这样将会有一部分网站将停止工作;

2、延迟TLS 1.2的部署，直到这些有缺陷的服务器被修复;

3、如果连接失败，则使用旧版本的TLS重试。

人们对浏览器的一个期望是，当它们进行更新时，网站会正常工作。但是，有缺陷而导致一更新就崩溃的服务器数量太多了，所以第1个选项被排除了。到现在为止，TLS 1.2已经发布一年时间了，然而服务器的问题仍未能解决，而继续等待看起来也不会解决这个问题，所以第2个选项也被排除了。这使得第3个选项成为了唯一可行的选择。

为了启用TLS 1.2，同时使它们的用户满意，大多数浏览器都部署了所谓的“不安全降级”。当浏览器连接到一个站点时，如果遇到连接失败的情况，它们会再次尝试使用TLS 1.1，然后尝试TLS 1.0，如果再失败，则尝试SSLv3。这种降级逻辑“修复”了这些有缺陷的服务器······但其代价是建立的连接速度很慢。

然而，不安全降级之所以称为“不安全”是有原因的。客户端降级是由一种特定类型的网络故障触发的，这种故障很容易伪装。从客户端的角度来看，没有办法判断这个故障是由一个有缺陷的服务器引起的，还是由一个刚好处于该网络所在的网络路径上的黑客的攻击所造成的。这就意味着，即使服务器和客户端都支持新的协议版本，网络攻击者也可以注入虚假的网络故障，诱骗客户端来使用SSLv3连接到服务器。在这个时候，SSLv3协议中并没有已公开的严重漏洞，所以这看起来并不是一个大的问题。然后POODLE漏洞发生了。

2014年10月，Bodo Möller公布了POODLE漏洞，这是SSLv3协议中一个严重的安全漏洞，它允许网络内的攻击者能够毫不费力地披露网络中的加密信息。因为TLS 1.0协议已经在客户端和服务器上都被广泛部署，所以在web上只有很少的连接使用SSLv3协议，这本应能够确保它们的安全。但是，不安全降级功能使得攻击者可以在客户端和服务器双方都支持SSLv3协议的情况下(大多数情况下都支持)将任何连接降级到SSLv3。这一“降级之跳”，将POODLE漏洞从一件奇闻变成了可能影响大部分网络的严重漏洞。

修复POODLE漏洞，消除不安全降级

对POODLE漏洞的修复是:

1、在客户端或服务器端禁用SSLv3协议;

2、启用一个名为SCSV的新的TLS功能。

在POODLE漏洞被发现之前的几个月，Adam Langley和Adam Langley顺便提出了SCSV。简单地说，当由于网络错误而需要重新尝试连接时，客户端通过SCSV将一个名为“降级金丝雀”的指示器添加到它的客户端问候信息中。如果服务器支持的协议版本比客户端问候信息中发布的版本更高，服务器就会查看这个指示器，服务器可能会假设降级攻击正在发生，并关闭这个连接。这是一个很好的功能，但它不是必选的，并且需要客户端和服务器都进行更新，这使得许多web用户仍然暴露在风险之中。

浏览器立即取消了对SSLv3的支持，除了对一些只支持SSLv3的网站造成影响之外，几乎没有什么别的影响。使用旧版浏览器的用户必须依赖web服务器来禁用SSLv3。Cloudflare公司立即为其客户做了这一工作，而大多数网站也是如此，但是根据SSL Pulse的数据，即使是在2017年年末，仍有超过10%的网站继续支持SSLv3。

关闭SSLv3对于解决POODLE漏洞来说是个可行的方案，因为SSLv3对互联网来说并不重要。这就提出了一个问题：如果在TLS 1.0中存在严重的漏洞，那么会发生什么事?TLS 1.0目前仍然被广泛使用和依赖，在浏览器中禁用它将会把大约10%的用户拒之门外。另外，尽管对于解决不安全降级的问题，SCSV是一个很好的方案，但许多服务器并不支持这一功能。在TLS 1.0中，确保用户安全的唯一选项是禁用不安全的回退。

对于大多数没有正确部署版本协商机制的网站来说，客户端不得不多次重新连接，这样的糟糕表现持续了数年时间，现在这些网站已经修复了它们的服务器。这使得一些浏览器能够消除这种不安全的回退。

Firefox浏览器和Chrome浏览器分别在2015和2016年解决了这个问题。因此，当面对目前出现的新的TLS 1.0漏洞时，这两个浏览器的用户处于更安全的位置。

文章来源：互联网

为什么各大浏览器还未发布支持TLS 1.3 (1)

数字证书

技术支持

关于沃通

旗下网站