RFR: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body
Daniel Jeliński
djelinski at openjdk.org
Wed Sep 24 13:30:34 UTC 2025
On Mon, 22 Sep 2025 20:20:19 GMT, Alice Pellegrini <duke at openjdk.org> wrote:
> According to RFC 8446 section 5.4, third paragraph
>> Application Data records may contain a zero-length
>> TLSInnerPlaintext.content if the sender desires. This permits
>> generation of plausibly sized cover traffic in contexts where the
>> presence or absence of activity may be sensitive. Implementations
>> MUST NOT send Handshake and Alert records that have a zero-length
>> TLSInnerPlaintext.content; if such a message is received, the
>> receiving implementation MUST terminate the connection with an
>> "unexpected_message" alert.
>
>
> The proposed change removes an off by 1 error in the SSLCipher implementation, forces the correct Alert message to be sent in response to zero-length Alert fragments, as well as updating some tests which detected the BadPaddingException but now detect a SSLProtocolException, which is thrown by `TransportContext.fatal`
Looks reasonable. Would it be possible to add a test for the empty plaintext case? Or do we never generate empty plaintexts?
Please update the copyright years.
src/java.base/share/classes/sun/security/ssl/SSLCipher.java line 1926:
> 1924: // remove inner plaintext padding
> 1925: int i = pt.limit() - 1;
> 1926: for (; i > 0 && pt.get(i) == 0; i--);
Suggestion:
for (; i >= pos && pt.get(i) == 0; i--);
src/java.base/share/classes/sun/security/ssl/SSLCipher.java line 2444:
> 2442: // remove inner plaintext padding
> 2443: int i = pt.limit() - 1;
> 2444: for (; i > 0 && pt.get(i) == 0; i--) {
Suggestion:
for (; i >= pos && pt.get(i) == 0; i--) {
-------------
PR Review: https://git.openjdk.org/jdk/pull/27438#pullrequestreview-3262902812
PR Review Comment: https://git.openjdk.org/jdk/pull/27438#discussion_r2375791852
PR Review Comment: https://git.openjdk.org/jdk/pull/27438#discussion_r2375792997
More information about the security-dev
mailing list