<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Xuelei, just a couple questions:<br>
<ul>
<li>SSLSocketImpl</li>
<ul>
<li>611: Are you sure conContext.inputRecord should go into a
try-with-resources? As far as I can tell, the inheritence
chain is SSLSocketInputRecord->InputRecord and that
directly or by extension implements the SSLRecord, Record and
Closeable interfaces. I thought that you needed to implement
AutoCloseable in order to get that automatic closure benefit
from leaving the try block. Am I missing something?</li>
</ul>
<li>SSLContextTemplate</li>
<ul>
<li>505: Is there any benefit to initializing the SSLContext
using a PKIXParameters object with the date fixed to sometime
in between 2018 and 2028 (the soonest expiration date of all
the certs in the test). This way you'd never have to worry
about things expiring. I know we don't do this in most of our
tests, dunno why it just occurred to me now.</li>
</ul>
</ul>
<p>The rest looks OK to me.<br>
</p>
--Jamil<br>
<br>
<div class="moz-cite-prefix">On 12/17/2018 9:52 AM, Xue-Lei Fan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ee9d7c61-fd77-a359-484b-5b13cee7e9ed@oracle.com">ping
...
<br>
<br>
On 12/10/2018 1:14 PM, Xue-Lei Fan wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
Please review the TLS 1.3 half-close issue in JDK.
<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/">http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/</a>
<br>
<br>
While trying to duplex close a TLS connection upon the
half-close policy, there might be pending receiving data in the
closing side, and result in a TCP RST during closing. The TCP
RST may then cause the peer reading failure. For example:
<br>
1. client and server establish a TLS 1.3 connection.
<br>
2. server sending the post-handshake NewSessionTicket message.
<br>
3. client send the application data, and then close the
connection.
<br>
4. as the client does not call to read the post-handshake
message, the connection close will cause a TCP RST.
<br>
5. server trying to read the client application data, but the
socket may be impacted by the TCP RST, and the reading can fail.
<br>
<br>
It would not be an issue any more if the client could read the
post-handshake message, explicit or implicit.
<br>
<br>
I would like applications consider to use half-close policy, and
moving away from the duplex-close policy.
<br>
<br>
The basic idea of the fix is trying to use up buffered network
input before close the socket. As is an implicit behavior to
consume the post-handshake message, and mitigate the impact of
it.
<br>
<br>
This fix is not a perfect one. It is just a workaround for
duplex-close. I'm open to hear more ideas.
<br>
<br>
Thanks,
<br>
Xuelei
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>