Description
When processing ECH, the server constructs the HPKE KDF and AEAD from the client's encrypted_client_hello extension. It does not verify that the client-selected HPKE suite was advertised in the selected ECHConfig.
The impact is narrow: a malicious client that already knows the ECH public key can choose a Go-supported HPKE KDF/AEAD pair not advertised by the server for that client's own connection. This does not expose plaintext or affect honest clients.
Specification
RFC 9849 Section 6.1 says the client must not choose a cipher suite or version not advertised by the selected ECH configuration. RFC 9849 Section 7.1 says the server verifies that the selected ECHConfig supports the cipher suite indicated by ECHClientHello.cipher_suite.
Code references
go/src/crypto/tls/ech.go:573 iterates over configured ECH keys.go/src/crypto/tls/ech.go:592 constructs the HPKE KDF from the client extension.go/src/crypto/tls/ech.go:597 constructs the HPKE AEAD from the client extension.go/src/crypto/tls/ech.go:627 accepts the decrypted ClientHelloInner without checking membership in the selected config's advertised suite list.go/src/crypto/tls/ech.go:631 through go/src/crypto/tls/ech.go:632 stores the untrusted config ID and cipher suite in the ECH context.
Test case
This can be a crypto/tls ECH server test using an ECHConfig that advertises one HPKE symmetric suite while the client encrypts with another Go-supported suite. The server should reject the extension.
This could also become a bogo ECH test: configure a server with an ECHConfig advertising suite A, send a valid ECH payload encrypted under suite B, and expect rejection.
Description
When processing ECH, the server constructs the HPKE KDF and AEAD from the client's
encrypted_client_helloextension. It does not verify that the client-selected HPKE suite was advertised in the selectedECHConfig.The impact is narrow: a malicious client that already knows the ECH public key can choose a Go-supported HPKE KDF/AEAD pair not advertised by the server for that client's own connection. This does not expose plaintext or affect honest clients.
Specification
RFC 9849 Section 6.1 says the client must not choose a cipher suite or version not advertised by the selected ECH configuration. RFC 9849 Section 7.1 says the server verifies that the selected
ECHConfigsupports the cipher suite indicated byECHClientHello.cipher_suite.Code references
go/src/crypto/tls/ech.go:573iterates over configured ECH keys.go/src/crypto/tls/ech.go:592constructs the HPKE KDF from the client extension.go/src/crypto/tls/ech.go:597constructs the HPKE AEAD from the client extension.go/src/crypto/tls/ech.go:627accepts the decrypted ClientHelloInner without checking membership in the selected config's advertised suite list.go/src/crypto/tls/ech.go:631throughgo/src/crypto/tls/ech.go:632stores the untrusted config ID and cipher suite in the ECH context.Test case
This can be a
crypto/tlsECH server test using anECHConfigthat advertises one HPKE symmetric suite while the client encrypts with another Go-supported suite. The server should reject the extension.This could also become a bogo ECH test: configure a server with an ECHConfig advertising suite A, send a valid ECH payload encrypted under suite B, and expect rejection.