On Fri, 26 Sep 2025 15:38:20 GMT, Artur Barashev <[email protected]> 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.
test/jdk/sun/security/ssl/SSLEngineImpl/TLS13ChangeCipherSpecAfterFinished.java
line 122:
> 120: ex -> {
> 121: assertTrue(ex instanceof SSLProtocolException);
> 122: assertEquals(ex.getMessage(), exMsg);
nitpick: expected goes on the left hand side, [see
here](https://github.com/openjdk/jdk/blob/fdbba049a2491c591fc1a866e4707bf9aac50f17/test/lib/jdk/test/lib/Asserts.java#L206-L210)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27529#discussion_r2387985209
