码迷,mamicode.com
首页 > Web开发 > 详细

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

时间:2018-01-16 18:20:29      阅读:3236      评论:0      收藏:0      [点我收藏+]

标签:cdn   平台   自己的   max   data-   rom   ref   change   image   

随着互联网的发展,用户对网络速度的要求也越来越高,尤其是目前在大力发展 HTTPS 的情况下,TLS 加密协议变得至关重要。又拍云在 HTTPS 的普及和性能优化上,始终做着自己的努力和贡献。2018年初,又拍云 CDN 网络部署了 TLS 1.3,进一步提升了用户的访问速度与安全。

什么是 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 的主要区别在于:

  • 新的加密套件只能在 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 与以前的版本相比具有如下两个大的优势,分别是:

  • 更快的访问速度
  • 增强安全性

TLS 1.3 作用

1. 更快的访问速度

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

技术分享图片

 

△ TLS 1.2 完整握手框架( 来自 RFC 5246 )

从上图可以看出,使用 TLS 1.2 需要两次往返( 2-RTT )才能完成握手,然后才能发送请求。

技术分享图片

 

△ 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 厂商。

 

推荐阅读

HTTPS系列干货(一):HTTPS 原理详解

从 HTTP 到 HTTPS 再到 HSTS

 

参考文档:

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

标签:cdn   平台   自己的   max   data-   rom   ref   change   image   

原文地址:https://www.cnblogs.com/upyun/p/8296404.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!