开启 TLS 1.3 加密协议，极速 HTTPS 体验

时间 2019-11-12

标签开启 tls 1.3 加密协议 https 体验繁體版

原文原文链接

随着互联网的发展，用户对网络速度的要求也愈来愈高，尤为是目前在大力发展 HTTPS 的状况下，TLS 加密协议变得相当重要。又拍云在 HTTPS 的普及和性能优化上，始终作着本身的努力和贡献。2018年初，又拍云 CDN 网络部署了 TLS 1.3，进一步提高了用户的访问速度与安全。html

什么是 TLS 1.3？

TLS 1.3 加密协议是在 TLS 1.0 、TLS 1.1 、TLS 1.2 以前版本基础上进行的升级和改造，也是迄今为止改动最大的一次，IETF 正在制定 TLS 1.3 的新标准，目前尚在草案阶段，能够参考最新草案。相比 TLS 1.2 ，TLS 1.3 的主要区别在于：react

新的加密套件只能在 TLS 1.3 中使用，旧的加密套件不能用于 TLS 1.3 链接；
添加了0-RTT 模式，在创建链接时节省了往返时间（以某些安全性为代价）；
废除了静态的 RSA（不提供前向保密）密钥交换，密钥交换机制如今可提供前向保密；
ServerHello 以后的全部握手消息采起了加密操做；
TLS 1.2 版本的重协商握手机制已被弃用，TLS 1.3 中从新协商变为不可行了；
相比过去的的版本，会话恢复在服务端是无状态的，使用了新的 PSK 交换；
DSA 证书再也不容许在 TLS 1.3 中使用；

以上的这些改动，能够避免以前版本出现的缺陷，不只如此，还能够减小 TLS 握手的时间。总结一下，TLS 1.3 与之前的版本相比具备以下两个大的优点，分别是：git

更快的访问速度
加强安全性

TLS 1.3 做用

1. 更快的访问速度

为了对比 TLS 1.3 在 TLS 握手阶段的变化，这里将 TLS 1.2 和 TLS 1.3 在 TLS 握手阶段进行对比。github

△ TLS 1.2 完整握手框架（来自 RFC 5246 ）算法

从上图能够看出，使用 TLS 1.2 须要两次往返（ 2-RTT ）才能完成握手，而后才能发送请求。chrome

△ TLS 1.3 完整握手框架（来自 TLS 1.3 最新草案）浏览器

TLS 1.3 的握手再也不支持静态的 RSA 密钥交换，这意味着可使用带有前向安全的 Diffie-Hellman 进行全面握手。从上图能够看出，使用 TLS 1.3 协议只须要一次往返（ 1-RTT ）就能够完成握手。安全

相比 TLS 1.2 ，TLS 1.3 的握手时间会减半。这意味着访问一个移动端网站，使用 TLS1.3 协议，可能会减小将近 100ms 的时间。关于 1-RTT 最大的变化是消除了 ServerKeyExchange 和 ClientKeyExchange 消息，DH 参数和公钥如今以特殊的 key_share 扩展发送，这是一种新的扩展类型，将被包含在 Client Hello 和 Server Hello 消息中。性能优化

△ TLS 1.3 0-RTT 模式握手框架（来自 TLS 1.3 最新草案）网络

值得关注的是，TLS 1.3 草案中新增了零 RTT （ 0-RTT ）模式，也即在上一次链接中，握手完成以后，服务端会发送一条 ServerConfiguration 消息，在随后的客户端发起第一个 TLS 记录 ClientHello 过程当中，直接附加加密的应用程序数据，该模式将会致使更加快速的访问体验。

2. 加强的安全性

TLS 的发展有 20 多年的历史，在以前的版本中，TLS 1.2 是高度可配置的，为了更好的兼容旧版本的浏览器，这意味着那些易受攻击的站点始终在运行着不安全的加密算法，这让互联网黑客有可乘之机。TLS 1.3 在以前版本的基础上删除了那些不安全的加密算法，这些加密算法包括：

RSA 密钥传输 —— 不支持前向安全性
CBC 模式密码 —— 易受 BEAST 和 Lucky 13 攻击
RC4 流密码 —— 在 HTTPS 中使用并不安全
SHA-1 哈希函数 —— 建议以 SHA-2 取而代之
任意 Diffie-Hellman 组—— CVE-2016-0701 漏洞
输出密码 —— 易受 FREAK 和 LogJam 攻击

TLS 1.3 目前支持如下加密套件：

TLS13-AES128-GCM-SHA256
TLS13-AES256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES128-CCM-SHA256
TLS13-AES128-CCM-8-SHA256

新的加密套件只能在 TLS 1.3 中使用，旧的套件不能用于 TLS 1.3 链接。总之，TLS 1.3 相比老版本的 TLS 协议将会更加安全，这也表明着互联网安全的一大进步。

2018 年初，又拍云在 CDN 部分节点中部署了 TLS 1.3，做为国内较早支持 TLS 1.3 的 CDN 厂商，又拍云始终跟随时代的步伐，为互联网世界的安全与加速贡献着本身的一份力量。在互联网世界这个生态系统中，进行 TLS 安全协议的升级并不简单，这个须要客户端和服务端同时进行升级，并确保客户端和服务端的全部通讯都是正常的。

一键开启 TLS 1.3

1）在又拍云 CDN 平台启用 TLS 1.3

在又拍云 CDN 控制台，针对 TLS 1.3 开放了切换开关，TLS 1.3 默认为关闭状态，您能够手动开启，以下图所示：

值得声明的是， CDN 是否启用 TLS 1.3 ，这个取决于客户端浏览器是否支持，若是客户端并不支持 TLS 1.3 ，则会进行协议降级，仍会使用较低的 TLS 1.2 协议进行通讯。

2）在浏览器中启用 TLS 1.3

目前最新版本的 Chrome 和 Firefox 都支持 TLS 1.3，可是都须要手动开启。

在 Firefox 中手动启用 TLS 1.3

Mozilla Firefox 用户能够经过如下方式在 Firefox 中启用 TLS 1.3 支持（请注意，Firfox Nightly版本默认支持 TLS 1.3，而 Firefox 稳定版（截至日前是 Firfox 57）须要专门配置以支持 TLS 1.3 ）。

在 Firefox 地址栏中输入 about:config。若是显示警告屏幕，请确认您要当心，可忽略安全提示；
在搜索区域搜索 security.tls.version.max；
经过双击它将首选项的值更改成 4（默认为 3 ）。

在 Chrome 中手动启动 TLS 1.3

Google Chrome 用户能够经过如下方式在 Chrome 中启用 TLS 1.3 支持（请注意，Chrome Canary 版本默认支持 TLS 1.3，而 Chrome 稳定版（截至日前是Chrome 64）须要专门配置以支持 TLS 1.3 ）

在浏览器的地址栏中加载 chrome://flags/，这将打开 Web 浏览器的实验页面。
在搜索区域搜索 TLS 或者 tls ，找到 TLS 1.3 选项，默认为 Default
须要将 TLS 1.3 改成 Enabled (Draft)；
从新启动 Web 浏览器。

注意：Chrome 62 以前的版本须要将 Maximum TLS version enabled 改成 TLS 1.3。

验证服务端是否支持了 TLS 1.3

使用 Google Chrome 开发者工具，选择 Security 模块，以下图所示，当安全连接为 TLS 1.3 时，说明这次链接是使用 TLS 1.3 进行通讯的。

以上能够得知，浏览器以及服务端都支持 TLS 1.3 才可使用 TLS 1.3 进行通讯。

总结

TLS 1.3 是 Web 安全与性能的一大进步，虽然主流浏览器还未默认开启，可是这一天的到来不会过久，又拍云牢牢跟随时代的步伐，但愿为互联网用户提供更安全、更快的加速体验，为推动互联网的发展贡献本身的力量。与此同时，咱们也很高兴成为国内较早支持 TLS 1.3 功能的 CDN 厂商。