关于QUIC Initial包的安全问题

[YongChingShieh]

QUIC的Initial包虽然加密，但密钥可被被动推导 QUIC Initial包的安全问题：
QUIC Initial包使用从连接ID（Connection ID）和初始密钥派生出的密钥进行加密，这些信息是公开的，因此任何中间人都可以解密Initial包。
这暴露了Initial包中的信息，例如TLS Client Hello（在QUIC中，TLS握手是在QUIC内部进行的，所以Client Hello是QUIC Initial包的一部分）。

加密 Client Hello 和 Initial 包分片 是提高QUIC在传输层安全性的一些有效手段，尤其是在面临流量分析等被动攻击时。这两种技术可以帮助确保QUIC协议的更加稳固的加密机制

tuic的底层quic是否处理了这个问题

[Itsusinn]

目前 TUIC 底层的 quinn 在建立连接时发出的 QUIC 初始包确实可进行解密。然而GFW 能获取的仅仅是 SNI 而已。

根据 GFW Report 我认为目前针对 QUIC 的 SNI 阻断主要基于一个 SNI 的黑名单。而该名单并非是根据统计学手段生成而是人为制定的。对于拥有独立SNI 的 TUIC 节点来说恐怕影响不大。

尽管如此，当下我有意愿将 tuic-jls 合并到主线。JLS 是一种 FakeTLS，我认为和你顾虑的 QUIC 之于 GFW 抗封锁能力有关。

[YongChingShieh]

目前 TUIC 底层的 quinn 在建立连接时发出的 QUIC 初始包确实可进行解密。然而GFW 能获取的仅仅是 SNI 而已。

根据 GFW Report 我认为目前针对 QUIC 的 SNI 阻断主要基于一个 SNI 的黑名单。而该名单并非是根据统计学手段生成而是人为制定的。对于拥有独立SNI 的 TUIC 节点来说恐怕影响不大。

尽管如此，当下我有意愿将 tuic-jls 合并到主线。JLS 是一种 FakeTLS，我认为和你顾虑的 QUIC 之于 GFW 抗封锁能力有关。

根据我浅薄的知识看 FakeTLS它是工作在 应用层（TLS 握手内部） 需要去魔改TLS 看起来好像有点治标不治本 而quic initial分片是
QUIC Initial包结构：
┌───────────────────────┐
│ HEADER (未加密) │
├───────────────────────┤
│ CRYPTO Frame 1 │ → 包含部分TLS ClientHello
├───────────────────────┤
│ CRYPTO Frame 2 │ → 包含剩余SNI/扩展
└───────────────────────┘