crypto/tls: client should not fail if it sets an ECH config and the server rejects it #75240
Description
Go version
go version go1.25.0 darwin/arm64
Output of go env in your module/workspace:
Not relevantWhat did you do?
I started a TLS connection with a fake, but well-formed ECH Config list in tls.TLSConfig.EncryptedClientHelloConfigList.
What did you see happen?
I get a TLS "ech required" alert and the tls: server rejected ECH error, created in tls.clientHandshakeStateTLS13.handshake()
What did you expect to see?
I expect the handshake to proceed with the ClientHelloOuter if the server doesn't accept ECH, as described in 6.1.4. Determining ECH Acceptance of the ECH standard proposal:
If the server accepts ECH, the client handshakes with ClientHelloInner as described in Section 6.1.5. Otherwise, the client handshakes with ClientHelloOuter as described in Section 6.1.6.
For that tls.clientHandshakeStateTLS13.handshake() needs to be updated to follow a different path on non-acceptance.
For context, I'm trying to simulate ECH GREASE by feeding the code with a fake ECHConfigList: Jigsaw-Code/outline-sdk#518. I want to measure ECH interference across networks and domains, even if the domain doesn't support it.
It would be helpful if the TLS client did ECH GREASE by default, perhaps with a TLSConfig.DisableECHGrease option to disable it. BoringSSL has SSL_set_enable_ech_grease, so it should be easy to add.