为了解决安全问题、提升性能，IETF于2018年发布了TLS协议的1.3版本，目前已在大量场景中应用。下面，将从商用密码应用安全性评估的视角对TLS1.3协议展开分析。

• 一、TLS1.3协议线

TLS1.3协议和早期版本一样，主要由握手协议和记录层协议组成，工作于应用层和传输层之间，框架见下图：

其中，记录层协议结构如下：

根据上图可知，握手协议、密码规格变更协议、报警协议和应用数据协议在记录层协议之上，通过不同的值来表示。例如，应用数据协议值为23，见下图：

Legacy record version用于兼容早期TLS版本。需要注意的是，为了实现最大向后兼容，初始Client Hello中的Legacy record version应为TLS1.0（0x0301），其他的消息中的Legacy record version应为TLS1.2（0x0303）。此字段仅起到兼容作用，不代表TLS实际协商后的版本。TLS版本与版本号对应关系见第三章。

 

• 二、TLS1.3握手过程

TLS1.2版本在2008年推出，到TLS1.3诞生已使用了十年之久，因此很多应用软件仅支持早期协议格式。为了尽快普及，TLS1.3的格式与早期版本保持一致，通过扩展来达到提升性能和安全性并向后兼容的目的。下图是TLS1.3协议的完整握手过程：

其中，+号代表重要扩展消息，*号代表可选或依赖上下文关系的消息，{}号代表被加密的握手消息，[]号代表不属于握手协议的被加密的应用数据消息。

在密钥交换阶段，客户端发送Client Hello消息给服务端，其中包含客户端随机数、supported_groups（客户端支持的密钥交换参数）、key_share（密钥交换参数和对应的客户端公钥）。

服务端返回Server Hello消息给客户端，其中包含服务端随机数、key_share（协商后的密钥交换参数和对应的服务端公钥）。

为了保证前向安全性，TLS1.3去掉了静态RSA和DH等密钥交换算法，目前仅支持ECDHE和DHE两种。因此，客户端和服务端可以在Server Hello消息之后就分别计算出预主密钥，再通过HKDF（HMAC-based Extract-and-Expand Key Derivation Function）生成主密钥，进而生成工作密钥用于保护后续消息。因此Change Cipher Spec消息之后的所有内容均为密文。

如上所述，TLS1.3握手过程与早期版本最大的不同是通过扩展将密钥交换参数发送提前，减少握手消息往返，使完整握手时间降低为1-RTT（Round-Trip Time）。在session 重用的场景，则将早期版本的session ID和session ticket更换为预共享密钥PSK（pre-shared key），从而Client Hello消息即可包含使用PSK加密的应用数据，使握手时间降低为0-RTT。不过0-RTT不具备前向安全性，可能导致重放攻击。

• 三、TLS1.3版本号

IETF将SSL标准化后，第一个TLS版本为1.0，版本号为0x0301，后续版本依次递增，TLS1.3版本号为0x0304，TLS几个版本与版本号的对应关系见下表。

TLS1.0	0x0301
TLS1.1	0x0302
TLS1.2	0x0303
TLS1.3	0x0304

前文提到TLS1.3采用扩展来实现新功能。为了实现与早期版本的兼容，TLS1.3在Client Hello和Server Hello里通过supported_versions扩展来协商TLS的版本。

    从Client Hello的结构体可以看出，legacy version默认为TLS1.2（0x0303），当supported version与legacy version不一致时，以supported version协商后的版本为准。如下图：

• 四、3支持的密码算法套件

TLS1.3协议的密码算法套件做了很大调整，仅保留AEAD算法（Authenticated Encryption with Associated Data）和2个SHA-2算法，如下表：

名称	AEAD算法	杂凑算法	值
TLS_AES_128_GCM_SHA256	AES-128-GCM	SHA-256	{0x13,0x01}
TLS_AES_256_GCM_SHA384	AES-256-GCM	SHA-384	{0x13,0x02}
TLS_CHACHA20_POLY1305_SHA256	CHACHA20_POLY1305	SHA-256	{0x13,0x03}
TLS_AES_128_CCM_SHA256	AES-128-CCM	SHA-256	{0x13,0x04}
TLS_AES_128_CCM_8_SHA256	AES-128-CCM-8	SHA-256	{0x13,0x05}

其中，AEAD算法用于实现通信数据完整性和通信过程中重要数据机密性，杂凑算法用于计算HKDF（HMAC-based Extract-and-Expand Key Derivation Function）。另外，TLS1.3强制要求支持TLS_AES_128_GCM_SHA256算法套件，从密码算法套件也可以间接确定通信信道TLS协议的版本。

当客户端既支持TLS1.2版本又支持TLS1.3版本时，Client Hello中将包含两种版本分别支持的密码算法套件，客户端从中选择自己也支持的密码算法套件，因此最终协商确定的密码算法套件可以从Server Hello中获取，如下图：

• 五、TLS1.3密钥交换

TLS1.3协议的密码算法套件中不再包含密钥交换算法。前文提到TLS1.3仅支持ECDHE和DHE两种密钥交换算法，加上新增的PSK，组合成三种密钥交换模式：

• （EC）DHE
• PSK-only
• PSK with (EC)DHE

第一种是完整握手时使用的模式，另外两种需要复用或者外部导入PSK。

我们先来看下第一种密钥交换模式。根据TLS1.3握手过程可知，supported_groups扩展代表密钥交换参数，支持DH参数和ECDH参数，优先级从高到低。其中，仅支持secp256r1,、secp384r1、secp521r1、 X25519 和 X448五条椭圆曲线用于ECDHE密钥交换。由于DH已逐渐退出历史舞台，此处不做分析。

如果需要采用PSK密钥交换模式，Client Hello中需要包含psk_key_exchange_modes扩展，包括psk_ke（PSK-only）和psk_dhe_ke（PSK with (EC)DHE）两种，同时需要包含pre_shared_key扩展，给出具体的PSK，PSK可为多条。服务端从客户端提供的PSK列表中进行选择，并通过Server Hello返回pre_shared_key扩展确定后续使用的PSK。需要注意的是，当需要在Client Hello中就发送应用数据时，需要包含early_data扩展并默认选择PSK第一条进行保护。

• 六、TLS1.3签名算法

  TLS1.3协议的密码算法套件中同样也不再包含签名算法。通过Client Hello的扩展来进行确认，其中signature_algorithms_cert扩展表示证书中使用的签名算法，即CA签发证书时的签名算法。signature_algorithms扩展表示CertificateVerify消息使用的签名，即身份鉴别算法。当未包含signature_algorithms_cert扩展时，证书中使用的签名算法应与signature_algorithms扩展一致。需要注意的是，签名算法是将任意长度的消息作为输入，而不是将摘要值作为输入。

TLS1.3支持以下签名算法：

其中，RSASSA-PKCS1-v1_5 algorithms和Legacy algorithms仅用于证书签发。下图为签名算法示例：

为了便于分析最终协商确定的签名算法，我们先对通信数据包进行解密，从Certificate Verify消息中即可分析出身份鉴别算法。

   其他测评按照常规流程操作即可。