The Config.Clone methods allows cloning a Config which has already been passed
to a TLS function, allowing it to be mutated and reused.

If Config.SessionTicketKey has not been set, and Config.SetSessionTicketKeys has
not been called, crypto/tls will generate random session ticket keys and
automatically rotate them. Config.Clone would copy these automatically generated
keys into the returned Config, meaning that the two Configs would share session
ticket keys, allowing sessions created using one Config could be used to resume
sessions with the other Config. This can allow clients to resume sessions even
though the Config may be configured such that they should not be able to do so.

Config.Clone no longer copies the automatically generated session ticket keys.
Config.Clone still copies keys which are explicitly provided, either by setting
Config.SessionTicketKey or by calling Config.SetSessionTicketKeys.

This issue was discoverd by the Go Security team while investigating another
issue reported by Coia Prant (github.com/rbqvq).

Additionally, on the server side only the expiration of the leaf certificate, if
one was provided during the initial handshake, was checked when considering if a
session could be resumed. This allowed sessions to be resumed if an intermediate
or root certificate in the chain had expired.

Session resumption now takes into account of the full chain when determining if
the session can be resumed.

Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.

This is CVE-2025-68121 and Go issue https://go.dev/issue/77113.

This is a PRIVATE issue for CVE-2025-68121, tracked in http://b/470079652 and fixed by https://go-internal-review.git.corp.google.com/c/go/+/3300.

/cc @golang/security and @golang/release