Tls v1.3的里程碑发展
原创
TLS v1.3在TLS v1.2的基础上，吸收了之前的设计，并且做了大量的改进。相对于TLS v1.2，协议更简洁、更安全、性能也更好。以下是对比TLS v.1.2说明TLSv1.3的变化。
一、重新设计协议
1.1．SSL握手对比
SSL握手完成双方鉴权Auth、协商对称密钥的过程。对比TLS1.2（图2）和TLS1.3（图3）的握手区别。TLS1.3重新设计了12种握手报文。相比TLS1.2，新增了Hello Retry Request、Early Data、End of Early Data、New Session Ticket、Key Update，废弃了Server Hello Done、Client Key Exchange、Server Key Exchange（图1）。
TLS1.2
Client | Server | |||
|---|---|---|---|---|
Client Params | ClientHello +Cipher Suite +List of supported groups/curves | ----> | ||
<---- | ServerHello +Chosen Cipher Suite | Server Params | ||
<---- | Certificate * | Auth | ||
<---- | ServerKeyExchange * | Key Exch | ||
<---- | CertificateRequest* | Auth | ||
<---- | ServerHelloDone | |||
Auth | Certificate* | ----> | ||
Key Exch | ClientKeyExchange | ----> | ||
Auth | CertificateVerify* | ----> | ||
[ChangeCipherSpec] Finished | ----> | |||
<---- | [ChangeCipherSpec] | |||
<---- | Finished | |||
Application Data | <---> | Application Data | ||
图2、TLS1.2的握手过程
TLS1.3
Client | Server | |||
|---|---|---|---|---|
Client Params | ClientHello +Cipher Suite +List of supported groups/curves | ----> | ||
Key Exch | + key_share* + signature_algorithms* + psk_key_exchange_modes* + pre_shared_key* | |||
<---- | ServerHello +Chosen Cipher Suite | Server Params | ||
<---- | + key_share* + pre_shared_key* | Key Exch | ||
<---- | {EncryptedExtensions} {CertificateRequest*} | Server Params | ||
<---- | ｛Certificate *｝ {CertificateVerify*} {Finished} | Auth | ||
Auth | ｛Certificate *｝ {CertificateVerify*} {Finished} | ----> | ||
Application Data | <---> | Application Data | ||
图3、TLS1.3的握手过程
变化点有如下：
- Key Exch生成算法不一样，TLS1.3使用HKDF，之前是使用PRF
- TLS1.3会话复用在ClientHello不用Session Ticket，而是使用Pre-Share-Key
- TLS1.3握手的鉴权阶段进行了消息加密，从而抓取信道无法查看到证书信息。
- 精简了协议：去除了Change Cipher Spec，Server Hello Done，密钥的改变不再需要发送change_cipher_spec报文给对方。
- 在ServerHello使用Change Cipher Spec切换成对称加密模式。
- 不再允许对加密报文进行压缩、不再允许双方发起重协商
1.2、更简洁设计
- TLS1.3禁止renegotiation。客户端尝试Renegotiation会导致连接错误。
- TLS1.3强制使用(EC)DHE key exchange，在服务器签名，key是前向安全的
- TLS1.3的PSK（Pre-shared Key）机制。使用PSK和(EC)DHE机制联合起来，增加前向安全（PSK-DEH mode， psk_deh_ke）。同时在0-RTT场景下，，PKI取代了Session ID和Session Ticket的作用，使用PSK的ID获取得到Session ticket。
- TLS1.3移除了compression，移除了DSA和DHE group
- 只支持5种加密套件(TLS v1.2，37种，之前版本319种)
二、更低时延
TLS1.3在时延上比TLS1.2更有优势。这里引用了cloudfare的示意图，在完全握手和会话复用场景下说明TLS1.3的优势。
2.1. 完全握手1-RTT（对比TLS 1.2的2-RTT）
lTLS 1.3（1-RTT）：TLS1.3提前发送Key Share，需要支持该特性的算法，比如 AES-GCM-SHA256 和ECDHE P-256。
lTLS 1.2 ECDHE（2-RTT）：TLS1.2需要完成ServerKeyExchange和ClientKeyExchange两个阶段完成整个Key-Share，协商完对称密钥。
2.2 会话复用0-RTT（对比TLS1.2的1-RTT）
lTLS 1.3（0-RTT）：用来实现0-RTT数据传输的Early Data（ED）报文： 如果使用了PSK协商密钥，可以利用双方都持有的PSK计算出一个early_key，使用该key在发送CH报文之后客户端就可以发送加了密的应用层数据（即ED）与服务端进行通讯，ED的发送与其他握手报文独立，即服务端不用等待接收到ED之后再向客户端发送SH，但是客户端一旦受到服务端发送的Finished报文，必须立即结束ED的发送，而转而发送一个End Of Early Data报文给服务端。除此之外，客户端也可以在early data正常发送完毕之后，发送End Of Early Data结束ED，而不需要等待收到服务端的Finished报文。Early-Data使用PSK派生密钥进行加密，没有forward Sec， 所以0-RTT的实现有一定的安全缺陷，自身没有抗重放攻击的机制。
lTLS 1.2 ECDHE（2-RTT）：TLS1.2使用会话复用机制。使用之前建立产生的Session ID/Ticket来还原加密通道，并在还原完成后发送应用层数据。
TLS1.2的1-RTT
TLS1.3的0-RTT
2.3 实验
Early data需要客户端和服务端同时支持。
使用openssl模拟的服务器，服务端设置，开启early—data模式：
openssl s_server -key key_path -cert cert_path-accept 8443 -tls1_3 -early_data
1-RTT
客户端首次访问，导出session数据
s_client -connect 127.0.0.1:8443 -tls1_3 -quiet -showcerts -debug -sess_out /tmp/session.dat
客户端第二次访问，使用首次访问的session，并且设置early data，early data的数据为
./openssl s_client -connect 127.0.0.1:8443 -tls1_3 -quiet -showcerts -debug -sess_out /tmp/session.dat -sess_in /tmp/session.dat -early_data /tmp/http.txt
http.txt的内容如下：
GET / HTTP/1.1
Host: mytest.com:8443
Wireshark观察1-RTT和0-RTT：
Tlsv1.2和TLSv1.3对比：
客户端的early-data请求
服务端看到的early-data
三、更安全
3.1、加密握手（隐私保护）
TLS1.3加密握手过程中除了ClientHello和ServerHello之外的所有数据。它使用从DH密钥交换派生的密钥加密消息。
3.2必须使用AEAD算法：
消息认证（message authentication）或数据源认证（data origin authentication）表示数据在传输过程中没有被修改（完整性），并且接收消息的实体能够验证消息的源（端点认证）。有三种组合方式：（1）Encrypt-and-MAC （2）MAC-then-Encrypt （3）Encrypt-then-MAC，根据最新密码学动态，目前学术界已经一致同意先加密后算消息认证码Encrypt-then-MAC是最安全。
有人提出将Encrypt和MAC直接集成在一个算法内部，让有经验的密码专家在算法内部解决安全问题，不让算法使用者选择，这就是这就是AEAD（Authenticated-Encryption With Addtional data）类的算法。TLS1.3彻底禁止AEAD以外的其他算法。
AEAD（Authenticated_Encrypted_with_associated_data）——唯一保留的加密方式。TLS协议的最终目的是协商出会话过程使用的对称密钥和加密算法，双方最终使用该密钥和对称加密算法对报文进行加密。
AEAD将完整性校验和数据加密两种功能集成在同一算法中完成，是TLS 1.3中唯一支持的加密方式。
AEAD算法和使用HKDF的hash算法组成了TLS1.3的可用密码套件
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
协议为新的cipher suite定义了新Value，和TLS1.2版本号是不兼容的 。openss1.1.1只支持前三个。如果是服务端选择默认的cipher，则是按此表格的先后顺序选择。
列出当前所有的cipher
openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g'
检查服务端支持的cipher
openssl s_client -ciphersuites TLS_AES_128_CCM_SHA256 -connect 127.0.0.1:8443 2>&1
目前版本的opensl 1.1.1支持RFC协议的前三种密码套件
3.3 加密套件更安全
针对以往的漏洞和攻击风险。TLS1.3做了以下改进。
- 移除加密算法-RC4，3DES，Camellia
- 移除hash算法-MD5，SHA-1
- 移除模式-AES-CBC
- 还移除包括：TLS压缩协议、会话复用DSA签名（ECDSA>=224bit）
3.4 禁止重协商（Renegotiation）和禁止压缩
测试重协商：
重协商失败。
禁用压缩是为了防范CRIME攻击
四、总结
总之，TLSv1.3重新设计了SSL/TLS协议，在保证更高安全的前提下，也优化了网络性能。TLS1.3+HTTP2.0/QUIC更是以后的趋势，将会有更大的市场占有率。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。