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

[Sean Coffey]

On Wed, 20 Mar 2024 09:55:34 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
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

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

> 795:             shc.handshakeOutput.flush();
> 796: 
> 797:             // In the Middlebox Compatibility Mode the server sends a

maybe this reads better:
// In TLS1.3 middlebox compatibility mode the server sends a

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

> 799:             // first handshake message. This may either be after
> 800:             // a ServerHello or a HelloRetryRequest.
> 801:             //(RFC 8446, Appendix D.4)

minor nit - space: ` // (RFC 8446, Appendix D.4)`

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

> 800:             // a ServerHello or a HelloRetryRequest.
> 801:             //(RFC 8446, Appendix D.4)
> 802:             shc.conContext.outputRecord.changeWriteCiphers(

the JDK exposes middlebox compatibility mode via the `jdk.tls.client.useCompatibilityMode` property. Is that a factor for this fix ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531953580
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531954119
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531955972