Bug fix: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries

Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level when they followed a key-changing message in the same record. The handshake transcript is still authenticated, so a network-position attacker cannot use this to alter or complete a handshake; the practical effect is that a peer could send handshake messages that should be encrypted in plaintext without rustls rejecting the connection.

This issue is tracked as GHSA-2mjx-qc3c-rqvc. This issue affects rustls versions 0.23.13 through 0.23.44 inclusive.

Note that this is functionally the same bug as GO-2026-4340.

What's Changed

• 0.23.45: Ensure handshake "alignment" check covers previously-received messages by @ctz in #3265
• Further 0.23 backports by @ctz in #3268 -- this incorporates
  • #3245
  • #3259
  • #3260
  • #3267

Full Changelog: v/0.23.44...v/0.23.45

Support for post-quantum secure ML-DSA certificates is now enabled by default in the aws-lc-rs crypto provider. ML-DSA certificates are not supported in the public web PKI, but they can be used with private certificate hierarchies.

The built-in KeyLogFile implementation now creates files that are restricted to being read only by the owner.

What's Changed

• [0.23] Enable ML-DSA by default by @djc in #3249
• [0.23] Create SSLKEYLOGFILE with owner-only permissions by @djc in #3210
• 0.23: verify server certificate against correct name on ECH rejection by @ctz in #3236
• Fix internal rustls links in README.md to make it compatible with cra… by @Erik-Sovereign in #3239

• Bug fix: corrected reachable panic in debug mode (or with overflow-checks) when decrypting a ticket of specific lengths with Rfc5077Ticketer (and therefore rustls::crypto::aws_lc_rs::Ticketer). This happens pre-authentication.

  This is not used in the default configuration, but using stateless resumption is common and this affects the aws-lc-rs provider. The ticketer associated with the ring provider is not affected.

• Bug fix: A QUIC client using a CryptoProvider that mixes QUIC-capable and -incapable TLS1.3 suites can panic if the server chooses the QUIC-incapable suite.

• Bug fix: A QUIC client would incorrectly accept a TLS1.2 server hello. A full handshake would require a trusted server that talks TLS1.2 in QUIC.

What's Changed

• 0.23 backports by @ctz in #3182

Full Changelog: v/0.23.42...v/0.23.43

• Implemented support for "TLS Ticket Requests" (RFC 9149)
  • Client-side: a new optional ClientConfig.send_ticket_request configuration field was added to allow specifying TicketRequest parameters for requesting a specific number of TLS 1.3 session tickets from the server. Defaults to None, which skips sending the client extension and preserves current behavior.
  • Server-side: a new ServerConfig.max_tls13_tickets configuration field was added to allow setting an upper bound on the number of TLS 1.3 tickets sent in response to a client's request. Defaults to 0, which ignores the client's ticket requests extension and preserves current behavior.

What's Changed

• Backport RFC 9149 ticket_request extension by @hz2 in #3132

What's Changed

• Update read_buf API to match current nightly by @djc in #3102

• ECH: correct implementation of RFC-recommended padding scheme for SNI names in the inner client hello.
• ECH: correct padding of inner client hello when SNI is disabled.
• Alter default of ServerConfig::require_ems based on provider's FIPS status. Prior to this change, the default followed the fips crate feature, which was less helpful for users of external FIPS-approved providers.

What's Changed

• Default require_ems based on CryptoProvider FIPS status by @janrueth in #3034
• 0.23.40: backport ECH padding fixes to 0.23 by @ctz in #3044

Full Changelog: v/0.23.39...v/0.23.40

Adapts to updated nightly for the non-default read_buf feature.

What's Changed

• 0.23 branch cleanup by @djc in #3035
• Prepare 0.23.39 by @cpu in #3037

Full Changelog: v/0.23.38...v/0.23.39

What's Changed

• Backport client: allow skipping selected ALPN validation by @TaeHagen in #3020

Adds support for ML-KEM-1024 key exchange.

What's Changed

• rel-0.23 CI fixes by @ctz in #2933
• Add ML-KEM-1024 key encapsulation mechanism by @DarkmatterVale in #2932

Full Changelog: v/0.23.36...v/0.23.37

Fix #2825 by allowing P256+SHA512 and P384-SHA512 signatures in certificate chains.

What's Changed

• 0.23.36: Support P256+SHA512 and P384+SHA512 signatures in certificates by @ctz in #2828

Full Changelog: v/0.23.35...v/0.23.36