你会经常听到说TLS是最重要的安全协议。通常这种说法的理由是,TLS被广泛地部署,并且为许多较高层级的协议工作。这当然没错,但相对于那些更接近较高层协议的其它协议来说,还有另一方面的原因:我们能够通过研究TLS的演化而对协议的设计有深入的了解。
协议版本不兼容
我们得到的一个很重要的经验是:不使用明确的协议版本号。在TLS中,这成了一系列麻烦的根源,导致了时间的浪费和安全问题。其根本原因是,当客户端要求就一个它无法理解的TLS版本号进行协商时,很多服务器会崩溃。按照协议的技术规范,服务器应该拒绝使用未知版本而使用其所能提供的最高版本。
尽管这是一个服务器端的问题(从更深层次上来说,是协议库的问题),但实际上当浏览器与某一站点无法通信时,人们却把问题完全归咎于浏览器。这就导致了一种被叫做主动协议降级的行为:当使用最高版本协议的尝试失败后,浏览器会尝试次高版本、第三级版本,以此类推,直到能够与服务器成功建立一个加密通道。
虽然这种浏览器行为增强了协同性,但却减缓了通信速度,同时使那些活跃的攻击者能够把通信安全等级降低到客户端和浏览器所支持的最低版本的协议上。
经过多年努力,那些主要的浏览器供应商才最终制止了这种情况。首先是解决了发现POODLE攻击促使降低到SSL v3版本的问题。
TLS1.3 版本不兼容的问题会一直持续到新的协议版本发布。TLS1.3虽已经接近完成,但我们还得面对很多服务器不支持的残酷事实,因此协议版本被降低使用的情况就又可能相应出现了。
SSL实验室中的版本不兼容测试
在一些SSL实验室中,协议版本不兼容测试已经进行了很长时间。如果你不幸进入一台与TLS1.0、1.1或1.2中的某个版本不兼容的服务器,那么你会收到一个严重警告,但这样的服务器变得越来越少;毕竟,大部分浏览器到2013年底已开始使用TLS1.2,这意味着已经有几年的时间用来解决版本不兼容问题了。
我们也为TLS1.3和其他一些很高版本的协议做了不兼容测试。现在看来TLS1.3的测试结果很有意义,而其他测试可能更让协议开发者感兴趣。
鉴于TLS1.3即将发布,我们要让不兼容警告更突出,同时在评估服务器的时候考虑到这一点。我们很快将会发贴对它单独进行讨论。
在SSL Pulse项目中追踪版本不兼容问题
我们的SSL Pulse项目监控着15万个最常用网站的SSL/TLS配置,不间断地提供从2012年4月第一次监测以来的版本不兼容信息。在下面的图表中可以看到相关信息。
可以看到,在我们最近的监测(2016年7月)中,样本中3.2%的服务器不喜欢TLS1.3,3.6%的服务器不喜欢TLS2.152。这听起来不算多,但对浏览器来说却是个大问题,因为这意味着它要对数千个网站进行解译,其中一些网站还非常流行。
你还会注意到在2015年5月,不兼容服务器的数量有一个巨大的降幅,这佐证了一种解释。当我们第一次测定版本不兼容问题时,其测定数据真的非常大;最多时有12%的服务器对TLS1.2不兼容,超过60%的服务器对TLS2不兼容。在这种情况下,几乎不可能顺利地引入一个新版本的协议。但那时已经有人意识到,TLS1.3可以减少这个问题的发生。
如果你看任何版本的SSL或TLS协议底层,你会看到他们都使用两种不同的版本号。一种版本号用于主协议(TLS1.0、1.1等等),但还有记录层版本号。你可以把记录层看成一个次协议。因为有两种版本号,所以在发送的每个字段中使用哪个版本号总会产生混淆。一些客户端会仅使用主协议版本号(如TLS1.2),但在SSL3或TLS1.0中保留记录层版本号,以便指明在记录层中没有变化。但是,一些客户端会在这两个字段中都使用较高的版本号,在我们的测试中自然只能模拟到最坏的情况。
不管怎样,大多数问题都来源于记录层不兼容。考虑到没人真的需要两种版本号,因而TLS1.3的技术规范弃用了记录层版本号,并把它固定在TLS1.0(0x0301)。经过一段时间,于2015年5月我们开始按照新规则测试时,版本不兼容问题的数量大大降低了。