On Thu, 26 Jun 2025 18:06:03 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> Daniel Fuchs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 525 commits: >> >> - merge latest changes from master branch >> - http3: run H3StreamLimitReachedTest.java with >> -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too >> - retry the ResetControlStream test as needed >> - http3: fix pending connection and reconnection on stream limit reached >> logic >> - http3: pending acknowledgement should be registered before actually >> sending the packet >> - http3: fix race with ping requests in PacketSpaceManager.java causing >> intermittent failures in H3ErrorHandlingTest.java >> - http3: improve exceptions in Http3ServerExchange.java >> - http3: fix exception handling in CancelRequestTest.java >> - http3: review feedback - revert HPACK.java >> - Implement X509TrustManagerImpl#checkClientTrusted for QUIC >> - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215 > > src/java.base/share/classes/sun/security/ssl/Finished.java line 852: > >> 850: QuicTLSEngineImpl engine = >> 851: (QuicTLSEngineImpl) >> shc.conContext.transport; >> 852: engine.deriveOneRTTKeys(); > > We should not derive the server's 1RTT read keys before processing the > client's Finished message. > > Also, we could skip calculating the SSL WriteCipher when QUIC is in use. > Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys > calculates the same secret) We decided to do this as a follow up after the JEP is integrated. In the meantime, in https://github.com/openjdk/jdk/pull/24751/commits/8d22ca7334da8d8b49d0634ea2f23bd409613928, we now introduce a check where the endpoint doesn't decrypt an incoming 1-RTT packet until the TLS handshake is complete. This matches with what the RFC-9001 specifies. @dfuch, @djelinski I think we can mark this conversation as resolved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288675780
