社区编辑申请
注册/登录
HTTPS - TLS 1.3 为何性能和安全性更高?
安全 数据安全 通信技术
TLS v1.2 支持的加密套件很多,在兼容老版本上做的很全,里面有些加密强度很弱和一些存在安全漏洞的算法很可能会被攻击者利用,为业务带来潜在的安全隐患

2008 年 8 月 TLS v1.2 发布,时隔 10 年,TLS v1.3 于 2018 年 8 月发布,在性能优化和安全性上做了很大改变,同时为了避免新协议带来的升级冲突,TLS v1.3 也做了兼容性处理,通过增加扩展协议来支持旧版本的客户端和服务器。

安全性

TLS v1.2 支持的加密套件很多,在兼容老版本上做的很全,里面有些加密强度很弱和一些存在安全漏洞的算法很可能会被攻击者利用,为业务带来潜在的安全隐患。TLS v1.3 移除了这些不安全的加密算法,简化了加密套件,对于服务端握手过程中也减少了一些选择。

  • 移除 MD5、SHA1 密码散列函数的支持,推荐使用 SHA2(例如,SHA-256)。
  • 移除 RSA 及所有静态密钥(密钥协商不具有前向安全特性)。
  • 溢出 RC4 流密码、DES 对称加密算法。
  • 密钥协商时的椭圆曲线算法增加 https://www.wanweibaike.net/wiki-X25519 支持。
  • 支持带 Poly1305消息验证码 的 ChaCha20 流加密算法,流加密也是一种对称加密算法。
  • 移除了 CBC 分组模式,TLS v1.3 对称加密仅支持 AES GCM、AES CCM、ChaCha20**-**Poly1305 三种模式。
  • 服务端 “Server Hello” 之后的消息都会加密传输,因此常规抓包分析就会有疑问为什么看不到证书信息。

性能优化

性能优化一个显著的变化是简化了 TLS 握手阶段,由 TLS v1.2 的 2-RTT 缩短为 1-RTT,同时在第一次建立链接后 TLS v1.3 还引入了 0-RTT 概念。

来源 https://www.a10networks.com/wp-content/uploads/differences-between-tls-1.2-and-tls-1.3-full-handshake.png

 

密钥协商在 TLS v1.2 中需要客户端/服务端双方交换随机数和服务器发送完证书后,双方各自发送 “Clent/Server Key Exchange” 消息交换密钥协商所需参数信息。在安全性上,TLS v1.3 移除了很多不安全算法,简化了密码套件,现在已移除了 “Clent/Server Key Exchange” 消息,在客户端发送 “Client Hello” 消息时在扩展协议里携带支持的椭圆曲线名称、临时公钥、签名信息。服务器收到消息后,在 “Server Hello” 消息中告诉客户端选择的密钥协商参数,由此可少了一次消息往返(1-RTT)。

  1.    Client                                           Server 
  2.  
  3. Key  ^ ClientHello 
  4. Exch | + key_share* 
  5.      | + signature_algorithms* 
  6.      | + psk_key_exchange_modes* 
  7.      v + pre_shared_key*       --------> 
  8.                                                   ServerHello  ^ Key 
  9.                                                  + key_share*  | Exch 
  10.                                             + pre_shared_key*  v 
  11.                                         {EncryptedExtensions}  ^  Server 
  12.                                         {CertificateRequest*}  v  Params 
  13.                                                {Certificate*}  ^ 
  14.                                          {CertificateVerify*}  | Auth 
  15.                                                    {Finished}  v 
  16.                                <--------  [Application Data*] 
  17.      ^ {Certificate*} 
  18. Auth | {CertificateVerify*} 
  19.      v {Finished}              --------> 
  20.        [Application Data]      <------->  [Application Data] 
  21.                                                  
  22.                        The basic full TLS handshake 

当访问之前访问过的站点时,客户端可以通过利用先前会话中的 预共享密钥 (PSK) 将第一条消息上的数据发送到服务器,实现 “零往返时间(0-RTT)”。

  1. Client                                               Server 
  2.  
  3. ClientHello 
  4. + early_data 
  5. + key_share* 
  6. + psk_key_exchange_modes 
  7. + pre_shared_key 
  8. (Application Data*)     --------> 
  9.                                                 ServerHello 
  10.                                            + pre_shared_key 
  11.                                                + key_share* 
  12.                                       {EncryptedExtensions} 
  13.                                               + early_data* 
  14.                                                  {Finished} 
  15.                         <--------       [Application Data*] 
  16. (EndOfEarlyData) 
  17. {Finished}              --------> 
  18. [Application Data]      <------->        [Application Data] 
  19.  
  20.               Message Flow for a 0-RTT Handshake 

TLS v1.3 抓包分析

以一次客户端/服务端完整的 TLS 握手为例,通过抓包分析看下 TLS v1.3 的握手过程。下图是抓取的 www.zhihu.com 网站数据报文,且对报文做了解密处理,否则 “Change Cipher Spec” 报文后的数据都已经被加密是分析不了的。抓包请参考 “网络协议那些事儿 - 如何抓包并破解 HTTPS 加密数据?”。

image.png

TLS v1.3 握手过程如下图所示:

tls-1-3-full-handshake.jpg

Client Hello

握手开始客户端告诉服务端自己的 Random、Session ID、加密套件等。

除此之外,TLS v1.3 需要关注下 “扩展协议”,TLS v1.3 通过扩展协议做到了 “向前兼容“,客户端请求的时候告诉服务器它支持的协议、及一些其它扩展协议参数,如果老版本不识别就忽略。

下面看几个主要的扩展协议:

  • supported_versions:客户端支持的 TLS 版本,供服务器收到后选择。
  • supported_groups:支持的椭圆曲线名称
  • key_share:椭圆曲线名称和对应的临时公钥信息。
  • signature_algorithms:签名
  1. Transport Layer Security 
  2.     TLSv1.3 Record Layer: Handshake Protocol: Client Hello 
  3.         Version: TLS 1.0 (0x0301) 
  4.         Handshake Protocol: Client Hello 
  5.             Handshake Type: Client Hello (1) 
  6.             Version: TLS 1.2 (0x0303) 
  7.             Random: 77f485a55b836cbaf4328ea270082cdf35fd8132aa7487eae19997c8939a292a 
  8.             Session ID: 8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee 
  9.             Cipher Suites (16 suites) 
  10.                 Cipher Suite: Reserved (GREASE) (0x1a1a) 
  11.                 Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) 
  12.                 Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) 
  13.                 Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) 
  14.             Extension: signature_algorithms (len=18
  15.             Extension: supported_groups (len=10
  16.                 Supported Groups (4 groups) 
  17.                     Supported Group: Reserved (GREASE) (0xcaca) 
  18.                     Supported Group: x25519 (0x001d) 
  19.                     Supported Group: secp256r1 (0x0017) 
  20.                     Supported Group: secp384r1 (0x0018) 
  21.             Extension: key_share (len=43
  22.                 Type: key_share (51) 
  23.                 Key Share extension 
  24.                     Client Key Share Length: 41 
  25.                     Key Share Entry: Group: Reserved (GREASE), Key Exchange length: 1 
  26.                     Key Share Entry: Group: x25519, Key Exchange length: 32 
  27.                       Group: x25519 (29) 
  28.                       Key Exchange Length: 32 
  29.                       Key Exchange: 51afc57ca38df354f6d4389629e222ca2654d88f2800cc84f8cb74eefd473f4b 
  30.             Extension: supported_versions (len=11
  31.                 Type: supported_versions (43) 
  32.                 Supported Versions length: 10 
  33.                 Supported Version: TLS 1.3 (0x0304) 
  34.                 Supported Version: TLS 1.2 (0x0303) 

Server Hello

服务端收到客户端请求后,返回选定的密码套件、Server Random、选定的椭圆曲线名称及对应的公钥(Server Params)、支持的 TLS 版本。

这次的密码套件看着短了很多 TLS_AES_256_GCM_SHA384,其中用于协商密钥的参数是放在 key_share 这个扩展协议里的。

  1. TLSv1.3 Record Layer: Handshake Protocol: Server Hello 
  2.     Content Type: Handshake (22) 
  3.     Handshake Protocol: Server Hello 
  4.         Handshake Type: Server Hello (2) 
  5.         Version: TLS 1.2 (0x0303) 
  6.         Random: 1f354a11aea2109ba22e26d663a70bddd78a87a79fed85be2d03d5fc9deb59a5 
  7.         Session ID: 8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee 
  8.         Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) 
  9.         Compression Method: null (0) 
  10.         Extensions Length: 46 
  11.         Extension: supported_versions (len=2
  12.             Supported Version: TLS 1.3 (0x0304) 
  13.         Extension: key_share (len=36
  14.             Type: key_share (51) 
  15.             Key Share extension 
  16.                 Key Share Entry: Group: x25519, Key Exchange length: 32 
  17.                     Group: x25519 (29) 
  18.                     Key Exchange: ac1e7f0dd5a4ee40fd088a8c00113178bafb2df59e0d6fc74ce77452732bc44d 

服务端此时拿到了 Client Random、Client Params、Server Random、Server Params 四个参数,可优先计算出预主密钥。在 TLS v1.2 中是经历完第一次消息往返之后,客户端优先发起请求。

在计算出用于对称加密的会话密钥后,服务端发出 Change Cipher Spec 消息并切换到加密模式,之后的所有消息(证书、证书验证)传输都会加密处理,也减少了握手期间的明文传递。

Certificate、Certificate Verify、Finished

除了 Certificate 外,TLS v1.3 还多了个 “Certificate Verify” 消息,使用服务器私钥对握手信息做了一个签名,强化了安全措施。

  1. Transport Layer Security 
  2.     TLSv1.3 Record Layer: Handshake Protocol: Certificate 
  3.     TLSv1.3 Record Layer: Handshake Protocol: Certificate Verify 
  4.         Handshake Protocol: Certificate Verify 
  5.             Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) 
  6.                 Signature Hash Algorithm Hash: Unknown (8) 
  7.                 Signature Hash Algorithm Signature: Unknown (4) 
  8.             Signature length: 256 
  9.             Signature: 03208990ec0d4bde4af8e2356ae7e86a045137afa5262ec7c82d55e95ba23b6eb5876ebb… 
  10.     TLSv1.3 Record Layer: Handshake Protocol: Finished 
  11.         Handshake Protocol: Finished 
  12.             Verify Data 

客户端切换加密模式

客户端获取到 Client Random、Client Params、Server Random、Server Params 四个参数计算出最终会话密钥后,也会发起 “Certificate Verify”、“Finished” 消息,当客户端和服务端都发完 “Finished” 消息后握手也就完成了,接下来就可安全的传输数据了。

image.png

 

责任编辑:赵宁宁 来源: 编程界
相关推荐

2022-05-18 23:42:08

网络安全安全分析工具

2022-05-20 14:54:33

数据安全数字化转型企业

2022-03-05 18:25:51

SSLTLS协议

2022-04-14 10:10:59

Nginx开源Linux

2022-05-17 15:51:32

数据中心运维能力基础设施

2022-05-17 14:03:42

勒索软件远程工作

2022-05-16 13:37:12

Sysrv僵尸网络微软

2022-01-06 10:23:49

2022-04-28 09:46:20

Nginx文件Linux

2022-05-10 14:11:05

网络安全网络犯罪

2022-05-11 14:05:11

区块链网络安全存储

2022-05-26 11:37:58

亚马逊云科技C7g实例

2022-04-21 10:01:48

VMware

2022-05-25 10:04:43

Go编程

2022-05-24 12:05:36

Testin云测试

2022-05-03 23:21:13

安全意识网络安全网络钓鱼

2022-05-25 16:52:55

数据智能瑞数信息API

2022-05-09 11:57:39

云原生实践安全

2022-02-24 07:34:10

SSL协议加密

2022-05-24 08:21:16

数据安全API

同话题下的热门内容

Veeam公布2022年勒索软件趋势:受害者只能恢复69%的受损数据POWERSUPPLaY:电源变扬声器,泄漏你的隐私信息构建数据成熟度模型和数据成熟度的四个阶段数据访问管理基础和实施策略

编辑推荐

网络管理员的利器之9款值得关注的Ping监控工具2020年漏洞扫描工具Top10细说七大邮件安全协议的实现原理安全趣闻 | “ji32k7au4a83”竟然是一个典型弱密码用于渗透测试的10种漏洞扫描工具
我收藏的内容
点赞
收藏

51CTO技术栈公众号