更新 REALITY 抗量子时发现的，目前在客户端我要找到 X25519 而非 X25519MLKEM768 的 x25519EphemeralKey，但是我发现在 uTLS 里面好像给复用了，虽然这在安全上没问题但我抓 Chrome 看了一下发现它两者最后 32 字节是不一样的，所以新版 uTLS 可与 Chrome 一眼区分，望尽快修复
|
hello.keyShares = []keyShare{ |
|
{group: X25519MLKEM768, data: append(mlkemEncapsulationKey, x25519EphemeralKey...)}, |
|
} |
|
// If both X25519MLKEM768 and X25519 are supported, we send both key |
|
// shares (as a fallback) and we reuse the same X25519 ephemeral |
|
// key, as allowed by draft-ietf-tls-hybrid-design-09, Section 3.2. |
|
if slices.Contains(hello.supportedCurves, X25519) { |
|
hello.keyShares = append(hello.keyShares, keyShare{group: X25519, data: x25519EphemeralKey}) |
|
} |
更新 REALITY 抗量子时发现的，目前在客户端我要找到 X25519 而非 X25519MLKEM768 的 x25519EphemeralKey，但是我发现在 uTLS 里面好像给复用了，虽然这在安全上没问题但我抓 Chrome 看了一下发现它两者最后 32 字节是不一样的，所以新版 uTLS 可与 Chrome
一眼区分，望尽快修复utls/handshake_client.go
Lines 183 to 191 in a7bb5ea