这是我参与8月更文挑战的第7天，活动详情查看：8月更文挑战
| 8月份更文挑战主题：TLS1.3协议 |
|---|
| TLS1.3系列文章（7）：TLS1.3握手之交互流程与状态切换 |
三、TLS1.3握手流程
TLS的握手状态变迁图参考第四章。在RFC8446中提到TLS1.3的握手流程主要可以分成四种：
- 标准的tls握手流程
- 当协商参数失败时，从协商tls流程
- 复用连接且使用PSK时握手流程
- 0-RTT握手流程
下面分别给出四种场景下的握手流程(第一种已经介绍)。
3.1 标准握手流程
3.2 DHE协商失败时握手流程
如果client端没有提供足够的”key_share”扩展消息（例如，只包含server不接受或不支持的DHE或ECDHE组），server会使用HelloRetryRequest来纠正这个不匹配问题，client需要使用一个合适的”key_share”扩展来重启握手，如图下图所示。如果没有通用的密码参数能够协商，server必须使用一个适当的告警来中止握手。
这个握手过程包含初始的ClientHello/HelloRetryRequest交换，不能被新的ClientHello重置
3.3 PSK协商+Resumption流程
3.4 0-RTT流程
当client和server共享一个PSK（从外部获得或通过以前的握手获得）时，TLS 1.3允许client在第一个发送出去的消息（“early data”）中携带数据。Client使用这个PSK来认证server并加密early data。
注意：0-RTT数据的安全属性比其它类型的TLS数据弱，特别是：
- 这类数据没有前向安全，它只使用了从提供的PSK中导出的密钥进行加密。
- 不能保证在多条连接之间不会重放。为普通的TLS 1.3的1-RTT数据提供抗重放的保护方法是使用server的随机数据，但0-RTT不依赖于ServerHello，因此只能得到更弱的保护。如果数据使用TLS client认证或在应用协议认证，这一点尤其重要。这个警告适用于任何使用early_exporter_master_secret的情况。
0-RTT数据不能在一个连接内复制（如server不会处理同一连接内相同数据两次），攻击者不能使0-RTT数据看起来像1-RTT数据（因为它们是用不同秘钥保护的）。附录E.5包含了潜在攻击的描述，第8章描述了server可以用来限制重放影响的机制。
