Executive Summary

[{'type': 'paragraph', 'content': "This vulnerability occurs in the Go programming language's crypto/tls package during TLS session resumption. If the Config struct's ClientCAs or RootCAs fields are changed between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed."}, {'type': 'paragraph', 'content': 'This can happen if a user clones the Config and modifies it or uses Config.GetConfigForClient. As a result, a client might resume a session with a server it would not have resumed with initially, or a server might resume a session with a client it would not have resumed with during the initial handshake.'}] [2, 3]

Useful 0 Not Useful 0

Impact Analysis

The vulnerability can cause resumed TLS sessions to be accepted based on outdated or changed trust configurations, potentially allowing connections that should be rejected.

This means that a client or server might resume a session with an entity that would not have been trusted during the initial handshake, possibly leading to unauthorized or unintended connections.

However, the Go maintainers consider this a misuse of the API because mutating trust-related fields after passing the Config to TLS functions is discouraged.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

[{'type': 'paragraph', 'content': "This vulnerability arises from the mutation of the tls.Config's ClientCAs or RootCAs fields between the initial TLS handshake and session resumption, which is a misuse of the Go crypto/tls API. Detection involves identifying whether your Go applications mutate these fields after the initial handshake or improperly reuse session ticket keys without rotation."}, {'type': 'paragraph', 'content': 'Since this is a programming API misuse issue rather than a network-level exploit, there are no specific network commands to detect it directly. Instead, detection requires code review or runtime inspection of Go applications using the crypto/tls package to check for calls to Config.Clone or Config.GetConfigForClient followed by mutations to ClientCAs or RootCAs.'}, {'type': 'paragraph', 'content': 'You can audit your Go codebase for patterns like:'}, {'type': 'list_item', 'content': 'Usage of Config.Clone followed by modifications to ClientCAs or RootCAs.'}, {'type': 'list_item', 'content': 'Usage of Config.GetConfigForClient that returns a Config which is then mutated.'}, {'type': 'paragraph', 'content': 'Additionally, monitoring TLS session resumption behavior in your application logs or telemetry for unexpected resumed sessions with changed trust configurations may help identify potential exploitation.'}] [2, 3]

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, avoid mutating the ClientCAs or RootCAs fields of a tls.Config after it has been used in a handshake. This is considered misuse of the API and is explicitly discouraged.

Use Config.SetSessionTicketKeys to rotate session ticket keys whenever the trust configuration changes. This ensures that resumed sessions are validated against the current trust settings.

Upgrade your Go environment to a fixed version where this issue is addressed, such as go1.24.13 or later, go1.25.7 or later, or go1.26.0-rc.3 or later.

Review your code to ensure that Config.Clone and Config.GetConfigForClient are not used in a way that mutates trust-related fields between handshakes.

Useful 0 Not Useful 0