共计 32709 个字符，预计需要花费 82 分钟才能阅读完成。
引言
在 HTTP – HTTPS（TLS1.2）中，咱们介绍了目前世界支流的 TLS1.2 协定的相干知识点，文中从 HTTP 的缺点、SSL 的历史、信息加密的次要伎俩、数字证书、以及最为要害的 TLS1.2 交互过程介绍了现今 HTTPS 的要害局部内容。
TLS1.3 在曾经 2018 年退场，这一节咱们来看看依据 TLS1.3 协定整体大抵讲了什么内容。
因为 TLS1.2 曾经做的比较完善，TLS1.3 的次要改良集体认为要害分为三个次要改良指标：兼容 、 平安与性能。
工夫线
TLS 1.3 改良点
兼容性
TLS1.2 倒退了很多年了，基本上少数网络设备对于这个版本的协定产生了依赖性，如果间接用 TLS1.3 的版本协定替换掉 TLS1.2，大量的代理服务器、网关都无奈正确处理，TLS1.2 存在微小的历史包袱。
TLS1.3 显然是没法撼动 TLS1.2 这个“老皇帝”的，这要怎么办呢？所以 TLS1.3 想到了一招“垂帘听政”，既然没法替换掉，那就是借用“TLS1.2”的名号进行传输数据，也就是所谓的“假装”。
那么该怎么辨别 TLS1.2 和 TLS1.3 呢？这时候就要用到 扩大协定（Extension Protocol），裁减协定有点相似“追加条款”，只反对 TLS1.2 的服务器，当无奈辨认扩大协定而被疏忽进化为 TLS1.2 握手，反之则认为能够进行 TLS1.3 协定握手。留神这里的进化还不止那么简略，TLS1.3 的进化只反对 TLS1.2，不反对 TLS1.2 以下任何版本，所以这一招还偷偷把一些老古董请上来。
TLS1.3 的改良是形式记录头部的 Version 字段“固定不变”，以及在进行第一步Hello 交互之后须要立即发送 supported_versions 的音讯示意本人反对 TLS1.3 协定，相似信号通知对方本人理论的 TLS 的版本号，也是新旧协定的次要分水岭。
TLS1.3 在握手的时候会呈现上面的变动：
Handshake Protocol: Client Hello
Version: TLS 1.2 (0x0303)
Extension: supported_versions (len=11)
Supported Version: TLS 1.3 (0x0304)
Supported Version: TLS 1.2 (0x0303)平安强化：“瘦身”
TLS1.2 尽管在平安方面曾经显得非常欠缺了，然而通过多年的考验还是发现不少的问题。所以 TLS1.3 次要是给 TLS1.2 遗留问题进行修复，比如说进行了上面的调整：
- 伪随机数函数由 PRF 降级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）；
- 明确禁止在记录协定里应用压缩，因为应用压缩被是存在破绽的并且有可能被黑客用非凡算法破解；（详情参考文章开端“TLS1.2 攻打伎俩”）
- 破除了 RC4、DES 对称加密算法；
- 破除了 ECB、CBC 等传统分组模式；
- 破除了 MD5、SHA1、SHA-224 摘要算法；
- 破除了 RSA、DH 密钥替换算法和许多命名曲线;
- ServerHello 之后的所有握手音讯采取了加密操作，可见明文大大减少;
- DSA 证书不再容许在 TLS 1.3 中应用;
下面这些点说是强化。更像是“瘦身”，因为废除了很多被证实不平安的算法。
还记得 PRF 么？在 TLS1.2 中用于最初确定会话密钥的要害函数。
在 RFC 的原文中，最终在 TLS1.3 中定义了上面的加密套件，然而须要留神 TLS1.3 的加密套件尽管看起来和 TLS1.2 有局部重合，然而 TLS 1.3 为了进一步简化加密套件的概念，TLS1.3 的加密套件实际上指的是 对称加密密钥 的协商，它是无奈和 TLS1.2 间接套用“兼容”的。
This specification defines the following cipher suites for use with
TLS 1.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} |
+------------------------------+-------------+以 TLS_AES_128_CCM_SHA256 为例，TLS 表明该加密组件用于 TLS 协定，AES 表明应用 AES 对称加密算法，128 示意密钥长度为 128 位，CCM 表明分组加密模式，SHA256 是 HKDF 过程应用的哈希算法。
理解下面的这些内容之后，读者可能会问为什么要放弃应用 DH 和RSA算法？这里波及 TLS1.2 到底有哪些攻打伎俩，为了不扩散留神，我把这些内容放到了开端“扩大常识”中的“已知 TLS1.2 攻打伎俩”局部介绍。
从这一部分内容能够发现 RSA 密钥在不少的算法中都有破绽，比方最为致命的 前向安全性 问题，所谓的前向安全性，指的是 RSA 算法自身的安全性存在破绽，一旦黑客破解出 RSA 的密钥的私钥，如果此时黑客刚好有网站此前所有的申请报文，就能够私钥把之前所有的传输加密报文解密，并且获取所有的用户信息，RSA 的最大问题在于密钥的变动永远是单方向的。
ECDHE 加密算法，简略了解是在进行握手的时候应用长期的椭圆函数曲线公钥作为“根”，利用数学公式推导计算替换密钥，而不是传统的非对称加密算法爱护堆对称加密密钥和进行密钥协商，每一次 TLS 连贯的所有参加密钥都是长期生成的，哪怕黑客真的手眼通天被破开某个申请的私钥，也只能获取到以后申请的相干信息，无奈用于其余申请，因而是具备前向安全性的。
此外，TLS 1.3 仅反对速度快安全性强的加密规范算法AES，以及性能耗费极低的CHACHA20。
留神 CHACHA20 是和 POLY1305 搭配应用的，这是因为 CHACHA20 在进行 AEAD 运算时，CHACHA20 自身不能提供完整性校验 性能，因而还须要借助 POLY1305 这种不消耗性能的 MAC 算法来提供完整性校验的性能。
分组加密模式则剩下 CCM 和 GCM，淘汰了 ECB、CBC 等有已知的攻击方式的不平安算法，目前都是实践上平安的算法，不容易被攻击者破解。
晋升性能
性能提醒是 TLS1.3 的一个要害局部，因为随着 HTTP/ 2 的性能全面晋升和 HTTP/ 3 的进一步倒退，加密传输的效率也成为了 TLS 倒退的重要瓶颈，在 TLS1.3 中利用扩大字段 extension 做了很多细节改善。咱们间接从 RFC 规范比照 TLS1.2 和 TLS1.3 的变动。
TLS1.3：
Client Server
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*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]上面是符号对应的作用
+ Indicates noteworthy extensions sent in the previously noted message.
* Indicates optional or situation-dependent messages/extensions that are not always sent.
{} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N.
翻译过去就是：
-
- 示意该报文中值得注意的 extension
-
- 示意该内容也可能不被发送
- {} 示意该内容应用 handshake_key 加密
- [] 示意该内容应用 application_key 加密
能够看到 Key Exchange 被删除了，对于加密套件的传输间接放到 ClientHello 外面，通过 1 -RTT 的 ClientHello 和ServerHello单方就能够协商出对称加密密钥（或会话加密密钥）。
被比照的 TLS 1.2 协定传输流程：
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data重点优化
除了 TLS 握手流程的调整，TLS1.3 还存在上面的一些重要优化和改良。
子协定优化
TLS 1.3 包含 3 个子协定——Alert、Handshake、Record。
Handshake：协定负责协商应用的 TLS 版本、加密算法、哈希算法、密钥资料和其余与通信过程无关的信息，对服务器进行身份认证，对客户端进行可选的身份认证，最初对整个握手阶段信息进行完整性校验以防备中间人攻打，是整个 TLS 协定的外围。
Alert：协定负责对接管到的报文进行加密解密，将其分片为适合的长度后转发给其余协定层。Alert 层负责解决 TLS 连贯过程中的各种异常情况，对每种状况发送一个 alert 报文，报文中附加一些错误处理须要的必要信息，TLS 1.3 中定义了 30 种 alert 报文。
Alert 协定内容会在下文介绍。
Record：负责解决音讯传输与握手阶段中的异常情况。Record 协定内容也会在下文进行介绍。
和 TLS1.2 不同的是 TLS1.3 删除了 变更明码标准协定（Change Cipher Spec Protocol），密钥的应用和扭转随着服务器和客户端状态的扭转天然进行。
TLS 1.2 协定的次要子协定内容：
- 记录协定（Record Protocol）
- 警报协定（Alert Protocol）
- 握手协定（Handshake Protocol）
- 变更明码标准协定（Change Cipher Spec Protocol）
PSK（pre_shared_key）新身份认证机制
PSK
PSK 是一种须要肯定满足条件的 身份认证机制，次要作用有三点：
- 进步身份认证的速度。
- 取代会话 Session Id 进行会话重用。
- 0-RTT 握手。（肯定的安全性作为代价）
PSK 和(EC)DHE 密钥是 TLS1.3 其中一种次要密钥替换算法，PSK 能够与(EC)DHE 密钥替换一起应用，两者并不抵触，比方 PSK 能够与(EC)DHE 联合提供更强的安全性，当然 PSK 也能够独自应用，独自应用的时候次要作为 TLS1.3 的会话重用以及实现 0 -RTT。
留神，如果服务器是通过 PSK 进行认证，那么它 不会发送证书或证书验证音讯，这一点能够从上面的替换步骤 理解到。当客户机通过 PSK 尝试复用连贯时，应该向服务器提供一个“key_share“扩大放在扩大字段，同时容许服务单回绝连贯复用，并且在须要时回退到残缺握手。
PSK 能够认为是对于身份认证这一步骤进行减速的形式，也能够看作是 Session Ticket 机制（也叫做 SSL session resumption）的一个降级。
TLS 握手完结后，服务器能够发送一个 NST（new_session_ticket）的报文给客户端，该报文中记录 PSK 的值、名字和有效期等信息，单方下一次建设连贯能够应用该 PSK 值作为初始密钥资料。
SSL session resumption 的原理是在服务端缓存所有的 session，客户端之后在每次和服务端握手时通过 Session ID 实现 session resumption。
而在 RFC 的规范中pre_shared_key（PSK）的次要应用流程如下：
Client Server
# 初始连贯
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
# 第二次连贯
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]留神：下面的解决流程中，PSK 解决形式看起来相似 Cookie，然而实际上差异很大，齐全不是这么一回事。
间接比照找不同，PSK 的密钥替换形式把上面三个步骤干掉了：简略来说就是 CR、CV
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}0-RTT
0RTT
PSK（pre_shared_key）呈现的另一个次要目标是实现 0 -RTT。
所谓的 0 -RTT，指的是在 TLS1.2 当中，为了协商密钥和加密算法，须要消耗 2 个 RTT 的工夫进行密钥的替换和确认（握手工夫耗费），所以 TLS1.2 效率比拟低。
为了优这一步骤 TLS1.3 应用“Extension”字段，在简化加密套件的前提下，把加密套件所须要的信息通过第一次 ClientHello 就实现了传输，同时在 ServerHello 返回之后，就曾经实现后续的所有申请都是加密传输，进一步提高 SSL 握手效率。
所以TLS1.3 实现了四次握手转为三次握手，在首次交互的时候因为单方没有 Key Share，所以仍然须要 1 -RTT 的数据交换操作，然而一旦单方都持有 PSK，就能够复用连贯，并且缩短至 0 -RTT。
留神：0-RTT 的代价是防不住重放攻打，这一点在“扩大常识”介绍协定的一些细节。
在 RFC 的规范中，客户端通过第一次返回的 PSK 传输来实现 0 -RTT 验证，如果验证失败则立即进行握手，通过上面的交互步骤能够发现从握手开始的那一刻就曾经是加密传输了，所以整个 HTTPS 的校验很快。
然而 0 -RTT 有个致命问题，那就是无奈齐全防住重放攻打，当然解决 0 -RTT 的副作用方法也有很多种，比方只容许幂等平安的 GET / HEAD 办法，在音讯里退出相似 token 校验的工夫戳验证、“nonce”验证，或者“一次性票证”等齐全限度重放。
psk_key_exchange_modes
psk_key_exchange_modes 是为了配合 PSK 而呈现的，也叫做 预共享密钥替换模式，为了应用 PSK，客户端还必须发送“psk_key_exchange_modes”扩展名。这个扩大的语义是客户端仅反对在这些模式下应用 PSK。
如何避免 psk_key_exchange_modes 被滥用？RFC 规定如果客户端抉择 psk_key_exchange_modes，然而并没有在扩大字段中传递 pre_shared_key（或者模式指定为 psk_ke），则服务器应该立即进行握手步骤，确保服务器不会应用客户端并没有指定的密钥替换而呈现信息透露的危险。
psk_key_exchange_modes 有两个可选项：
psk_ke：示意仅 PSK 密钥创立，服务器此时不容许提供 ”psk_share”。psk_dhe_ke：通过 EC)DHE 密钥创立的 PSK。在这种模式下，客户端和服务器必须提供“key_share”值。
更多 psk_key_exchange_modes 能够浏览 RFC 文档理解。
AEAD（Authenticated_Encrypted_with_associated_data）加密形式
TLS 1.3 仅反对 AEAD 来校验数据完整性，AEAD 蕴含对称加密和 MAC 计算两局部，依据二者的先后顺序能够将 AEAD 分为 对称加密 和加密算法。AEAD 本质将完整性校验和数据加密两种性能集成在同一算法中实现。
AEAD 性能提供对立的加密和认证操作，将明文转换为通过身份验证的密文而后再返回。每个加密记录由一个明文头和一个加密的注释组成，它自身蕴含一个类型和可选的填充。
之所以呈现 AEAD 作为完整性校验和加密性能的“合体”，是因为在 TLS1.2 中的 CBC 分块传输加密以及 MAC 校验完整性的形式是存在破绽的，所以这个加密算法是一个“合体版”。
这里必定会有疑难，CBC 是啥？为啥说它是存在破绽的，这一块波及密码学和加密学根底，集体在“扩大常识”中的“平安密钥参考文章”中找到另一篇不错的文章，对于密码学感兴趣能够补充这部分内容。
具体请看“明码平安参考文章”局部。
TLS 1.3 反对的 AEAD 算法有三种：AES-CCM、AES-GCM、ChaCha20-Poly1305。
| AEAD 算法 | AEAD 办法 | 优缺点比照 | 应用场景举例 |
|---|---|---|---|
| AES-CCM(AES-CTR + CBC-MAC) | Encrypt-and-MAC | 受限于 CBC 模式个性，不能充分发挥并行处理的劣势 | TLS 1.2/1.3、IPsec、WLAN WPA2、BT LE 等 |
| AES-GCM<br/>(AES-CTR + Galois-MAC) | Encrypt-then-MAC | 能够充分利用并行处理提高效率 | TLS 1.2/1.3、IPsec、WLAN WPA3、SSH 等 |
HKDF（HMAC_based_key_derivation_function）
HKDF 是对于 PRF 算法的进一步降级，用于取代 PRF 函数计算主密钥“Master Secret”获取更高的安全性以及随机性。HKDF 在 PRF 根底上通过应用协商进去的密钥资料，和握手阶段报文的哈希值作为输出，能够输入安全性更强的新密钥。
HKDF 包含 extract_then_expand 的两阶段过程，extract过程减少密钥资料的随机性能，expand则是加固密钥资料的安全性。
须要留神 PRF 实际上只实现了 HKDF 的 expand 局部，所以不算是残缺的 HKDF 算法，会呈现这种只实现了一半就认为随机性残缺的状况，集体认为可能是因为过后设计者的思考欠缺或者工夫紧促所致。
最初能够看一份 wiki 上应用 Python 实现的 HKDF 代码案例：
#!/usr/bin/env python3
import hashlib
import hmac
from math import ceil
hash_len = 32
def hmac_sha256(key, data):
return hmac.new(key, data, hashlib.sha256).digest()
def hkdf(length: int, ikm, salt: bytes = b"", info: bytes = b"") -> bytes:
"""Key derivation function"""
if len(salt) == 0:
salt = bytes([0] * hash_len)
prk = hmac_sha256(salt, ikm)
t = b""okm = b""
for i in range(ceil(length / hash_len)):
t = hmac_sha256(prk, t + info + bytes([i + 1]))
okm += t
return okm[:length]
okm = hkdf(length=42,
ikm=bytes.fromhex('0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b'),
salt=bytes.fromhex('000102030405060708090a0b0c'),
info=bytes.fromhex('f0f1f2f3f4f5f6f7f8f9'))
assert okm == bytes.fromhex('3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865')DHE 密钥协商机制
TLS 1.3 对于 ECHED 算法自身做了一些改进，比方在椭圆曲线函数抉择上，TLS1.3 做的比 TLS1.2 更加欠缺，在 TLS1.2 中的流程是单方先由客户端抉择反对算法算法，而后服务端通过抉择确定应用 ECHED 算法，而后由 服务端 最终抉择的函数曲线，所以步骤较为固定，单方各须要依据协定好的函数曲线抉择适合的参数。
而 TLS1.3 则是由 单方独特决定，因为在客户端，具体内容能够看上面的 TLS1.3 抓包（这里截取局部内容介绍），对于椭圆域 DH 是椭圆曲线和基点的值，同选定加密组件一样，TLS 1.3 定义了几组 gp 值，利用 Group 进行标识，因为 Hello 阶段还是明文，所以上面应用了 x25519 是一个参数代称，具备平安告诉的同时能够达到协商的目标。
Extension: key_share (len=38)
Key Share extension
Key Share Entry: Group: x25519, Key Exchange length: 32
Key Exchange: b6fd2a1b723b0b11c648b3bee3f5412323423f28fa3ab797e57a4cde3ab1fe28整个协商的过程和 PSK 的协商有点相似，都是学生成一个列表，而后每个 Group 生成密钥的替换参数，内容同样和 PSK 放到了扩大字段 key_share 当中，服务端决定好 DH 密钥之后，再通过 Group 封装返回。
在规范设计上客户端应该把本人反对的所有
其余改良
New Session Ticket（NST）报文
NST 的内容属于 Post-Handshake Messages 目录的一部分。
New Session Ticket（NST）这部分内容集体倡议学习的时候比照 TLS1.2 的 Session Id，Session Ticket 以及 TLS1.3 的 PSK 理解整个会话重用的过程，而这里因为篇幅所限仅仅概括一下 NST 次要的性能和作用：
- NST 次要用于参加 PSK 密钥的计算，单方通常会在进行 application_key（主密钥）密钥协商计算实现之后，计算出 resumption_key（复原会话主键），而后应用 resumption_key 与 PSK 初始值做 HKDF 计算才会失去真正的 PSK 值，用于下一次 TLS 连贯的建设。
- NST 报文在连贯建设后（即客户端发送完 Finished 报文后），由服务端发送给客户端，蕴含 PSK 初始值和 PSK 名字、有效期、用处限定等信息。
- NewSessionTicket 应用
server_application_traffic_secret加密，通过 resumption_key 和 HKDF 算法计算出 PSK 的公式如下：
HKDF-Expand-Label(resumption_master_secret,
"resumption", ticket_nonce, Hash.length)对于这个构造具体的内容，能够参考：4.6.1 New Session Ticket Message.
原文形容：
At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message. This message creates a unique association between the ticket value and a secret PSK derived from the resumption master secret (see Section 7).在服务器收到客户端的 Finished 音讯后的任何时候，它都能够发送 NewSessionTicket 音讯。此音讯在票证值和从复原主密钥派生的机密 PSK 之间创立惟一关联（参见第 7 节）。
Record 子协定
Record 子协定能够从这部分开始看起：5. Record Protocol
Record 有点儿相似 TCP 报文格式的定义，在 TLS1.2 提到过 HTTPS 是处于 TCP 和 HTTP 两头的“夹层协定”，因为 TCP 是 HTTP 的上层协定，所以 HTTPS 的报文和数据内容格局，和 TCP 的报文根本相似，然而要比 TCP 的报文要简略不少。
Record 协定的规范局部一上来就给这个协定做了一个定义：
The TLS record protocol takes messages to be transmitted, fragments
the data into manageable blocks, protects the records, and transmits
the result. Received data is verified, decrypted, reassembled, and
then delivered to higher-level clients.
TLS 记录协定将要传输的音讯分片，将（加密）数据分成可治理的块，爱护记录并传输后果。收到数据通过验证、解密、重组，而后传递给更高级别的客户端。Record 协定也是应用了分片的思维，同时分片的内容是须要加解密的报文。Recod 对于报文一些上面的限度：
- 每个 record 都有长度限度。
- 不同的密钥音讯内容不能存在于一个 Record 当中，一些变更信息都要通过独自的 Key 发送。
- 对于 Alert 的音讯解决比拟非凡，不能进行分片。
- application data：对 TLS 协定不可见，所以没有对应的解决规定。
- handshake message：握手信息，传输数据两头不能夹杂其余信息。
加密解密应用 AEAD，应用 AEAD 加密机制和协商进去的加密算法对消息报文进行加密。
AEADEncrypted = AEAD-Encrypt(write_key（即加密密钥）, nonce, plaintext)，
上面是无关 AEAD 加密的流程图：
TLS 1.3 中 AEAD 算法将单个密钥，随机数，明文作为输出附加参数，整体流程和 TLS1.2 有点相似，在细节上优化和解决等。
TLS 1.2 实际上也有 AEAD 加密，TLS 1.3 的加密在细节上做了调整，比方 Nonce 的生成形式变了，序列号在 TLS1.2 是additional_data，到了 TLS1.3 算到了 Nonce 当中，并且能够发现 TLS1.3 参加计算的 additional_data 的两个头部字段是固定字节 (opaque_type = 23、legacy_record_version = 0x0303)。
加密和解密的过程是刚好反过来的后 TLS 1.3 通过 TLS 对消息报文填充来阻止攻击者获知传送音讯的长度等信息，所以在单方解密报文的时候还须要多做一步，那就是把开端的 0 给去掉能力正确解密。
Alert 协定扩大
规范局部能够从这里开始看：6. Alert，TLS 1.3 更多是对于 Alert 协定扩大，这里简略比照一下 TLS1.2 的 Alert 内容，TLS 1.3 Alert 枚举定义如下：
enum {close_notify(0),
unexpected_message(10),
bad_record_mac(20),
record_overflow(22),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
missing_extension(109),
unsupported_extension(110),
unrecognized_name(112),
bad_certificate_status_response(113),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;TLS 1.2 Alert 枚举定义：
enum {close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
(255)
} AlertDescription;能够看到 TLS1.3 的 Alert 仍然是对于 TLS1.2 的扩大，这里举两个新增的例子：
- unrecognized_name(112)：当没有辨认出服务器时，由服务器通过“server_name”扩展名发送给客户端提供的名称（参考 [RFC6066]）。
- unknown_psk_identity：当须要建设 PSK 会话重用连贯但客户端没有提供受到认可的的 PSK 身份时由服务器发送（留神可选发送），服务器可能会改为发送“decrypt_error”警报以仅批示有效的 PSK 身份。
TLS 1.3 抓包
抓包将会参考 TLS1.3 的交互流程进行介绍：
Client Server
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*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]这里偷懒找了一个曾经反对 TLS1.3 的集体博客间接拿来用了，访问速度的确挺快的。首先咱们须要在浏览器按下 F12，通过查看 Security 的局部，以此查看指标网站是否反对 TLS1.3。
测试网站：https://halfrost.com/tls1-3_start/。除了这个网站之外，也能够间接用最为熟知的寰球最大同性交友网站 github，也是反对 TLS1.3 的。
上面是否是否反对 TLS1.3 的网页截图：
2.1 Client_hello
首先咱们看 WireShanker 抓包，集体应用了 WIFI，所以抓的是 WIFI 对应的端口。在 TLS1.3 中通过 ClientHello 和 Servssser Hello 的扩大字段进行密钥替换，简化了 KeyExchange，实际上就是“新瓶装旧酒”换了个地位。
TLS 1.3 的 Client Hello 大抵是这样形容的：
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->抓包报文：
Handshake Protocol: Client Hello
Version: TLS 1.2 (0x0303)
Random: bab59bd2b9007afce54bdb6e3802c8b30d78b833e4aa21d7242858a08fae5da5
Session ID: 23d30d7ff75c05fdc4d7f49c0a4e84fc88dd123e167c91f9e5e3d29bc85cc46e
Cipher Suites (19 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Extension: signature_algorithms (len=26)
Signature Hash Algorithms (12 algorithms)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: ed25519 (0x0807)
Extension: supported_versions (len=5)
Supported Version: TLS 1.3 (0x0304)
Supported Version: TLS 1.2 (0x0303)
Extension: supported_groups (len=10)
Supported Groups (4 groups)
Supported Group: x25519 (0x001d)
Supported Group: secp256r1 (0x0017)
Supported Group: secp384r1 (0x0018)
Supported Group: secp521r1 (0x0019)
Extension: key_share (len=38)
Key Share extension
Key Share Entry: Group: x25519, Key Exchange length: 32
Key Exchange: b6fd2a1b723b0b11c648b3bee3f5412323423f28fa3ab797e57a4cde3ab1fe28
首先握手协定的后面几行介绍了整个报文的长度，以及 Version: TLS 1.2 (0x0303) 版本协定，因为 TLS1.3 须要伪装成 TLS1.2 向后兼容，所以这个版本号须要固定为 0x0303，而扩大字段·supported_versions 则设计为专为 TLS1.2 降级 TLS1.3 应用，Supported Version 版本从大到小排列，最终确认应用 TLS1.3 协定。
没用的常识：留神这里在 TLS1.3 刚公布的时候，Chrome 或者 FireFox 浏览器可能因为浏览器的过旧的起因进化到 TLS1.2 握手，过后须要降级最新版本。
接着咱们简略介绍其余参数：
client_random 仍然是作为后续对称加密曲线重要参数。
Session ID：TLS1.3 中不再应用 Session ID 进行会话复原，这一个性曾经和预共享密钥 PSK 合并了，PSK 也是 TLS1.3 举荐的密钥替换形式之一。这里设置这个字段的意义次要也是为了兼容之前版本，同时 Client 发现如果服务端存在 TLS 1.3 版本之前的 Server 设置的缓存 Session ID，那么这个字段必须要填上对应 ID 值保持一致。
同时兼容模式下这个值必须是非空的，所以如果 Client 不能反对 TLS1.3，那么须要从新生成一个 32 字节的值。然而如果反对 TLS1.3，Session ID 必须 是一个长度为 0 的矢量。
总之 RFC 设置了一些细节规定 Session ID 兼容和应用问题，在 TLS1.3 中咱们的重心更应该放在 PSK 上，因为 Session ID 是十分传统的会话握手关键字段。
signature_algorithms 标识了客户端所抉择的算法，下面看似很多的加密套件，实际上在 TLS1.3 中能抉择加密只有一个巴掌的数量，传输一些其余的加密算法同样是为了兼容和有可能的从新协商握手思考。
Cipher Suites 指的是应用的非对称加密套件，客户端提供列表由服务端进行抉择。
supported_groups 示意的是 ECDHE 算法所须要的内容信息，比方用于计算出 椭圆函数曲线公钥。
psk_key_exchange_modes：因为本次抓包并不满足传递 PSK 的条件，所以这里看不到此参数。
pre_shared_key：本次抓包不满足 PSK 的条件，所以扩大字段 并没有传递 key_share。
能够看到 TLS1.3 的 ClientHello 相比于 TLS1.2 看上去多了很多货色，然而实际上整体流程就是把 TLS1.2 的 KeyExchange 局部全副退出到了扩大字段当中。
Client Hello 的抓包到此告一段落，上面看看 Sever Hello 多了哪些内容。
2.2 Server Hello
接下来是 Server Hello，Supported Version 阐明服务器辨认了客户端的 TLS1.3 申请，故应用 Supported Version TLS 1.3 阐明本身反对应用 TLS 1.3 进行握手。
这里留神开端的 Change Cipher Spec Message，服务器收到了客户端传输的数据之后，此时根本就曾经有了客户端的加密套件和所需信息：Client Random 和Server Random、Client Params和Server Params，加上 HKDF 算法就能够算出对称加密的密钥，所以有了会话密钥之后，后续的传输都是对成加密的密文，进一步提高安全性。
HKDF 是对于 PRF 的改良，这里简略回顾 TLS1.2 的 PRF 算法，联合 TLS1.3 得出上面的步骤：通过 key_share 传递的椭圆曲线函数密钥 +Client Params和 Server Params，得出 pre_master_secret（这两个椭圆曲线公钥 + 简单算法 = 随机数 ，叫做 PreMaster=pre_master_secret），而后联合Client Random 和Server Random+pre_master_secret 三个参数计算出对称加密密钥 master_secret。HKDF 所做的改良则是这个主密钥的计算过程，退出更多的变动，让这个主密钥更加具备随机性和难以猜想。
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];所以在 TLS1.3 这里用 HKDF 对整个会话主密钥的计算做了改进，在 RFC 中没有找到对应的公式，所以咱们把下面的 PRF 脑补替换成了 HKDF 即可。
最初来看看 Server Hello 的报文：
Version: TLS 1.2 (0x0303)
Handshake Protocol: Server Hello
Version: TLS 1.2 (0x0303)
Random: 79982ab6bfaca82f4d8bce215262e597ed7c326e1e5dd5974f943ee566d2a03e
Session ID: 1ebba1d46f1fc351617977ca86ba9441946ac19dcf4849848b589c64e24b1ffa
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Extension: key_share (len=36)
Key Share extension
Key Exchange: d545f21e4c2e759a2b45735e554c789a5869c7921fbf780dc69f5ecd3df9a60f
Extension: supported_versions (len=2)
Supported Version: TLS 1.3 (0x0304)
TLSv1.3 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
Version: TLS 1.2 (0x0303)
Change Cipher Spec Message2.3 Change Cipher Spec
计算出对称加密须要的主密钥之后，服务端会立马返回Change Cipher Spec”音讯告知前面的内容都是密文传输，比 TLS1.2 提前进入加密通信，这意味着前面的证书等信息都是加密的了，缩小了握手时的明文信息泄露。
这部分内容因为都是加密传输，内容非常简短，这里简略截个图：
因为后续的内容都是加密传输，抓包看到的也都是密文并且没法剖析，所以咱们依据 RFC 规范流程进行简略介绍。
2.4 HelloRetryRequest
如果服务端无奈辨认客户端的加密参数信息，那么此时服务端会送一个 HelloRetryRequest 的信息，要求客户端从新发送符合要求的 CH 报文。
HelloRetryRequest 具备与 ServerHello 音讯雷同的格局，和 legacy_version，legacy_session_id_echo、cipher_suite 和 legacy_compression_method 等字段具备雷同的含意。
收到 HelloRetryRequest 后，客户端必须查看 legacy_version（TLS Version）、legacy_session_id_echo、cipher_suite 和 legacy_compression_method，而后解决扩大字段“supported_versions”确定版本开始。
RFC 中规定，如果 HelloRetryRequest 不会导致 ClientHello 产生任何变动，则客户端必须应用“illegal_parameter”警报停止握手。如果客户端在同一连贯中接管到第二个 HelloRetryRequest（即，ClientHello 自身就是响应 HelloRetryRequest 的中央），它必须应用“unexpected_message”警报停止握手。
HelloRetryRequest 能够看作是服务端不意识客户端加密算法的状况下进行再一次的密钥协商和 TLS1.3 握手尝试。
2.5 Encypted Extension
服务器在应用加密传输之后，接着会传输 Encypted，外面蕴含其余与密钥协商无关的扩大数据给客户端。
2.6 CertificateRequest（CR）
如果应用公钥证书进行身份认证，服务端此时须要发送 Certificate 报文（传递本人的证书信息）和下面提到的Certificate Verify（CV）报文，在报文外面应用本人的证书私钥对之前的报文进行 HMAC 签名证实本人持有该证书，之后传输给给客户端。
在 [[HTTP 面试题 – HTTPS 优化]] 中能够理解到，CR 的过程是能够被提前到握手之前的，上面这个流程如果通过了 HTTPS 优化是能够做到客户端发送申请进行 HTTPS 握手之前实现 CA 验证，进步整个握手效率。
这里持续联合之前 TLS1.2 所学，介绍 CR 的过程流程图：
2.7 CertificateVerify（CV）
CertificateVerify 将会联合之前所有的数据加上 HMAC 摘要算法做一个证实，而后在报文外面应用本人的证书私钥加密，而后传给 CA 进行加密解决，再一次证实本人可信水平。
2.8 Finished
服务端发送 Finished 报文。表明服务端到客户端信道的握手阶段完结，实践上不得再由该信道发送任何握手报文。达到这一步，之后的内容是开始传输 Application Data，也就是应用程序数据，这些曾经超出 TLS 协定的领域了，不多剖析：
2.9 Certificate
这里的 Certificate 指的是客户端收到服务端索要证书的申请开始发送证书，留神不要和后面的步骤混同。
2.10 Finished
客户端发送 Finished 报文，表明握手阶段完结，单方能够进行正式通信了。
Finished 报文应用会话密钥以及之前上述所有握手信息进行 HMAC 签名，校验签名能够测验握手阶段的完整性，也能够验证单方是否协商出了统一的密钥，同时进一步验证服务端的安全性。
留神以上所有握手阶段的报文都是由 record 协定层 加解密、分片、填充、转发的。
在这个过程中，如果产生了任何谬误（如：服务端证书验证失败、完整性校验谬误），则会发送一个 alert 报文（警报），转交给 alert 协定层进行错误处理。
TLS 1.3 流程图
咱们剖析完抓包之后，笔者对于整个 TLS 1.3 交互流程图画一个流程图，TLS1.3 要比 TLS1.2 简略很多，少了一次握手的也是最为直观的感触：
扩大常识
更深刻的学习
首先因为 TLS 自身就是和密码学非亲非故的规范，所以如果要吃透 TLS 必然须要对于密码学进一步探索，如果要钻研密码学，能够参考这一篇文章：# TLS 协定剖析 与 古代加密通信协议设计
当然去钻研密码学非常消耗精力，如果精力有限，能够看看微信在基于 TLS1.3 晚期草案（文章 2017 年，然而 2018 年 TLS1.3 才正式定版）的而设计的 mmtls 介绍文章，尽管过来很多年，然而对于 RFC 规范的落地实际仍然具备肯定的参考价值：
基于 TLS1.3 的微信平安通信协议 mmtls 介绍.md
如果具备肯定的英文程度，并且想看看老外如何介绍 TLS1.3，其实集体比拟倡议找找老外的文章，集体比拟举荐 cloud flare 公布的 TLS1.3 介绍合集，算是比拟受到宽泛认可的材料，
老外做进去的货色必定是外国人更能领悟，毕竟学习和生存环境以及思考形式都有很大差别，外国人了解起来总是快那么一些。
cloud flare 公司对 TLS 1.3 的介绍博文合集（英文）
如果想看 TLS1.3 是如何一步步探讨进去的，除了看 RFC，还有人专门整顿了一个 Github，当然没除非真的很闲，否则不倡议看这一份材料：
TLS 1.3 草案合集，能够从这里检索到最新版的 TLS1.3 草案（英文）
最初是 16 年 NDSS 会议钻研 TLS，这部分内容很多曾经无法访问了，然而有些内容还能够看个大略。
16 年 NDSS 会议钻研 TLS 1.3 的论文合集（英文）
最初如果还想再硬核一些，想更深刻理解 TLS1.3 规范局部的细节内容，能够从霜神大佬的系列文章无关 TLS1.3 介绍，很多内容是对于 RFCTLS 1.3 的整顿，能够借助 TLS1.3 的文档了解：
https://halfrost.com/https_tls1-3_handshake/
JDK 11 和 TLS1.3
原文：https://blog.gypsyengineer.com/en/security/an-example-of-tls-13-client-and-server-on-java.html
作者从事 JAVA 平安库的工作长达 6 年，提供的信息比拟精确。因为 TLS1.3 是 2018 年呈现的，所以作为 JDK8 的钉子户，如果要应用 JAVA 对接 TLS1.3 必须要 JDK 11。
然而须要留神 JDK11 版本的 TLS1.3 协定反对并不是非常欠缺，在 JEP332 中提供了上面的反对：
- Protocol version negotiation（协定版本协商）
- Full handshake for both client and server sides（客户端和服务器端的齐全握手）
- Session resumption（会话重用）
- Key and IV update（密钥和 IV 更新）
- Updated OCSP stapling（OCSP 从新订正）
- Backward compatibility mode（向后兼容模式）
- Required extensions and algorithms（所需的扩大和算法）
- Two new cipher suites: TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384（新的明码套件）
- RSASSA-PSS signature algorithms（签名算法）
- Both SSLSocket and SSLEngine（SSLSocket 和 SSLEngine）
不反对的内容（留神以 JDK11 版本为例）：
- 0-RTT data 0-RTT 数据
- Post-handshake authentication 握手后认证
- Signed certificate timestamps (SCT) 签名证书工夫戳 (SCT)
- ChaCha20/Poly1305 cipher suites (targeted to Java 12) ChaCha20/Poly1305 明码套件（针对 Java 12）
- x25519/x448 elliptic curve algorithms（针对 Java 12）
- edDSA signature algorithms（针对 Java 12）
Java 11 没有为 TLS 1.3 引入新的公共类和办法。它只是为新协定名称、明码套件等增加了几个新常量。应用常量的益处是只须要降级应用的算法和降级 JDK 等操作，代码逻辑不须要进行改良，这非常不便。
Java 13 中的 TLS 加强
作者还是下面那一位老哥（白嫖常识感觉真爽）：https://blog.gypsyengineer.com/en/security/tls-enhancements-in-java-13.html
Java 13 于 2019 年 9 月 13 日公布。尽管新的 Java 不蕴含平安库中的重大更新，但在 TLS 实现中有几个值得注意的更新。上面看看几个须要关注的降级点：
第一个降级点：默认加密套件的抉择程序：
这里不多废话，间接看变动：
扭转之前：
- ECDHE-ECDSA
- ECDHE-RSA
- RSA
- ECDH-ECDSA
- ECDH-RSA
- DHE-RSA
- DHE-DSS
扭转之后：
- ECDHE-ECDSA
- ECDHE-RSA
- DHE-RSA
- DHE-DSS
- ECDH-ECDSA
- ECDH-RSA
- RSA
简略来说就是具备前向安全性以及加密平安水平更高的算法往前调整，TLS1.3 曾经把 RSA 废除，这里集体并不太了解为什么 JAVA 不把 RSA 间接干掉。
第二个降级点：椭圆函数曲线降级
X25519 和 X448 是到目前为止公认最为平安的两个椭圆函数曲线，JDK13 Java 13 反对 TLS 版本 1.0、1.1、1.2 和 1.3 的 x25519 和 x448 椭圆曲线，x25519 优先级最高，而 x448 则遵循可选曲线分支，最终的程序是：x25519, secp256r1, secp384r1, secp521r1, x448, ... 这些细节被放到 `jdk.tls.namedGroups 当中。
第三个降级点：无状态服务
所谓的无状态服务，实际上指的是 0 -RTT，实现的形式是 JDK 官网为了给 TLS 连贯减速，举荐应用 PSK 预替换密钥而应用
上面是 JAVA 代码的案例，只是它应用了新的常量“TLSv1.3”和“TLS_AES_128_GCM_SHA256”：
package com.gypsyengineer.tlsbunny.jsse;
import javax.net.ssl.SSLServerSocket;
import javax.net.ssl.SSLServerSocketFactory;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import java.io.*;
/*
* Don't forget to set the following system properties when you run the class:
*
* javax.net.ssl.keyStore
* javax.net.ssl.keyStorePassword
* javax.net.ssl.trustStore
* javax.net.ssl.trustStorePassword
*
* More details can be found in JSSE docs.
*
* For example:
*
* java -cp classes \
* -Djavax.net.ssl.keyStore=keystore \
* -Djavax.net.ssl.keyStorePassword=passphrase \
* -Djavax.net.ssl.trustStore=keystore \
* -Djavax.net.ssl.trustStorePassword=passphrase \
* com.gypsyengineer.tlsbunny.jsse.TLSv13Test
*
* For testing purposes, you can download the keystore file from
*
* https://github.com/openjdk/jdk/tree/master/test/jdk/javax/net/ssl/etc
*/
public class TLSv13Test {
private static final int delay = 1000; // in millis
private static final String[] protocols = new String[] {"TLSv1.3"};
private static final String[] cipher_suites = new String[] {"TLS_AES_128_GCM_SHA256"};
private static final String message =
"Like most of life's problems, this one can be solved with bending!";
public static void main(String[] args) throws Exception {try (EchoServer server = EchoServer.create()) {new Thread(server).start();
Thread.sleep(delay);
try (SSLSocket socket = createSocket("localhost", server.port())) {InputStream is = new BufferedInputStream(socket.getInputStream());
OutputStream os = new BufferedOutputStream(socket.getOutputStream());
os.write(message.getBytes());
os.flush();
byte[] data = new byte[2048];
int len = is.read(data);
if (len <= 0) {throw new IOException("no data received");
}
System.out.printf("client received %d bytes: %s%n",
len, new String(data, 0, len));
}
}
}
public static SSLSocket createSocket(String host, int port) throws IOException {SSLSocket socket = (SSLSocket) SSLSocketFactory.getDefault()
.createSocket(host, port);
socket.setEnabledProtocols(protocols);
socket.setEnabledCipherSuites(cipher_suites);
return socket;
}
public static class EchoServer implements Runnable, AutoCloseable {
private static final int FREE_PORT = 0;
private final SSLServerSocket sslServerSocket;
private EchoServer(SSLServerSocket sslServerSocket) {this.sslServerSocket = sslServerSocket;}
public int port() {return sslServerSocket.getLocalPort();
}
@Override
public void close() throws IOException {if (sslServerSocket != null && !sslServerSocket.isClosed()) {sslServerSocket.close();
}
}
@Override
public void run() {System.out.printf("server started on port %d%n", port());
try (SSLSocket socket = (SSLSocket) sslServerSocket.accept()) {System.out.println("accepted");
InputStream is = new BufferedInputStream(socket.getInputStream());
OutputStream os = new BufferedOutputStream(socket.getOutputStream());
byte[] data = new byte[2048];
int len = is.read(data);
if (len <= 0) {throw new IOException("no data received");
}
System.out.printf("server received %d bytes: %s%n",
len, new String(data, 0, len));
os.write(data, 0, len);
os.flush();} catch (Exception e) {System.out.printf("exception: %s%n", e.getMessage());
}
System.out.println("server stopped");
}
public static EchoServer create() throws IOException {return create(FREE_PORT);
}
public static EchoServer create(int port) throws IOException {SSLServerSocket socket = (SSLServerSocket)
SSLServerSocketFactory.getDefault().createServerSocket(port);
socket.setEnabledProtocols(protocols);
socket.setEnabledCipherSuites(cipher_suites);
return new EchoServer(socket);
}
}
}HTTPS VS HTTP 性能
HTTP vs HTTPS — Test them both yourself
这两个页面再集体的比照后果有点大跌眼镜，上面的两个页面都是在 Edge 浏览器下侧好似实现的，会发现 HTTPS 竟然要比 HTTP 快？这是为什么？集体的猜想是这个网站的 HTTP 是未通过优化的，而 HTTPS 是通过优化的，所以整个加载过程反而比 HTTP 快很多。
而起因可能是多方面的，比方 0 -RTT，HTTP/2 等，这个测试后果是通知咱们不要以相对的眼光对待某件事情。
[[HTTP 面试题 – HTTPS 优化]]
Replay Attacks on 0-RTT
原文：https://www.rfc-editor.org/rfc/rfc8446#appendix-E.5
这里仅集体了解简略阐明一下，0-RTT 最大的威逼在于弱安全性，而最大的威逼是重放攻打，什么是重放攻打？这里官网给出了一些潜在攻打伎俩。
官网将 0 -RTT 的攻打分为两个大类，第一个大类是简略复制非幂等性申请进行重放攻打（比方付款，转账等只能做一次的操作），第二个大类则是大量利用重放测试幂等性接口，比方资源耗尽或者定向攻打，或者利用 0 -RTT 缓存测试资源在不同的服务器是否有不同体现。
第一类攻打能够通过共享状态来避免 0-RTT 数据最多被承受一次，然而并不说所有的运营商部署都会照做，也取决于服务器的实现。假如攻击者利用了晚期 ClientHello 并且重放到 A 和 B 服务器，A 是能够解决的，然而申请会被 B 服务器回绝，假如攻击者挡掉 A 返回的 ServerHello，那么此时音讯持续重放，流量将会被迫交给 B 并且由 B 实现，那么整个服务器的申请都会被反复执行。
第一类攻打的解决要害是永远保障 0 -RTT 只会被承受一次。也就是说 0 -RTT 数据不能在一个连贯中复制和重复使用（即服务器不会为同一连贯解决两次雷同的数据）。
第二类攻打比拟针对业务下手，所以 TLS 是帮不上忙的，须要服务端应用程序通过利用代码解决，比方利用 0 -RTT 重放获取账户明码等敏感信息，这些接口通常都是幂等性的。幂等性在 TLS1.3 上无奈保障平安，放任重放攻打是很容易受到信息泄露。比方比拟常见的做法是缓存解决校验或者间接从服务端做 Nginx 过滤等。
已知 TLS1.2 攻打伎俩
TLS 攻打伎俩
所谓道高一尺，魔高一丈，咱们补充一些无关 TLS1.2 以前（蕴含 TLS1.2）的攻打伎俩，借此从侧面理解为什么 TLS1.3 一下子废除了一大票算法，这些问题都和历史破绽有着很深的渊源。
BEAST、BREACH、CRIME、FREAK、LUCKY13、POODLE、ROBOT。
BEAST：BEAST (CVE-2011-3389) 是一种明文攻打，通过从 SSL/TLS 加密的会话中获取受害者的 COOKIE 值（通过进行一次会话劫持攻打），进而篡改一个加密算法的 CBC（明码块链）的模式以实现攻打目录，其次要针对 TLS1.0 和更早版本的协定中的对称加密算法 CBC 模式。
CRIME：CRIME 通过在受害者的浏览器中运行 JavaScript 代码并同时监听 HTTPS 传输数据，可能解密会话 Cookie，次要针对TLS 压缩。Server 端能够通过敞开 SSL/TLS 压缩和 HTTP 压缩来防止 CRIME/BREACH 攻打，这也是 TLS 1.3 废除压缩算法的起因，然而这个压缩无关紧要，因为 HTTP/ 2 和 HTTP/ 3 的首部压缩做的更为优良和通用。
BREACH：BREACH 攻打是 CRIME 攻打的升级版，攻打办法和 CRIME 雷同，不同的是 BREACH 利用的不是 SSL/TLS 压缩，而是 HTTP 压缩。所以要抵挡 BREACH 攻打必须 禁用 HTTP 压缩。
FREAK：衍生自美国的进口级密钥，512 位的 RSA 密钥，这种加密形式能够便于情报机构和非凡机构破解利用（斯诺登事件爆出之前干的事件，见怪不怪了），这个破绽编号为 CVE-2015-0204，人们将它命名为FREAK（Factoring Attack on RSA-EXPORT Keys），z
FREAK 攻打通过检测有至多 30% 的网站存在进口级 RSA 加密破绽，在上世纪 90 年代，破解 512 位的密钥须要出动超级电脑。而明天，咱们只须要破费 7 小时 + 约 100 美金，就能够轻松搞定这种加密机制。
这里衍生出 RSA 的中间人攻打伎俩，作为一个扩大：
FREAK 破绽与 POODLE（贵宾犬）破绽的相似性
FREAK 破绽：利用了进口级 RSA 加密的算法版本。
POODLE（贵宾犬）：也是通过降级套件的形式回退版本攻打，强制终端用低版本 SSL/T LS。
次要的区别是一个是针对进口级 RSA 算法，另一个利用 SSL 协定自身的低版本不安全性破绽做手脚，比方 TLS1.0 和 TLS1.1。内容起源：“历史遗留”破绽：浅析新型 SSL/TLS 破绽 FREAK – 腾讯云开发者社区 - 腾讯云 (tencent.com)
POODLE 破绽：古老但广泛应用的 SSL 3.0 加密协议中存在被称为 POODLE（Padding Oracle On Downgraded Legacy Encryption）的重大破绽，该破绽容许攻击者解密加密连贯的内容。
ROBOT：ROBOT 是个首字母缩写，是丹尼尔·布雷琴巴赫于 1998 年发现的，意思是 布雷琴巴赫 Oracle 威逼重现 (Return Of Bleichenbacher’s Oracle Threat)。这是一个在 1998 年就发现的破绽，该破绽容许应用服务端的私钥执行RSA 解密和签名操作。
更多内容能够浏览：# TLS ROBOT Attack 破绽
降级攻打
咱们察看下面的的这些破绽，会发现针对 SSL 协定的降级攻打是非常常见的，那么 TLS1.3 是如何防备降级攻打的？
咱们先看看降级攻打是下面意思，只有看上面这个图即可：
攻打过程如下：
- 客户端发送申请的时候，攻击者把客户端的加密算法替换成存在安全漏洞的低安全性算法，以此坑骗服务端降级返回弱平安密钥替换算法。
- 攻击者利用弱安全性密钥替换算法进行暴力破解，而后伪造 Finish Message，单方依照密钥进行失常交互，这样后续所有的对称加密都是“通明传输”。
- 最终黑客通过这些数据获取到用户隐衷数据。
针对这个攻打过程，咱们接着剖析 TLS1.3 就会发现尽管 Server Hello 之后的音讯是密文传输的，然而在 Client Hello 和 Server Hello 中传输的还是明文，所以所有的加密算法是公开的，同样 TLS1.3 的 ServerHello.random 也是明文，能够通过 wireshark 抓包看到，所以 T LS1.3 降级攻打是存在隐患的？
咱们接着看一下 TLS1.3 如何定义降级爱护：
The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack下面这段话的意思是说，单方平安通信的前提是 明码对等 、 参数对等，留神这两个条件是“短路”的，其中任意一个条件不满足，则应该立即进行握手，交给 Alert 解决。
首先是 明码对等，所谓的密钥对等实现形式是在 Verify 外面把后面所有的参数合起来加一个 HMAC 进行签名校对，在 RFC 的文档中有上面的这样一段代码：
finished_key =
HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
Structure of this message:
struct {opaque verify_data[Hash.length];
} Finished;
The verify_data value is computed as follows:
verify_data =
HMAC(finished_key,
Transcript-Hash(Handshake Context,
Certificate*, CertificateVerify*))下面的代码要求客户端和服务器都发送一个蕴含所有先前握手音讯的 MAC 的 Finished 音讯。其实就是 TLS1.3 握手过程的 CertificateVerify 这一步，verify_data 代表了这个计算过程的伪代码。
在以前版本的 TLS 中，verify_data 始终为 12 个八位字节长。在 TLS 1.3 中，它是 Hash 的 HMAC 输入的大小，而后用于握手。
有了明码对等是不够的，因为这些内容攻击者都能够在传输过程中伪造 Finish 轻易替换，上面咱们来看 参数对等 是如何进一步解决的。
这时候咱们能够翻到 https://www.rfc-editor.org/rfc/rfc8446#section-4.1.3 这一部分，大抵浏览看到 RFC 的内容，会发现 TLS 的想出了一招在 Server Random 外面做手脚。
咱们找到下面的外围局部，Server Random 一旦被更改，那么服务器最初的 8 位字节会依照上面的规定替换：
- 如果协商 TLS 1.2，那么最初 8 个字节必须是
44 4F 57 4E 47 52 44 01。 - 如果协商 TLS 1.1 或更旧的协定版本，那么最初 8 个字节必须是
44 4F 57 4E 47 52 44 00。
也就是说如果 Server Random 不等于下面提到的任何一个值，则服务端必须要终止连贯。同时这些个字符实际上也有自身的意义，这几个字节编码翻译过去的后面七个字节示意 DOWNGRD，这串单词的的含意是： 降级。
咱们能够这样了解：
- 我是服务器，我反对 TLS1.3，我从一个客户端失去一个连贯，它说它只反对 TLS 1.2 或更低版本，然而实际上我反对更高级的版本，我会把这些信息改写到 Server Random 的最初一段，你如果看到了确认一下哈。
- 我是客户端，我收到了服务端的回信，然而我明明是 TLS1.3 握手，怎么服务端让我用 TLS1.2 呢？不对劲，喔，服务端让我查看
ServerHello.random是否蕴含“DOWNGRD”（降级）音讯，我看了一下果然有，那么此时必定是第三者在两头捣蛋，我和服务端须要立即终止连贯。
等等，还是有问题，你会问 Server.random 不是明文传输么，黑客删了怎么办？其实这种解决形式就是改了删了就让它改了无所谓，成心裸露弱点给黑客，如果被篡改我就立马再返回信息外面阐明服务被降级了，客户端发现服务都被降级了，本人发的是 TLS1.3，后果被换成 TLS1.2 了立即进行握手。
而如果删了 Server.random，别忘了还有椭圆函数曲线的加密算法是必须要 Server Random 这个参数的，没了它对称加密密钥的计算进行不上来，也是有问题的。最终我发现发现 明码对等 、 参数对等 两个条件其中一个被毁坏了，单方没法失常交换，最终实现会话加密的平安。
不论是删了，改了，换了，都能查看出问题，最终降级爱护实现。
最初留一个小问题：天然状况下 TLS 握手碰到协定开端字节是 DOWNGRD + 00/01”的概率是多少？
前向平安：斯诺登事件
一些历史记忆，当初曾经被人们逐步淡忘了。
斯诺登 2013 的“棱镜事件”。具体能够看维基百科的介绍：https://zh.wikipedia.org/wiki/%E7%A8%9C%E9%8F%A1%E8%A8%88%E7%95%AB。
集体感触是互联网是老美创造的，利用互联网干坏事也是很失常的事件，而这些历史放到当初不过是云烟，因为大部分人的集体信息安全当初来看根本等于 0。
棱镜打算（英语：PRISM）是一项由美国国家安全局自 2007 年开始施行的绝密级网络监控监听打算。1 该打算的正式名称为“US-984XN”。
依据报导，泄露的文件中形容 PRISM 打算可能对即时通信和既存材料进行深度的监听。[5]许可的监听对象包含任何在美国以外地区应用参加打算公司服务的客户，或是任何与国外人士通信的美国公民。[5]国家安全局在 PRISM 打算中能够取得数据电子邮件、视频和语音交谈、视频、照片、VoIP 交谈内容、文件传输、登录告诉，以及社交网络细节，并透过各种联网设施，如智能手机、电子式手表等各式联网设施对特定指标进行攻打。[5]综合情报文件《总统每日简报》中在 2012 年中的 1,477 个打算里应用了来自棱镜打算的材料。
对于 PRISM 的报道，是在美国政府继续机密要求威讯向国家安全局提供所有客户每日电话记录的音讯曝光后不久呈现的。7 泄露这些绝密文件的是国家安全局合约外包商员工爱德华·斯诺登，于 2013 年 6 月 6 日在英国《卫报》和美国《华盛顿邮报》公开。
密钥平安参考文章
- padding oracle 原理深度解析 & CBC 字节翻转攻打原理解析，这篇文章介绍了 CBC 加密的细节和攻打模式。
- ChaCha20 and Poly1305 for IETF Protocols，这一篇报告中介绍了 ChaCha20 和 Poly1305 的搭配应用，是由 TLS1.3 协定制订过程中有人提出的配合计划，目标是解决 ChaCha20 没有数据完整性校验的计划实现细节，既能够组合应用，也能够独自应用。
TLS 1.3 报文定义
TLS 1.3 一共定义了 12 种报文，实际上大部分报文都是从 TLS1.2 继承下来的。
其余问题
依据这篇文章提出的一些补充疑难，以及提供相干解答。
- TLS1.3 里的明码套件没有指定密钥替换算法和签名算法，那么在握手的时候会不会有问题呢？
- 为什么 RSA 密钥替换不具备“前向平安”。
- PSK 真的平安吗？
第一个问题答复：TLS1.3 精简了加密算法，通过 support_groups、key_share、signature_algorithms 这些参数就能判断出密钥替换算法和签名算法，不必在 cipher suite 中协商了。
第二个问题答复：client key exchage 会应用 RSA 公钥加密 pre master 后传给服务端，一旦私钥被破解，那么之前的信息都会被破译，根本原因还是在于 RSA 的这一对公钥私钥并不是长期的，而是生成进去就永恒寄存的，所以以往的做法是服务端针对。
第三个问题来自于集体所参考的文章一个评论的发问，上面是原文：
感觉 psk 不平安，后面连 rsa 私钥安全性都信不过，这里居然信赖一个本地长期存储的密钥。
通过 rsa 传送明码我认为不是私钥安全性问题，而是有两个另外的起因：
1）rsa 密钥由双方生成，另一端无条件承受，这样的密钥接收端无奈信赖另一端的随机数能力、密钥治理能力。dh 是两端参加，各自放一个随机数进去（而且各端还要对另一端发过来的因子做肯定的查看），所以安全性更高
2）完满前向兼容性。dh 生成密钥当前，各自把长期随机数删除，密钥就只有内存利用，网络上也不怕破解。
PSK 第一眼看上去长得很像 Cookie，然而实际上和 Cookie 的安全性是云泥之别，咱们看看 PSK 是如何保障随机性和安全性的：
- 首先 Client 发一个 NewSessionTicket，这外面会蕴含刷新的 ticket，就是用来做 Psk 用的，也就是说每次实现握手之后都会超过过期工夫都会刷新掉票证，也就是所谓的“一次性票证”，一次性票证的官网倡议工夫是不超过 24 小时。
- 留神连贯握手两头有一个 verify 的过程，这是双向都须要进行的一次校验，这一步要把之前的所有参数合并，用 HMAC 做一个明码进行比对。
- 每次握手的 HandleShake 会被 Hash 计算动静生成 crypt key，同时 Psk 分还为 PSK_ES 与 PSK_SS，两个 Psk 的生命周期也不一样，前者只会要求生成明码，后者则是握手后用于下一次拜访携带的 PSK。
post-authentication 机制
post-authentication 机制 用于客户端确认是否向服务端提供信息，次要是用于客户端认证加强，在握手流程当中，CH 的报文会额定退出扩大字段post_handshake_anth，客户端会在收到 CR 之后再发送 CT、CV 报文给服务端进行身份认证。
然而这个机制存在许多未被解决问题，具体介绍之前咱们先说后果是 不倡议 应用或者 禁用，上面这篇文章探讨能够看到一些答案：
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-tls13
笔者这里挑了探讨中比拟重要的内容来阐明为什么不倡议应用：
TLS 1.2 with HTTP/1.1：应用 TLS 从新协商。这产生了十分多的遗留问题导致无奈从新协商。
TLS 1.3 with HTTP/1.1：应用 TLS 握手后身份验证（post-authentication 机制）。没有被宽泛施行，官网的文档 https://tools.ietf.org/html/draft-ietf-httpbis-http2-tls13ye 没有解释外部的抵触和歧义问题，所以基本问题还是 毁坏 HTTP/2，毁坏文档标准。
间接问题：任何带有 HTTP/2 的 TLS 版本上述机制都不起作用，因为 HTTP/2 是多路复用的。握手后客户端证书身份验证实质上是一种简直无奈见效的 hack，因为 HTTP/1.1 是一个足够简略的协定，能够抵挡分层违规。https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs 形容了一种填补这一空白的机制，但它依然是一个草案。
PS：客户端认证在理论利用上非常少，所以能够看到基于客户端认证的内容无论是 RFC 还是理论的文章探讨都不是特地具体，而在服务端认证上的细节则十分宏大。
总结
最初咱们在比照 TLS1.2 和 TLS 1.3，看看次要做了哪些更新：
- 简化握手流程，从 4 次握手削减为 3 次握手，利用了新呈现的 PSK 密钥替换算法，实现了 0 -RTT。
- TLS 1.3 只反对 (EC)DHE 的密钥协商算法，间接干掉了 RSA 密钥替换算法（缩小学习老本，笑），加密套件削减为 5 个，并且 所有基于公钥的密钥替换算法当初都能提供前向平安。此外从另一方面看因为都是用 (EC)DHE 的密钥协商算法，实际上也是间接废除了非对称密钥加密模式。取而代之的是基于数学推导的椭圆曲线密钥。
- 删除对称加密密钥的 MAC 以及 CBC 分组加密，起因能够看“已知 TLS1.2 攻打伎俩”。
写在最初
这一篇内容花了不少工夫，因为网上波及的大部分材料都是讲 TLS1.2 的，TLS1.3 真正深刻解读的材料并不多，并且因为英文比拟渣，在 RFC 文档的材料钻研比照了解下花了不少功夫。
倡议各位学技术的小伙伴们要好好磨难英语呀，不然在某个畛域的深度钻研上真的举步维艰。
这篇解读 并不业余，更多是依照集体的思路简略整顿了 TLS1.3 的一些重点，如果有任何疑难或者任何谬误欢送私信或者评论领导，一起共同进步。
更多密钥计算
TLS1.3 的 HRDF 对于不同的报文应用不同的密钥，在密钥替换算法上反对更多更灵便的变动。
TLS1.2 的密钥比拟枯燥，一种是进行完整性校验，另一个报文加密，所以这种两两组合的形式有不同的分支。
TLS 1.3 因为应用 AEAD 机制，不再须要应用 MAC_key 来进行完整性校验，
参考文章
- https://www.cxymm.net/article/qq_31442743/111666786
- https://halfrost.com/tls1-3_start/
- https://zhuanlan.zhihu.com/p/28850798
- # How does TLS 1.3 protect against downgrade attacks?
- https://halfrost.com/https_tls1-2_handshake/
