RFR: 8326643: JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message

[Daniel Jeliński]

On Tue, 19 Mar 2024 07:13:19 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

We should have a test for this; HelloRetryRequest is sent when the server refuses to use the client-offered key share. The client sends x25519 and secp256r1 key shares by default, so you could create a test where the server accepts only x448, secp384r1, or ffdhe2048.

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 804:

> 802:             shc.conContext.outputRecord.changeWriteCiphers(
> 803:                 SSLWriteCipher.nullTlsWriteCipher(),
> 804:                     (clientHello.sessionId.length() != 0));

Suggestion:

            if (clientHello.sessionId.length() != 0) {
                shc.conContext.outputRecord.encodeChangeCipherSpec();
            }

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

PR Review: https://git.openjdk.org/jdk/pull/18372#pullrequestreview-1945466479
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1529907249