RFR: 8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message" [v2]

[Alice Pellegrini]

On Mon, 29 Sep 2025 16:43:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> According to the TLS specification, RFC 8446 section 5,
>> 
>> An implementation may receive an unencrypted record of type
>>    change_cipher_spec consisting of the single byte value 0x01 at any
>>    time after the first ClientHello message has been sent or received
>>    and before the peer's Finished message has been received and MUST
>>    simply drop it without further processing. Note that this record may
>>    appear at a point at the handshake where the implementation is
>>    expecting protected records, and so it is necessary to detect this
>>    condition prior to attempting to deprotect the record. An
>>    implementation which receives any other change_cipher_spec value or
>>    which receives a protected change_cipher_spec record MUST abort the
>>    handshake with an "unexpected_message" alert. If an implementation
>>    detects a change_cipher_spec record received before the first
>>    ClientHello message or after the peer's Finished message, it MUST be
>>    treated as an unexpected record type (though stateless servers may
>>    not be able to distinguish these cases from allowed cases).
>> 
>> 
>> However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by friedbyalice at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27529#pullrequestreview-3317945400