HTTPS – TLS 1.3 为何性能和安全性更高？

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)。

ClientServer

Key^ClientHello
Exch|+key_share*
|+signature_algorithms*
|+psk_key_exchange_modes*
v+pre_shared_key*-------->
ServerHello^Key
+key_share*|Exch
+pre_shared_key*v
{EncryptedExtensions}^Server
{CertificateRequest*}vParams
{Certificate*}^
{CertificateVerify*}|Auth
{Finished}v
<--------[ApplicationData*]
^{Certificate*}
Auth|{CertificateVerify*}
v{Finished}-------->
[ApplicationData]<------->[ApplicationData]

ThebasicfullTLShandshake

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

ClientServer

ClientHello
+early_data
+key_share*
+psk_key_exchange_modes
+pre_shared_key
(ApplicationData*)-------->
ServerHello
+pre_shared_key
+key_share*
{EncryptedExtensions}
+early_data*
{Finished}
<--------[ApplicationData*]
(EndOfEarlyData)
{Finished}-------->
[ApplicationData]<------->[ApplicationData]

MessageFlowfora0-RTTHandshake

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：签名

TransportLayerSecurity
TLSv1.3RecordLayer:HandshakeProtocol:ClientHello
Version:TLS1.0(0x0301)
HandshakeProtocol:ClientHello
HandshakeType:ClientHello(1)
Version:TLS1.2(0x0303)
Random:77f485a55b836cbaf4328ea270082cdf35fd8132aa7487eae19997c8939a292a
SessionID:8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee
CipherSuites(16suites)
CipherSuite:Reserved(GREASE)(0x1a1a)
CipherSuite:TLS_AES_128_GCM_SHA256(0x1301)
CipherSuite:TLS_AES_256_GCM_SHA384(0x1302)
CipherSuite:TLS_CHACHA20_POLY1305_SHA256(0x1303)
Extension:signature_algorithms(len=18)
Extension:supported_groups(len=10)
SupportedGroups(4groups)
SupportedGroup:Reserved(GREASE)(0xcaca)
SupportedGroup:x25519(0x001d)
SupportedGroup:secp256r1(0x0017)
SupportedGroup:secp384r1(0x0018)
Extension:key_share(len=43)
Type:key_share(51)
KeyShareextension
ClientKeyShareLength:41
KeyShareEntry:Group:Reserved(GREASE),KeyExchangelength:1
KeyShareEntry:Group:x25519,KeyExchangelength:32
Group:x25519(29)
KeyExchangeLength:32
KeyExchange:51afc57ca38df354f6d4389629e222ca2654d88f2800cc84f8cb74eefd473f4b
Extension:supported_versions(len=11)
Type:supported_versions(43)
SupportedVersionslength:10
SupportedVersion:TLS1.3(0x0304)
SupportedVersion:TLS1.2(0x0303)

Server Hello

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

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

TLSv1.3RecordLayer:HandshakeProtocol:ServerHello
ContentType:Handshake(22)
HandshakeProtocol:ServerHello
HandshakeType:ServerHello(2)
Version:TLS1.2(0x0303)
Random:1f354a11aea2109ba22e26d663a70bddd78a87a79fed85be2d03d5fc9deb59a5
SessionID:8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee
CipherSuite:TLS_AES_256_GCM_SHA384(0x1302)
CompressionMethod:null(0)
ExtensionsLength:46
Extension:supported_versions(len=2)
SupportedVersion:TLS1.3(0x0304)
Extension:key_share(len=36)
Type:key_share(51)
KeyShareextension
KeyShareEntry:Group:x25519,KeyExchangelength:32
Group:x25519(29)
KeyExchange: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” 消息，使用服务器私钥对握手信息做了一个签名，强化了安全措施。

TransportLayerSecurity
TLSv1.3RecordLayer:HandshakeProtocol:Certificate
TLSv1.3RecordLayer:HandshakeProtocol:CertificateVerify
HandshakeProtocol:CertificateVerify
SignatureAlgorithm:rsa_pss_rsae_sha256(0x0804)
SignatureHashAlgorithmHash:Unknown(8)
SignatureHashAlgorithmSignature:Unknown(4)
Signaturelength:256
Signature:03208990ec0d4bde4af8e2356ae7e86a045137afa5262ec7c82d55e95ba23b6eb5876ebb…
TLSv1.3RecordLayer:HandshakeProtocol:Finished
HandshakeProtocol:Finished
VerifyData

客户端切换加密模式

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

image.png