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 消息来进行秘钥变更。

握手协议流程（作者理解）：

1. 建立 QUIC 连接，QUIC 向 TLC 提供 QUIC 传输参数
2. 触发 TLS 模块进行 TLS 握手协议流程，其中 TLS 报文由 CRYPTO 封装后经过 QUIC 发送。
3. 握手完成后，TLS 模块转为被动模式，由派生的秘钥对整个 QUIC （包括包头）进行完整性保护。（除了版本协商和 retry_package）

四、额外特性

4.1 协议和版本协商保护

由于初始报文中，版本未经保护，因此可能遭受降级攻击。

QUIC 要求加密握手提供经过身份验证的协议协商。 TLS 使用应用层协议协商(ALPN)来选择应用协议。 除非使用另一种机制来商定应用协议，否则终端必须为此使用 ALPN。 使用 ALPN 时，如果未协商应用协议，则终端必须中止连接。

4.2 QUIC 传输参数扩展

这是一个 TLS 扩展，携带了 QUIC 传输参数的相关信息，用于对这些信息提供机密和完整性保护。