RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server

[Daniel Jeliński]

On Tue, 17 Sep 2024 17:44:37 GMT, Artur Barashev <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8331682

Should the client send a close_notify if the connection is closed in the middle of the handshake? I couldn't find a good answer in the TLS1.3 spec, but I'd assume that closing the connection without sending a close_notify would be good enough.
Should the server throw a handshake exception when the handshake is aborted?
Will the server throw the right exception if the client aborts the connection for a different reason (like a server_hello that fails to decode correctly)?

src/java.base/share/classes/sun/security/ssl/SSLTransport.java line 112:

> 110: 
> 111:         // Check for unexpected plaintext alert message during TLSv1.3 handshake, @bug 8331682
> 112:         if (srcsLength == 1 && context.handshakeContext != null &&

The unencrypted message may only be permitted right after the ClientHello; we need a better check for that. `handshakeContext` will be non-null after handling a key_update message, for example.

test/jdk/javax/net/ssl/TLSv13/SSLEngineNoServerHelloClientShutdown.java line 204:

> 202:         // Server unwrap should process an unencrypted 2 byte packet,
> 203:         log("---Server Unwrap user_cancelled alert---");
> 204:         serverResult = serverEngine.unwrap(cTOs, serverIn);

does that mean that we don't throw a SSLHandshakeException on receipt of close_notify in the middle of the handshake?

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

PR Review: https://git.openjdk.org/jdk/pull/21043#pullrequestreview-2312410586
PR Review Comment: https://git.openjdk.org/jdk/pull/21043#discussion_r1764887223
PR Review Comment: https://git.openjdk.org/jdk/pull/21043#discussion_r1764888696