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. ------------- Commit messages: - Add unit test - 8366244: TLS1.3 ChangeCipherSpec message received after the client Finished message should trigger a connection abort with "unexpected message" Changes: https://git.openjdk.org/jdk/pull/27529/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27529&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366244 Stats: 127 lines in 2 files changed: 126 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27529/head:pull/27529 PR: https://git.openjdk.org/jdk/pull/27529
