Reproducer for JDK-8221218 again

[Bradford Wetmore]

Thanks Domien.

First off, thank you so much for the detailed bug report, and how to 
reproduce.   It made creating a reproducer very easy.

JDK-8221218 and friends were test bugs, but happen to have the same 
exceptions that you're seeing here.

This is an unrelated issue.  I have filed JDK-8331682 [1] as an possible 
usability enhancement (full details there including why this fails on 
TLSv1.3 but not 1.2).  It's not very high on the priority list.

TLS depends on TCP's reliable ordering (retry/etc.), so about the only 
thing we might do if the client abandons the connection with a 
close_notify is to retry the inbound message as plaintext if there is a 
decryption failure on that flight.

BTW, the plaintext alerts you mention in step 5 are 
protocol-independent, so should work in any version of TLS.

Hope this helps.

Brad

[1] https://bugs.openjdk.org/browse/JDK-JDK-8331682


On 5/3/2024 8:28 AM, Domien Nowicki wrote:
>
> Hi everyone,
>
>
> Recently we've started to use SSLEngine to create our own TLS server. 
> However we sometimes got the following exception 
> "SSLHandshakeException: Insufficient buffer remaining for AEAD cipher 
> fragment (2)." when dealing with client disconnections at server side 
> during the TLS handshake. This has been tested with latest JDK21.
>
>
> We started to investigate and traced it down to the following scenario:
>
> - Setup: Standard SSLSocket as client (all defaults) connects to our 
> TLS server using Java SSLEngine as internal engine. Both client and 
> server have support for TLSv1.3
>
>
> 1. Client sends hello
>
>       "client version"      : "TLSv1.2",
>
>         "supported_versions (43)": {
>           "versions": [TLSv1.3, TLSv1.2]
>         },
>
> 2. Server processes the client hello, and attempts to send server hello:
>
>       "server version"      : "TLSv1.2",
>
>         "supported_versions (43)": {
>           "selected version": [TLSv1.3]
>         },
>
> 3. From this point, server has switched to TLSv1.3 and is using a 
> GcmReadCipher (from SSLCipher class)
>
> 4. However, in this scenario, due to network congestion or server 
> application being slow, the server hello response is delayed and did 
> not reach the client yet
>
> 5. The client, still assuming it is operating under TLSv1.2, gets a 
> timeout and decides to close the socket. This produces TLSv1.2 alerts 
> (user canceled and close notification) and reaches the server
>
> 6. Server tries to decrypt the TLSv1.2 alerts, but since TLSv1.2 
> alerts are not encrypted, gets the "SSLHandshakeException: 
> Insufficient buffer remaining for AEAD cipher fragment (2)." exception.
>
>
> If the client did receive the server hello response, it would switch 
> to TLSv1.3 properly and would encrypt TLSv1.3 alerts from then on as 
> expected.
>
> Additionally, if we use the same scenario but force TLSv1.2 on the 
> server side, then the server does not use the GcmReadCipher at this 
> point, and it can process the TLSv1.2 alerts properly.
>
>
> So it seems the JDK SSLEngine did not take the above scenario into 
> account, or are we missing something?
>
>
> Best regards,
>
> Domien
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240503/da5baf26/attachment.htm>