-
Bug
-
Resolution: Unresolved
-
P4
-
8, 26
-
None
-
Cause Known
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.
```
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.
- links to
-
Review(master) openjdk/jdk/27529