On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula <pkopp...@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
