mg不朽情缘

为相识决安全问题、提升机能
，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新闻中即可分析出身份甄别算法。

   其他测评依照通例流程操作即可。