现在正式发布:TLS 1.3被认可为标准

我们之前曾写道 ,互联网工程理事会(IETF)已批准TLS的新版本-1.3。 上周,该协议被认可为标准。 今天-让我们谈谈其功能。


/图片Charles Dyer CC

TLS 1.3的功能


他们从2014年开始着手更新协议。 非正式地,TLS 1.3的工作于今年3月结束,但是工程师们还需要几个月的时间来进行其他检查。

创建者声称TLS 1.3的最终版本更加安全和高效:其加密算法中已关闭了所有已知(当今)的TLS 1.2漏洞,“握手”过程的速度是其先前版本的两倍。 开发人员还增加了前向机密性和0-RTT等新功能。

TLS 1.3在协议的历史记录中进行了最大数量的重大更改。 因此,有人甚至建议将其称为TLS 2.0。

既然TLS 1.3协议的新版本( RFC 8446 )已被正式批准,那么它仍然可以为所有网络连接实现它。

实施困难


TLS具有一种向后兼容性。 在客户端和服务器之间建立连接时,将交换协议的受支持版本,并选择双方都可以使用的版本。 但是,此功能并非在所有地方都使用。 随着TLS 1.3的问世,超过3%的支持TLS 1.2的服务器只是断开连接,而不是向客户端发送受支持的版本号。

中间节点( middlebox )也发生了类似的问题。 由于TLS的变化不大,因此防火墙,NAT和负载平衡器之类的东西拒绝使用新版本的协议。

工程师称这种现象为骨化(ossification)。 一些开发人员没有使用该协议的灵活功能这一事实使得很难引入该协议的新实现。 打个比方,行业参与者举出了旧门的例子 。 如果长时间不触摸它,则循环会生锈,并且会发出吱吱声。


/图片Christopher Sessums CC

原来的协议已经过时了,但是默认情况下引入新协议是行不通的。 例如,在去年IEEE( PDF )的研究中,可以找到有关该主题的更多信息。

该解决方案是由从事铬研究的David Benjamin找到的。 他建议将来自支持TLS 1.3的客户端的第一条消息伪装成TLS 1.2消息。 并且有效:提到的3%的服务器停止了断开连接。 对于中介网站,Facebook的Kyle Nekritz建议使用相同的方法。 这样一来,Chrome中的崩溃次数减少了6.5%,而Firefox中的崩溃次数减少了2%。

要检查中间盒是否与该协议的新版本兼容,可以使用Cloudflare中开发的测试

如何简化实施


TLS和HTTPS规范的开发者之一Eric Rescorla表示,一般来说,实现TLS 1.3并不那么困难。 工程委员会试图使此过程尽可能简单。 TLS 1.3使用与TLS 1.2相同的密钥和证书。 如果客户端和服务器都支持新版本的协议,则这将允许客户端和服务器通过TLS 1.3自动建立连接。

此外,还有许多库可以帮助您更快地部署协议。 例如,上周初,Facebook 其TLS 1.3 Fizz库转让 给了开源 。 Fizz 减少了传输数据时的延迟以及CPU的负载。

开发人员已准备好如何在Ubuntu 16.04 LTS上开始使用Fizz的指南。 它位于GitHub上的官方存储库中 (也有针对MacOS的指南)。

首先,您需要安装必需的follylibsodium依赖项

sudo apt-get install \ g++ \ cmake \ libboost-all-dev \ libevent-dev \ libdouble-conversion-dev \ libgoogle-glog-dev \ libgflags-dev \ libiberty-dev \ liblz4-dev \ liblzma-dev \ libsnappy-dev \ make \ zlib1g-dev \ binutils-dev \ libjemalloc-dev \ libssl-dev \ pkg-config \ libsodium-dev 

接下来,您需要构建并安装愚蠢的用户:

 git clone https://github.com/facebook/folly mkdir folly/build_ && cd folly/build_ cmake configure .. make -j $(nproc) sudo make install 

然后,您可以继续安装Fizz:

 cd ../.. git clone https://github.com/facebookincubator/fizz mkdir fizz/build_ && cd fizz/build_ cmake configure ../fizz make -j $(nproc) sudo make install 

除了Fizz之外,网络上还有其他库,例如wolfSSLGnuTLSrustls

未来协议


为了最终解决该协议“僵化”的问题,David Benjamin 建议在标准的正式版本之外使用其多种变体,该变体将每六周发布一次(与新版本的Chrome一起发布)。 因此,将要求服务器和中间节点遵守所有建立连接的规则,否则大多数客户端将无法连接到服务。

因此,开发人员希望避免加载网页时发生崩溃,以及将来的TLS版本出现类似问题。

引入TLS 1.3后,预计网络的整体安全性将大大提高。 有助于部署该协议新版本的库必须有助于大规模分发。



PS来自公司IaaS博客的其他材料:




我们在IT-GRAD中所做的工作-主要领域:

虚拟基础架构(IaaS) | PCI DSS托管 | 云FZ-152

Source: https://habr.com/ru/post/zh-CN420521/


All Articles