The TLS handshake begins with plaintext messages exchanged in both directions, the client hello and the server hello. Once these messages are exchanged, keys are established and subsequent messages are required to be encrypted using those keys.

In TLS 1.2 there is an explicit change cipher spec message which enforces the switch to encrypted messages. In 1.3 this message is optional, and is not required for the client and server to switch to using their established keys.

When we process the initial hello messages, the other side of the connection can concatenate multiple messages, which we store in a buffer. On a CCS message we check that this buffer is empty, preventing us from later consuming a plaintext message when we expect to consume messages which were encrypted. Since the CCS message is option in 1.3, a server, or on path attacker who can modify traffic, can include subsequent messages in their first response to the client (or vice versa), which will then be consumed once we switch to the encrypted portion of the handshake.

Since the transcripts at the end of the handshake will not match, doing so will cause the handshake to fail, but this behavior can be exploited to reduce the security of things like ECH (by attempting to determine the ServerName in the inner client hello).

Due to the limited impact of this issue, we are treating it as a PUBLIC track security issue, per the Go Security Policy (https://go.dev/security/policy).

This is CVE-2025-61730.

cc @rbqvq who initially reported this issue.