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

[Xue-Lei Andrew Fan]

On Thu, 17 Oct 2024 15:55:29 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> > Does it happen in server side (server send plaintext) as well? I found some cases that the client decryption failed.
> 
> Current reports indicate it happens on the server side only (server throws the exception). Please share any cases when it happens on the client side. This PR has a check to handle this scenario on the server side only.

Here is a stack trace:


javax.net.ssl.SSLHandshakeException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:378)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:316)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:134)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:576)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:187)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1458)
at java.base/sun.net.www.protocol.http.HttpURLConnection$8.run(HttpURLConnection.java:1421)
at java.base/sun.net.www.protocol.http.HttpURLConnection$8.run(HttpURLConnection.java:1419)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at java.base/java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:962)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1418)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:220)

>> src/java.base/share/classes/sun/security/ssl/SSLTransport.java line 131:
>> 
>>> 129:             throw context.fatal(Alert.BAD_RECORD_MAC, bte);
>>> 130:         } catch (BadPaddingException bpe) {
>>> 131:             // Check for unexpected plaintext alert message during TLSv1.3+ handshake.
>> 
>> Could the case happen for SSLEngine as well?
>
> Yes, we have tests for both `SSLEngine` and `SSLSocket` usages. In case of SSLEngine the data is passed downstream in `srcs` array.

It looks like SSLEngine does not use the cached record?  I did not get the point to have two different logic for SSLEngine and SSLSocket.

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

PR Comment: https://git.openjdk.org/jdk/pull/21043#issuecomment-2420087269
PR Review Comment: https://git.openjdk.org/jdk/pull/21043#discussion_r1805143099