In rustls 0.23.44 and 0.23.45, application data that a client buffers before the handshake completes is sent to the server even when the server rejects Encrypted Client Hello (ECH).

When the server rejects ECH, the client completes the handshake with the outer ClientHello and authenticates the server against the ECH config's public_name. At the end of the handshake, start_traffic() encrypts and queues any plaintext buffered by ClientConnection::writer(). It does this before checking for EchStatus::Rejected and queueing the ech_required alert.

The application then receives Error::PeerIncompatible(ServerRejectedEncryptedClientHello), as expected. However, the client is still expected to call write_tls() to send the fatal alert, and that call also sends the encrypted application data. The server decrypts the data and only then receives the alert.

The ordering bug is older than 0.23.44. Before 0.23.44, the client checked the server certificate against the inner server name rather than public_name, so a correctly configured server failed certificate verification first and no data was sent. 0.23.44 fixed that check, which makes the ordinary rejection path reachable.

Impact

Plaintext meant for the inner server, the one named in the encrypted ClientHello, goes to the client-facing server identified by public_name. That server is properly authenticated, so this is not an attack by an unauthenticated party. However this violates RFC 9849, which says the following:

• Section 6.1.6: if the handshake and authentication succeed after ECH rejection, the client "MUST ... abort the connection with an "ech_required" alert before sending any application data to the server."
• Section 6.1.7: the certificate is checked only against public_name, and the connection "MUST NOT" be reported as successful to the application. rustls does report failure correctly. The problem is only that data is sent before the alert.

This affects only clients that meet all of these conditions:

• They use EchMode::Enable. GREASE ECH is not affected.
• They write application data before the handshake completes.
• They connect to a server that rejects their ECH config, for example because the config is stale. This is the same case where the server returns retry configs.

The usual client response to rejection is to retry with the server's retry configs. In that case, the data has already gone to the outer server.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

In rustls 0.23.44 and 0.23.45, application data that a client buffers before the handshake completes is sent to the server even when the server rejects Encrypted Client Hello (ECH).

When the server rejects ECH, the client completes the handshake with the outer ClientHello and authenticates the server against the ECH config's public_name. At the end of the handshake, start_traffic() encrypts and queues any plaintext buffered by ClientConnection::writer(). It does this before checking for EchStatus::Rejected and queueing the ech_required alert.

The application then receives Error::PeerIncompatible(ServerRejectedEncryptedClientHello), as expected. However, the client is still expected to call write_tls() to send the fatal alert, and that call also sends the encrypted application data. The server decrypts the data and only then receives the alert.

The ordering bug is older than 0.23.44. Before 0.23.44, the client checked the server certificate against the inner server name rather than public_name, so a correctly configured server failed certificate verification first and no data was sent. 0.23.44 fixed that check, which makes the ordinary rejection path reachable.

Impact

Plaintext meant for the inner server, the one named in the encrypted ClientHello, goes to the client-facing server identified by public_name. That server is properly authenticated, so this is not an attack by an unauthenticated party. However this violates RFC 9849, which says the following:

• Section 6.1.6: if the handshake and authentication succeed after ECH rejection, the client "MUST ... abort the connection with an "ech_required" alert before sending any application data to the server."
• Section 6.1.7: the certificate is checked only against public_name, and the connection "MUST NOT" be reported as successful to the application. rustls does report failure correctly. The problem is only that data is sent before the alert.

This affects only clients that meet all of these conditions:

• They use EchMode::Enable. GREASE ECH is not affected.
• They write application data before the handshake completes.
• They connect to a server that rejects their ECH config, for example because the config is stale. This is the same case where the server returns retry configs.

The usual client response to rejection is to retry with the server's retry configs. In that case, the data has already gone to the outer server.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

In rustls 0.23.44 and 0.23.45, application data that a client buffers before the handshake completes is sent to the server even when the server rejects Encrypted Client Hello (ECH).

When the server rejects ECH, the client completes the handshake with the outer ClientHello and authenticates the server against the ECH config's public_name. At the end of the handshake, start_traffic() encrypts and queues any plaintext buffered by ClientConnection::writer(). It does this before checking for EchStatus::Rejected and queueing the ech_required alert.

The application then receives Error::PeerIncompatible(ServerRejectedEncryptedClientHello), as expected. However, the client is still expected to call write_tls() to send the fatal alert, and that call also sends the encrypted application data. The server decrypts the data and only then receives the alert.

The ordering bug is older than 0.23.44. Before 0.23.44, the client checked the server certificate against the inner server name rather than public_name, so a correctly configured server failed certificate verification first and no data was sent. 0.23.44 fixed that check, which makes the ordinary rejection path reachable.

Impact

Plaintext meant for the inner server, the one named in the encrypted ClientHello, goes to the client-facing server identified by public_name. That server is properly authenticated, so this is not an attack by an unauthenticated party. However this violates RFC 9849, which says the following:

• Section 6.1.6: if the handshake and authentication succeed after ECH rejection, the client "MUST ... abort the connection with an "ech_required" alert before sending any application data to the server."
• Section 6.1.7: the certificate is checked only against public_name, and the connection "MUST NOT" be reported as successful to the application. rustls does report failure correctly. The problem is only that data is sent before the alert.

This affects only clients that meet all of these conditions:

• They use EchMode::Enable. GREASE ECH is not affected.
• They write application data before the handshake completes.
• They connect to a server that rejects their ECH config, for example because the config is stale. This is the same case where the server returns retry configs.

The usual client response to rejection is to retry with the server's retry configs. In that case, the data has already gone to the outer server.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

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 affects rustls versions 0.23.13 through 0.23.44 inclusive.

Original report

Summary

Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.

This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7

Details

It appears Deframer::aligned considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.

This is insufficient per RFC 8446 section 5.1's

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

Impact

An on path attacker can inject plaintext messages that are accepted.

Tool Use Disclosure

This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.