@copilot 我是问你“现在 Xray 的 ECH 会加密哪些信息”，列举出来

@copilot 我是问你“现在 Xray 的 ECH 会加密哪些信息”，列举出来

现在 Xray 的 ECH 会加密以下信息（放在 inner ClientHello 中，外部不可见）：

1. SNI (server_name) — 真实的服务器名称被加密，outer ClientHello 使用 ECH config 中的 public_name（如 cloudflare-ech.com）
2. ALPN (application_layer_protocol_negotiation) — 真实的协议列表被加密（本 PR 的改动），outer ALPN 固定显示为 h2, http/1.1

外部可观测到的 outer ClientHello 包含：

• ECH config 的 public_name 作为 SNI
• 通用 ALPN h2, http/1.1
• encrypted_client_hello 扩展（包含加密后的 inner ClientHello 密文）
• 非敏感扩展：supported_versions、key_share、supported_groups、signature_algorithms 等（由 uTLS 指纹决定，inner/outer 通常相同）

代码层面：

• copyConfig() 在 ECH 启用时将 ServerName 和 NextProtos 传入 utls config → 进入 inner ClientHello
• WebsocketHandshakeContext() 在 ECH 启用时跳过将 outer ALPN 改为 http/1.1，保持真实 ALPN 仅在 inner 中

* 非敏感扩展：`supported_versions`、`key_share`、`supported_groups`、`signature_algorithms` 等（由 uTLS 指纹决定，inner/outer 通常相同）

@copilot 这些也会被复制一份进 inner client hello 吗

* 非敏感扩展：`supported_versions`、`key_share`、`supported_groups`、`signature_algorithms` 等（由 uTLS 指纹决定，inner/outer 通常相同）

@copilot 这些�...

不完全是"复制一份"。根据 uTLS fork 中 handshake_messages.go 的 marshalMsgReorderOuterExts() 实现，inner ClientHello 对这些扩展使用了 ECH outer extension compression（ech_outer_extensions）。

具体来说，当 echInner == true 时：

使用 ECH 压缩引用（inner 不重复，引用 outer 的值，内外相同）：

• supported_groups (supported_curves)
• signature_algorithms
• signature_algorithms_cert
• supported_versions
• key_share
• psk_modes
• cookie
• status_request (OCSP)

inner/outer 各自独立携带（值可以不同，这才是 ECH 真正隐藏的）：

• server_name (SNI) — inner 是真实域名，outer 是 ECH config 的 public_name
• ALPN — inner 是真实协议，outer 是 h2, http/1.1（本 PR 改动）

仅在 outer 中存在（inner 直接跳过）：

• supported_points
• session_ticket
• renegotiation_info
• extended_master_secret

所以 supported_versions、key_share 等并非被"复制"进 inner，而是 inner 通过 ech_outer_extensions 引用 outer 中的同一份数据，服务端解密后重建完整 inner ClientHello。

@copilot 所以带上隐藏 ALPN 后 encrypted_client_hello 的长度是否可以与不带 ALPN 区分？它们是否可以与 GREASE 区分？

@copilot 所以带上隐藏 ALPN 后 encrypted_client_hello 的长度是否可以与不带 ALPN 区分？它们是否可以与 GREASE 区分？

关于带 ALPN vs 不带 ALPN 的长度区分：

encodeInnerClientHelloReorderOuterExts() 对 inner ClientHello 进行 32 字节对齐填充：

paddingLen = 31 - ((len(h) + paddingLen - 1) % 32)

ALPN 扩展（如 ["http/1.1"]）大约增加 15 字节。由于 32 字节填充，加密后的密文长度变化取决于总 inner hello 大小是否跨过 32 字节边界。大多数情况下填充会吸收这个差异，但并非 100% 保证——如果恰好跨越边界，encrypted_client_hello 会增大 32 字节。

不过这并不是实际问题，因为：

1. 本 PR 是把 outer 的 ALPN 从 http/1.1 变成 h2, http/1.1，inner 的 ALPN 始终存在（值为真实 ALPN）——所以 inner 长度不变，encrypted_client_hello 长度也不变
2. 即使 inner 不带 ALPN（比如未来的其他场景），观察者只能看到密文长度的 32 字节粒度变化，无法精确推断 ALPN 是否存在

关于与 GREASE 的区分：

可以区分。GREASE ECH 的 payload 长度是固定候选值：128, 160, 192, 224（加密后 +16 tag = 144, 176, 208, 240）。而真正的 ECH payload 长度 = encodedInner + 16，取决于实际 inner ClientHello 大小（经 32 字节对齐后）。两者的长度大概率不同。

此外，真正的 ECH 携带 encapsulatedKey（32 字节 X25519 公钥），GREASE 也是 32 字节随机数据——这部分无法区分。但 payload 长度是主要区分特征：GREASE 使用 BoringSSL 的固定几种长度，而真实 ECH 的长度由实际 inner hello 内容决定。

实际上这也是浏览器的现状——Chrome 的 GREASE ECH 和真实 ECH 的 payload 长度不同，是已知的可区分点。

@copilot 你的意思是即使没有该 PR 的修改，encrypted_client_hello 中本来就包含 outer ALPN 的一份拷贝而不是引用吗

此外，真正的 ECH 携带 encapsulatedKey（32 字节 X25519 公钥），GREASE 也是 32 字节随机数据——这部分无法区分。

然而 X25519 公钥并不是纯随机数，此外详细解释 ECH 的加解密机制

@copilot 你的意思是即使没有该 PR 的修改，encrypted_client_hello 中本来就包含 outer ALPN 的一份拷贝而不是引用吗

此外，真正的 ECH 携带 `enca...

是的。在 uTLS fork 的 handshake_messages.go 第 244-246 行，ALPN 的压缩引用被显式禁用了：

if echInner && false {  // 注意 && false，永远不会进入
    echOuterExts = append(echOuterExts, extensionALPN)
}

注释写的是 "ALPN extension copy is skipped because in ECH inner, the ALPN might be different"。所以即使没有本 PR 的修改，inner ClientHello 中也是独立携带一份完整的 ALPN 扩展，而非通过 ech_outer_extensions 引用 outer 的值。本 PR 的作用是让 inner 和 outer 的 ALPN 值不同（inner 为真实 ALPN，outer 为 h2, http/1.1）。

关于 X25519 和 ECH 加解密机制：

你说得对，X25519 公钥不是纯随机数。encapsulatedKey 是 X25519 椭圆曲线上的点，具有代数结构，理论上可与纯随机字节区分（尽管 X25519 设计上已尽量接近 uniform random）。

ECH 加解密的完整机制（基于 HPKE，RFC 9180）：

1. 密钥封装（客户端，SetupSender）：

• 客户端生成临时 X25519 私钥 privEph（ecdh.X25519().GenerateKey(rand.Reader)）
• 计算 encapsulatedKey = privEph.PublicKey().Bytes()（32 字节，发送给服务端）
• 计算 DH 共享密钥：dhVal = ECDH(privEph, pubRecipient)，其中 pubRecipient 来自 ECH config
• 构造 kemContext = encapsulatedKey || pubRecipient.Bytes()
• 通过 ExtractAndExpand 派生 sharedSecret：
  • eaePRK = LabeledExtract("KEM" || kemID, nil, "eae_prk", dhVal)
  • sharedSecret = LabeledExpand("KEM" || kemID, eaePRK, "shared_secret", kemContext, 32)

2. 密钥调度（newContext）：

• suiteID = "HPKE" || kemID || kdfID || aeadID
• info = "tls ech\x00" || echConfig.raw（绑定到具体 ECH 配置）
• 派生加密密钥和 nonce：
  • pskIDHash = LabeledExtract(suiteID, nil, "psk_id_hash", nil)
  • infoHash = LabeledExtract(suiteID, nil, "info_hash", info)
  • ksContext = 0x00 || pskIDHash || infoHash
  • secret = LabeledExtract(suiteID, sharedSecret, "secret", nil)
  • key = LabeledExpand(suiteID, secret, "key", ksContext, keySize)（AES-128-GCM: 16 bytes）
  • baseNonce = LabeledExpand(suiteID, secret, "base_nonce", ksContext, nonceSize)（12 bytes）

3. 加密 inner ClientHello（Seal）：

• encodedInner = inner ClientHello（经 32 字节对齐填充）
• AAD = 序列化后的 outer ClientHello（payload 位置置零）
• nonce = seqNum XOR baseNonce（首次 seqNum=0，所以 nonce=baseNonce）
• ciphertext = AEAD.Seal(nonce, encodedInner, AAD)（密文 = 明文 + 16 字节 tag）

4. 解密（服务端，SetupReceipient + Open）：

• 服务端用自己的 X25519 私钥和客户端发来的 encapsulatedKey 计算相同的 sharedSecret：
  • dhVal = ECDH(secRecipient, encPubEph)
  • 同样的 ExtractAndExpand → 同样的 sharedSecret
• 用相同的密钥调度派生相同的 key 和 baseNonce
• AAD = 把 outer ClientHello 中 ECH payload 替换为零后的数据
• plaintext = AEAD.Open(nonce, ciphertext, AAD) → 得到 encodedInner

关于 GREASE ECH 的 encapsulatedKey：
GREASE ECH 默认也通过 hpke.SetupSender 生成（对一个 dummy X25519 公钥做 DH），所以它也是合法的 X25519 公钥点而非纯随机字节。但当通过 Write() 解析已有扩展数据时（如从抓包重放），GREASE 会用 rand.Read 生成纯随机 32 字节覆盖，这时才会与真正的 X25519 点有可区分性。

@copilot 又在胡说，我看原代码 inner alpn 咋更像是压缩引用而并非你说的独立携带呢？也就是说密文长度可能会有变化

@copilot 又在胡说，我看原代码 inner alpn 咋更像是压缩引用而并非你说的独立携带呢？也就是说密文长度可能会有变化

你说得对，我之前搞错了。

原始 upstream refraction-networking/utls 中，ALPN 确实是通过 ech_outer_extensions 压缩引用的：

// upstream 原版 handshake_messages.go:246
if echInner {
    echOuterExts = append(echOuterExts, extensionALPN)
}

inner ALPN = 引用 outer ALPN 的值，内外相同。

fangliding fork 把它改成了 echInner && false 来禁用压缩，使 inner ALPN 独立携带：

// fork 修改后
if echInner && false {  // 永远不进入，ALPN 不走压缩
    echOuterExts = append(echOuterExts, extensionALPN)
}

所以密文长度确实会变化：原本 inner 中 ALPN 只占 ech_outer_extensions 列表中的 2 字节引用，改为独立携带后增加约 13-16 字节（取决于具体 ALPN 值）。经过 32 字节对齐填充后，encrypted_client_hello 的 payload 可能增大 0 或 32 字节。

这 AI 还是傻

@copilot #5725 (comment)

@copilot #5725 (comment)

ech_outer_extensions 列表本身的长度变化约 2 字节（加/减一个 ALPN 类型 ID），经过 32 字节对齐后可能不变或增大 32 字节。由于无法假定 SNI 长度，密文长度本身不构成稳定的区分特征。

关于 inner payload 是否达不到 128：

对于 Xray（uTLS path，MaxNameLength=0）：inner hello 包含 3 个 TLS 1.3 cipher suite + SNI + SCTs + ECH inner marker + ALPN（独立携带）+ ech_outer_extensions（~5 个引用）+ supported_versions（直接携带）。对于典型域名（3-33 字符），未填充的 inner hello 约 98-128 字节，经 32 字节对齐后 = 128 字节，加密后 = 144 字节。

最短的 GREASE ECH payload（CandidatePayloadLens 默认 [128]）加密后也是 144 字节。所以 Xray 的真 ECH 和最短 GREASE 大小相同（128 pre-enc = 144 encrypted），真 ECH 并不比 GREASE 短。

对于 Chrome/BoringSSL：Chrome 的 inner hello 更大（15+ cipher suites、compress_certificate、ALPS 等扩展），但因为大量扩展通过 ech_outer_extensions 压缩，最终大小也落在 128 或 160 pre-enc 附近。Chrome 的 GREASE 使用 [128, 160, 192, 224] 四个候选值，真 ECH 的 payload 大小恰好也会落在这几个值之一（因为都是 32 字节对齐）。所以 Chrome 的真 ECH 和 GREASE 在 payload 大小上也是不可区分的——这是有意设计的。

总结：真 ECH ≥ 最短 GREASE，两者在 payload 长度上基本匹配。

@copilot 你看看你又在瞎说，Chrome TLSv1.3 哪有 15+ cipher suites，另外 uTLS 的任务之一就是模仿 Chrome client hello

@copilot 你看看你又在瞎说，Chrome TLSv1.3 哪有 15+ cipher suites，另外 uTLS 的任务之一就是模仿 Chrome client hello

你说得对，Chrome 的 TLS 1.3 cipher suites 只有 3 个（AES_128_GCM、AES_256_GCM、CHACHA20_POLY1305），不是 15+。Chrome 的 outer ClientHello 总共 16 个 cipher suites（GREASE + 3 TLS 1.3 + 12 TLS 1.2），但 TLS 1.3 部分确实只有 3 个。

关于 uTLS 模仿 Chrome：uTLS 的 outer ClientHello 确实模仿 Chrome 指纹（16 cipher suites + 相同的扩展列表和顺序）。但 ECH 的 inner ClientHello 是通过 Go 的 makeClientHello() 生成的，由于 ECH 要求 supportedVersions = [TLS 1.3]，inner 的 cipher suites 会被重置为仅 3 个 TLS 1.3 suites。inner 的其他敏感字段（keyShares、supportedCurves、signatureAlgorithms）从 outer spec 复制，通过 ech_outer_extensions 压缩引用 outer 的值。