Quic 协议——第五部分
谷歌的 QUIC 协议中使用了自己的安全握手协议。而后 IETF 将 TLS 1.3 引入 QUIC 协议，并作为安全握手协议使用。
一、TLS 1.3 协议简介
TLS 是一个分层协议，包括下层的记录协议和上层的握手协议、告警协议和应用数据。
!! QUIC 不支持 TLS 的密码变更协议
TLS 1.3 提供了支持 1-RTT 的完整验证流程和 0-RTT 的快速回复机制。 TLS 报文有 0RTT 和 1RTT 两种安全级别。前者使用上次连接过程中建立的 psk。 后者使用 DH 秘钥交换等派生出 master key 后派生加密。
客户端 服务端
客户端请求
(0-RTT 应用数据) -------->
服务端请求
{加密扩展}
{完结的}
<-------- [应用程序数据]
{完结的} -------->
[应用程序数据] <-------> [应用程序数据]
() 受早期数据(0-RTT)键保护的指示消息
{} 使用握手密钥保护的指示消息
[] 使用应用程序数据保护的指示消息(1-RTT)键
二、 QUIC 协议中 TLS 概述
- QUIC 协议中不再使用 TLS 协议的记录协议，而是直接由 QUIC 协议提供消息传递。
- TLS 协议中的告警协议和握手协议直接作为 QUIC 的一个 STREAM 来完成。
- QUIC 协议不兼容 TLS 协议的密码变更协议
- QUIC 协议直接使用 TLS 协议所派生的秘钥对整个连接进行保护，而不再使用 TLS 的应用数据协议
+--------------+--------------+ +-------------+
| TLS | TLS | | QUIC |
| handshake | alert | | application |
+--------------+--------------+-+-------------+
| QUIC Transport |
+---------------------------------------------+
| QUIC Data Package Protect |
+---------------------------------------------+
三、TLS 交互流程（个人理解）
- QUIC 使用 CRYPTO 帧将 TLS 握手协议打包并发送，在传输过程中保证可靠达到。
- QUIC 将 TLS 告警协议中的错误值取出后封装在 CONNECTION_CLOSE 帧中。
- QUIC 将 HelloRetryRequest 用于纠错时，取出并改为发送 Retry_Package。
- QUIC 使用短头部中的 KEY_PHASE 来代替TLS中的KeyUpdate 消息来进行秘钥变更。
握手协议流程（作者理解）：
- 建立 QUIC 连接，QUIC 向 TLC 提供 QUIC 传输参数
- 触发 TLS 模块进行 TLS 握手协议流程，其中 TLS 报文由 CRYPTO 封装后经过 QUIC 发送。
- 握手完成后，TLS 模块转为被动模式，由派生的秘钥对整个 QUIC （包括包头）进行完整性保护。（除了版本协商和 retry_package）
四、额外特性
4.1 协议和版本协商保护
由于初始报文中，版本未经保护，因此可能遭受降级攻击。
QUIC 要求加密握手提供经过身份验证的协议协商。 TLS 使用应用层协议协商(ALPN)来选择应用协议。 除非使用另一种机制来商定应用协议，否则终端必须为此使用 ALPN。 使用 ALPN 时，如果未协商应用协议，则终端必须中止连接。
4.2 QUIC 传输参数扩展
这是一个 TLS 扩展，携带了 QUIC 传输参数的相关信息，用于对这些信息提供机密和完整性保护。
本人保留对侵权者及其全家发动因果律武器的权利
版权提醒
如无特殊申明，本站所有文章均是本人原创。转载请务必附上原文链接：https://www.elliot98.top/post/lab/quic-5/。
如有其它需要，请邮件联系！版权所有，违者必究！