crypto/tls: skip unsupported ECH config versions

When we encounter an ECHConfig structure with an unsupported version,
the RFC 9849 section 4 text indicates we MUST ignore it. The
parseECHConfig helper returns a skip boolean when this case is hit, but
previously processECHClientHello treated this as equivalent to a non-nil
error return, sending an alert and terminating the handshake.

Instead we should handle the nil error true skip case by continuing to
try the next available echKeys entry, ignoring the unsupported version
entry. If we exhaust all available echKeys without finding a supported
one, we will not accept ECH as expected.

Change-Id: Id0a21c48b472756ad27a028be4d8422c1e9dd3ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/771461
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This commit is contained in:
yuhan6665
2026-09-08 21:33:47 -04:00
parent ac0f415d2e
commit 09c32d597e
+1 -1
View File
@@ -572,7 +572,7 @@ func (c *Conn) processECHClientHello(outer *clientHelloMsg, echKeys []EncryptedC
for _, echKey := range echKeys {
skip, config, err := parseECHConfig(echKey.Config)
if err != nil || skip {
if err != nil {
c.sendAlert(alertInternalError)
return nil, nil, fmt.Errorf("tls: invalid EncryptedClientHelloKey Config: %s", err)
}