TLS1.3终于来了,我们如何了解它?

举报
橘座 发表于 2019/10/14 21:16:57 2019/10/14
【摘要】 今年8月份,IETF正式宣布TLS 1.3规范真正落地了,标准规范(Standards Track)定义在 rfc8446,这篇文章聊聊TLS 1.3的一些动态,概要性的了解下TLS 1.3协议的特性,并解释各个组织对于该版本的支持,如果想让你的服务支持 TLS 1.3,这篇文章非常适合。TLS 1.3版本从2014年开始开发,到今年8月份历经了四年,可见是非常大的一个工程,一共有28个草案...

今年8月份,IETF正式宣布TLS 1.3规范真正落地了,标准规范(Standards Track)定义在 rfc8446,这篇文章聊聊TLS 1.3的一些动态,概要性的了解下TLS 1.3协议的特性,并解释各个组织对于该版本的支持,如果想让你的服务支持 TLS 1.3,这篇文章非常适合。

TLS 1.3版本从2014年开始开发,到今年8月份历经了四年,可见是非常大的一个工程,一共有28个草案。

作为TLS1.3协议最重要、最著名的实现,OpenSSL也发布了OpenSSL 1.1.1版本,该版本全面支持TLS 1.3,是一个长期支持版本(LTS),将会有5年的支持,该版本兼容1.1.0版本,OpenSSL官方建议尽快从1.1.0版本升级到1.1.1版本。

另外 Facebook 开源了一个 TLS 1.3 协议实现软件 Fizz,仅仅支持 TLS 1.3版本,不用考虑老的 TLS 版本,会让代码简洁不少。

另外一个比较流行的TLS协议实现就是NSS,其3.39版本也全面支持TLS 1.3(rfc8446)协议了。

作为世界上最流行的Web服务器,Nginx从1.13.0版本开始支持TLS 1.3协议,但真正支持还是依赖于其引用的协议实现(比如OpenSSL、NSS)。

说完服务器支持TLS 1.3,接下去说下浏览器对于该版本的支持,在《让Nginx快速支持TLS1.3协议》这篇文章中,我们知道不管是Chrome还是Firefox都可以手动配置支持TLS 1.3(当然是draf草案)。目前两大浏览器厂商宣布:

  • chrome70(桌面版)开始,将默认开启支持TLS 1.3(rfc8446),潜台词70以前的版本可以手动启用TLS 1.3(draf)。

  • firefox63版本(201810月),将默认开启支持TLS 1.3(rfc8446)。

国外的一些云服务厂商也全面支持TLS 1.3协议了,比如 CloudFlare 从2016年就启用TLS 1.3支持了,KeyCDN也已经全面支持了,国内在这方面还差了不少。

我平时喜欢说用 Wireshark 解密HTTPS流量,从2.6.3版本开始,Wireshark也将支持TLS 1.3(rfc8446),在《使用Wireshark解密TLS 1.3流量》这篇文章中,介绍了如何解密 TLS 1.3 流量,但对于协议细节介绍的比较少(因为我也在不断的学习),更多描述的是如何配置 WSSLKEYLOGFILE,关于协议细节后面我在学习过程中也会不断分享。

另外一个著名的HTTP协议调试工具 Curl,从 7.52.0 版本开始也已经支持 TLS 1.3协议,但真正支持还是依赖于其引用的协议实现(比如OpenSSL、NSS)。

那 TLS 1.3 协议做了那些改变呢?

  • 性能提升,主要是减少了握手次数,甚至可以做到0-RTT,了解TLS协议的同学都知道,TLS握手延迟是TLS性能最大的杀手。

  • 安全性提升,比如说仅仅支持 AEAD 密码套件,废除了 AES-CBC 密码套件(使用不当会存在安全问题);整个握手协议也使用签名保证握手消息的完整性(在TLS 1.2协议使用MAC算法验证握手消息),同时握手协议也是加密的(在TLS 1.2协议中,握手消息是明文的)。

  • 协议设计的全方位改革,和TLS 1.2 协议完全是不兼容的,可以说是一次大手术,完全不同的设计理念,比如说仅仅只支持5中密码套件,进一步保障了安全性。

如果你想详细了解TLS 1.3协议,建议你关注CloudFlare的文章,非常的精彩,他们是TLS协议运用方面的先行者。最近的一篇文章也被开源中国翻译了,地址是 https://www.oschina.net/translate/rfc-8446-aka-tls-1-3,有兴趣可以看看。

那我们是否可以全面拥抱TLS 1.3呢?

对于服务提供者来说,现在可以支持 TLS 1.3了,但不能废弃其他的TLS 版本(比如 TLS 1.2),原因在于:

1)很多老的客户端(比如浏览器)版本可能比较低,根本不支持较新的一些密码套件,所以旧的TLS版本存活时间是比较长的,想想现在TLS 1.1版本还不能强制下线,TLS 1.2从2016年开始启用,到现在已经12年了,某些网站还没有支持TLS 1.2,可见从兼容性的角度看,TLS老版本仍然会存在很长的生命周期。最近几年HTTPS应用越来越普及了,但并不是所有人(包括技术层面)对它还并不是特别了解,就我预估TLS 1.2协议至少还会存活十年以上。

2)TLS1.3是个新版本,认知度和可信任度还比较欠缺,CloudFlare和Firefox在2017年统计过,仅有5%的用户支持TLS 1.3(当然是草案),所以各个服务全面支持 TLS 1.3还有很大的时间,比如服务器可能不会轻易升级OpenSSL,拿我们公司来说,很多服务器OpenSSL版本还是 OpenSSL 1.0.1e。另外很多服务都会使用OpenSSL,轻易是不敢升级的。后续估计各个Linux发行版会发布OpenSSL 1.1.1的APT或RPM包。

3)TLS1.3版本是完全不兼容老版本的,HTTPS协议是TLS协议最大的是使用者,其本质上还是HTTP协议,而HTTP应用非常的灵活,在互联网中,有很多的代理服务器或网关,他们为了各种各样的目的,都会透明解析TLS协议,CloudFlare 称之为 「middleboxes」,TLS 1.2 版本已经有12年历史了,这些代理服务器和网关也逐步能够解析TLS协议了,但TLS1.3版本的来临,其解析规则全部失效,那么对于用户来说,他们可能就无法使用TLS1.3协议了,这也是TLS1.3协议非常重要的一个问题,关于这方面也是我后续的一个学习点,总结来说,TLS 1.3的普及还需要很长时间。

不过对于个人开发者来说,可以尽快支持TLS 1.3协议,我在《让Nginx快速支持TLS1.3协议》这篇文章中介绍过Nginx配置TLS 1.3,当时使用的TLS 1.3版本是 draft 28。如果想支持正式版的 TLS1.3,下载OpenSSL 1.1.1源代码、Nginx下载1.14.0版本(在我测试过程中,1.13.5编译没有通过),其他安装过程完全可以。

以 www.simplehttps.com 为例,我配置仅支持 TLS1.3 协议,关键配置如下:

ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers  on;
ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256;

编译、启动后,可以使用 ssltest 工具测试,结果如下:


ebb1586019684fa8a2bb931df8ec14a5.png

从图中看出,该网站完美支持 TLS 1.3(rfc8446)。

目前Chrome桌面版的最新版本是69,如果访问该网站,会直接报错,等Chrome桌面版70来领后,就能打开该网站了。

以上就是我最近参考的一些资料,如果你对HTTPS协议感兴趣,可以参考我的新书《深入浅出HTTPS:从原理到实战》,本书github地址是 https://github.com/ywdblog/httpsbook,如果感兴趣可以讨论; 或者关注我的公众号(ID:yudadanwx,虞大胆的叽叽喳喳),我会尽可能多的分享HTTPS&密码学方面的信息。

本文转载自异步社区

原文链接:https://www.epubit.com/articleDetails?id=Na72b2c22-e8de-4d9f-82cd-ee12b430b1ed


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200