TLS原理与实践（三）tls1.3

TLS1.3协议

TLS1.3加密套件

TLS1.3支持的加密套件如下：

TLS_AES_128_GCM_SHA256

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

从 加密套件 上看，与tls1.2相比（如： tls_ecdhe_ecdsa_with_aes_128_gcm_sha256 ）, tls1.3协议支持的加密套件不再包含 密钥协商算法 和 签名算法 ，仅包含加密和摘要算法，这是因为在TLS 1.3中：

所有密钥协商默认使用


    ECDHE算法

，这意味着在握手过程中，客户端和服务器都使用


    椭圆曲线密钥协商

来生成共享的对称密钥。椭圆曲线Diffie-Hellman密钥交换提供了


    强大的安全性

和


    前向保密性

，可以抵抗主动攻击和被动监听。

TLS1.3


    允许

客户端和服务器


    选择适当的签名算法

，以实现身份验证和握手完整性的保护。这种


    灵活性

和


    可扩展性

是TLS 1.3设计的一部分，以提供更安全和可靠的通信。

TLS1.3仅支持AEAD带认证的加密算法，不再支持CBC模式的加密算法，提高了加密数据的安全性

注：需要注意的是，尽管TLS1.3 默认使用ECDHE 作为密钥协商算法，但仍然 可以通过配置选择 其他密钥交换算法，如基于RSA的密钥交换（RSA Key Exchange）。然而，在TLS 1.3中，推荐使用ECDHE来获得更高的安全性和性能。

TLS1.3握手协议

TLS1.3协议握手流程如下 ( 来源 rfc8446 ）

表示在先前提到的消息中发送的值得注意的扩展。

表示可选或情境依赖的消息/扩展，不一定总是发送。

{}

表示使用从 [sender]_handshake_traffic_secret 导出的密钥保护的消息。

[]

表示使用从 [sender]_application_traffic_secret_N 导出的密钥保护的消息。

从上图可以看到，握手可以看作有三个阶段（如上图所示）：

密钥交换（Key Exchange）：建立共享的密钥材料并


    选择加密参数

。此阶段之后的所有内容都是加密的。

服务器参数（Server Parameters）：


    建立其他握手参数

（如客户端是否经过身份验证、应用层协议支持等）。

身份验证（Authentication）：对服务器（以及可选地对客户端）进行


    身份验证

，并提供


    密钥确认

和


    握手完整性

。

密钥交换（Key Exchange)

在 密钥交换 阶段，客户端发送ClientHello消息，其中包含：

随机的nonce（ClientHello.random);

所提供的协议版本；

一组对称密码算法/HKDF哈希对；

Diffie-Hellman共享密钥(在"key_share"扩展中)、预共享密钥标签集合(在"pre_shared_key"扩展中), 或两者都有；

可能的其他扩展。

服务器处理ClientHello并确定适当的加密参数。然后通过ServerHello响应，指示协商的连接参数。ClientHello和ServerHello的组合确定了共享密钥。

如果使用了(EC)DHE密钥协商，则ServerHello包含服务器临时生成DH公钥的


    key_share

扩展。

如果使用PSK密钥协商，则ServerHello包含一个


    pre_shared_key

扩展，指示选择了客户端提供的PSK中的哪一个。

请注意，实现可以同时使用(EC)DHE和PSK，在这种情况下ServerHello将提供两个扩展。

服务器参数(Sever Parameters)

然后，服务器发送两个消息以建立服务器参数：

EncryptedExtensions：对于不需要确定密码参数的ClientHello扩展的响应。

CertificateRequest：如果需要客户端身份证书验证，则为该证书的所需参数。如果不需要客户端身份验证，则省略此消息。

身份验证（Authentication)

最后，客户端和服务器交换身份验证消息。具体来说：

Certificate：


    服务端证书

和证书相关的扩展。如果不使用证书进行身份验证，则服务器会省略此消息；如果使用原始公钥[RFC7250]或缓存的信息扩展[RFC7924]，则此消息将不包含证书，而是包含与服务器的长期密钥对应的其他信息。

CertificateVerify：使用Certificate消息中公钥对应的私钥对整个


    握手消息

进行


    签名

。如果不通过证书进行身份验证，则省略此消息。

Finished：对应整个握手的


    消息认证码MAC

。此消息提供密钥确认，将客户端/服务端的身份与交换的密钥绑定，并在PSK模式下还进行握手身份验证。

收到服务器的消息后，客户端通过其身份验证消息（即Certificate和CertificateVerify（如果有请求）和Finished）做出响应。
此时，握手过程完成，客户端和服务器生成了记录层所需的 密钥材料 ，以通过加密来交换应用层数据。在发送Finished消息之前，不得发送应用数据。

TLS1.3协议wireshark抓包分析

在 TLS原理与实践（二）中，我们使用 tcpdump 对 TLS1.2协议 的demo程序进行了抓包，并使用 wireshark 进行了分析。我们使用同样的方法，对TLS1.3进行抓包分析， （注:在我们的demo程序中，仅模拟了服务器单项认证的场景) , 抓包过程如下：

启动抓包程序：我们使用tcpdump进行抓包

启动tls服务：该demo程序服务端仅支持TLS1.3协议

启动tls客户端：该demo程序客户端支持多种版本TLS协议，我们通过


    tlsVersion 1.3

指定仅使用TLS1.3

结束抓包程序：当客户端控制台打印


    hello world

时，表明握手和传输应用数据完成。我们通过


    ctrl + c

手动关闭tcpdump抓包程序，抓包程序会将捕获的网络数据保存到


    capture.pcap

文件中。

下面我们将 capture.pcap 导入或拖入 wireshark 程序，对TLS1.3协议进行分析：

从概览图中我们可以看到，TLS1.3握手协议8个记录被封装到3个tcp协议包中完成：

Client Hello

Server Hello，Change Cipher Spec, Application Data，Application Data，Application Data，Application Data

Change Cipher Spec, Application Data

Change Cipher Spec这个记录用于较早版本TLS中，在TLS1.3不再需要。在


    中间盒兼容模式

中，发送这个记录可以帮助伪装会话为TLS 1.2会话。

在第2个协议包中包含4个


    Application Data

实质代表的是


    被加密的握手协议记录

，分别对应


    EncryptedExtensions


    Certificate


    CertificateVerify

和


    Finished

在第3个协议中包含的


    Application Data

实质为应用层数据，这里代表客户端请求的数据（密文形式）

“中间盒兼容模式”: 在TLS 1.3中，引入了"中间盒兼容模式"（middlebox compatibility mode）的概念，这是为了解决某些网络中存在的中间设备（如防火墙、代理服务器等）可能不支持或不理解TLS 1.3协议的情况。由于TLS 1.3在协议设计和加密套件选择方面与TLS 1.2有很大的差异，一些网络设备可能无法正确解析或处理TLS 1.3的通信。为了绕过这些设备的限制，TLS 1.3引入了中间盒兼容模式。在中间盒兼容模式下，TLS 1.3的客户端会发送一个伪装为TLS 1.2的记录（record）。这个伪装的记录可以欺骗中间设备，使其认为通信是基于TLS 1.2协议进行的，从而绕过了对TLS 1.3的限制。需要注意的是，中间盒兼容模式只是一种临时解决方案，旨在帮助过渡期内的网络设备与TLS 1.3兼容。随着时间的推移，网络设备应该升级并支持TLS 1.3以享受其更强大的安全性和性能优势。

Client Hello消息

消息发送：客户端 -> 服务端

我们按照图中的序号进行分析：

表明该握手协议发送的为Client Hello消息

伪装的TLS协议版本，在TLS1.3


    中间盒兼容模式

中，此处的版本号仅用于兼容TLS1.2模式，用于欺骗中间设备，绕过对TLS1.3协议的限制（这里的中间设备目前支持的最高TLS版本为TLS1.2）

客户端随机数，tls1.3协议Client Hello中的Random作用与TLS1.2相同，充当随机数种子

支持的加密套件。从图中可以看出客户端支持的加密套件(Cipher Suites)列表一共有19个。

TLS1.3协议支持的加密套件。TLS1.3废弃了不安全或存在安全隐患的加密套件（16个），新增了3个更加安全的加密套件(本文开头已介绍，不在赘述）

在TLS1.3中，扩展字段发挥了重要作用，Client Hello消息包含的主要扩展字段（如上图) 有：

客户端支持的椭圆曲线算法


    Supported Groups

列表，这里的EC算法主要用于密钥协商，按照优先级排列

客户端支持的签名算法


    signature_algorithms

列表，用于身份认证

客户端支持的TLS版本，这里的版本为实际支持的TLS版本，由于我们在demo里，通过tlsVersion设置了TLS协议版本为

1.3

，所以这里显示客户端支持的TLS版本列表为


    TLS1.3

客户端选用的椭圆曲线算法，客户端使用了


    x25519

椭圆曲线算法来生成了


    预备主密钥

的客户端部分。

Server Hello消息

消息发送: 服务端 -> 客户端

Server Hello消息与Change Cipher Spec, Application Data，Application Data，Application Data，Application Data消息在同一个TCP包中发送。

基于上图，我们按照序号分析：

表明发送的握手协议包为


    ServerHello消息

(伴随了其他握手消息的密文，在同一个TCP包中发送）

服务端随机数，tls1.3协议Server Hello中的Random作用与TLS1.2相同，用作随机数种子

协商的加密套件，从上图中我们可以看到，客户端/服务端最终协商使用的加密套件为


    TLS_AES_128_GCM_SHA256

协商的tls协议版本，为TLS1.3

协商使用的


    密钥协商

用到的椭圆曲线算法，从图中可以看到为


    x25519

，这也是Client Hello中客户端优先选用的算法。在


    Key Exchange

字段携带了服务端生成的共享密钥

此消息


    Change Cipher Spec

在TLS1.3中不使用，仅用于兼容（本文前言部分已介绍，不在赘述）

Application Data消息一共有4个，这里为密文形式，从这里我们可以了解到，与TLS1.2相比，TLS1.3提供了更强大的保密能力。这里被加密的消息，与TLS1.2中的消息类似，主要用于客户端/服务端身份验证，不在赘述。

Change Cipher Spec

消息发送：客户端 -> 服务端
Change Cipher Spec消息Application Data消息在同一个TCP包中发送。

Change Cipher Spec消息：略

Application Data：客户端请求数据的密文形式

本文详细介绍了TLS1.3协议的握手流程，通过wireshark抓包分析，我们可以看到与TLS1.2相比，TLS1.3在握手效率、消息保密性上具有更大的优势。应用系统接入TLS1.3也将是一种未来趋势。

TLS原理与实践（二）： https://www.cnblogs.com/informatics/p/17517627.html

tcpdump： http://www.tcpdump.org

wireshark: https://www.wireshark.org

practical-crypto: https://github.com/warm3snow/practical-crypto.git

TLS1.3 RFC文档： https://datatracker.ietf.org/doc/html/rfc8446