<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Thanks Domien.</p>
<p>First off, thank you so much for the detailed bug report, and how
to reproduce. It made creating a reproducer very easy.<br>
</p>
<p>JDK-8221218 and friends were test bugs, but happen to have the
same exceptions that you're seeing here.<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>BTW, the plaintext alerts you mention in step 5 are
protocol-independent, so should work in any version of TLS.</p>
<p>Hope this helps.<br>
</p>
<p>Brad</p>
<p>[1] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-JDK-8331682">https://bugs.openjdk.org/browse/JDK-JDK-8331682</a></p>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/3/2024 8:28 AM, Domien Nowicki
wrote:<br>
</div>
<blockquote type="cite" cite="mid:33b87d71-5b5a-41dd-a81f-5e3115999381@ccvlab.eu">
<p>Hi everyone,</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>We started to investigate and traced it down to the following
scenario:</p>
<p>- 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</p>
<p><br>
</p>
<p>1. Client sends hello <br>
</p>
<blockquote>
<p><font face="monospace"> "client version" : "TLSv1.2",<br>
<br>
"supported_versions (43)": {<br>
"versions": [TLSv1.3, TLSv1.2]<br>
},<br>
</font></p>
</blockquote>
<p>2. Server processes the client hello, and attempts to send
server hello:<br>
</p>
<blockquote>
<p><font face="monospace"> "server version" : "TLSv1.2",<br>
<br>
"supported_versions (43)": {<br>
"selected version": [TLSv1.3]<br>
},<br>
</font></p>
</blockquote>
<p>3. From this point, server has switched to TLSv1.3 and is using
a GcmReadCipher (from SSLCipher class)</p>
<p>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</p>
<p>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</p>
<p>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.</p>
<p><br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p><br>
</p>
<p>So it seems the JDK SSLEngine did not take the above scenario
into account, or are we missing something?</p>
<p><br>
</p>
<p>Best regards,</p>
<p>Domien</p>
<p><br>
</p>
</blockquote>
</body>
</html>