为何Google Chrome不允许为HTTP/3 + QUIC使用自定义根证书颁发机构？

核心安全考量 #

• QUIC连接迁移放大MITM风险：QUIC支持跨IP/网络的连接迁移，一旦自定义CA完成MITM劫持，攻击者可持续控制客户端切换网络后的连接；而传统TLS切换网络会重新握手，风险更易控制。Chrome认为这种“持续劫持”的风险远高于传统场景，因此收紧了限制。
• 0-RTT握手加剧信任漏洞：QUIC的0-RTT快速握手允许客户端复用会话密钥，若自定义CA被滥用，MITM节点可直接复用劫持会话，无需重新验证，大幅降低攻击成本且难以检测。Chrome的安全模型刻意规避这种“一次劫持永久控制”的风险。
• 优先保障原生加密链完整性：Chrome将原生QUIC加密链的完整性放在高优先级，自定义CA会打破标准证书链的信任模型。尽管杀毒、DLP的MITM出于安全目的，但这类工具的实现质量参差不齐，可能引入证书存储不当、验证逻辑缺陷等漏洞，反而成为攻击入口。

与其他浏览器的策略差异 #

其他浏览器的安全模型更侧重兼容现有企业/个人安全工具生态，对MITM场景的风险评估相对宽松。而Chrome用户基数大，面临的攻击面更广，因此选择了更保守的策略，优先保护普通用户免受MITM滥用的潜在风险。

针对安全工具的替代方案 #

企业用户可通过Chrome Enterprise Policy配置允许特定自定义CA用于QUIC连接，平衡安全与合规需求；普通用户若遇到工具失效，可通过chrome://flags/#enable-quic禁用HTTP/3，恢复MITM工具的功能。

内容的提问来源于stack exchange，提问作者Joe J