Crypto/Tls

Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.

Published: 2026-07-08T15:46:33.407Z
Updated: 2026-07-08T19:38:17.603Z

If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3.

Published: 2026-04-08T01:06:57.670Z
Updated: 2026-07-30T12:05:01.465Z

During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake.

Published: 2026-02-05T17:48:44.141Z
Updated: 2026-04-29T13:29:25.582Z

During the TLS 1.3 handshake if multiple messages are sent in records that span encryption level boundaries (for instance the Client Hello and Encrypted Extensions messages), the subsequent messages may be processed before the encryption level changes. This can cause some minor information disclosure if a network-local attacker can inject messages during the handshake.

Published: 2026-01-28T19:30:30.986Z
Updated: 2026-02-02T17:28:49.572Z

When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.

Published: 2025-10-29T22:10:12.947Z
Updated: 2025-11-04T21:13:39.428Z