<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Xuelei, mostly small stuff:<br>
<ul>
<li>SSLEngineImpl.java</li>
<ul>
<li>717: Nit, inbout --> inbound</li>
</ul>
<li>SSLEngineOutputRecord.java</li>
<ul>
<li>162<span class="new">, 169: Nit, applicatoin -->
application</span></li>
<li><span class="new">Same section: It looks like the "if" and
"else if" clauses take the same actions with the same
message. Maybe just do "if (isClosed())" ? Or were you
planning to have different messages here?<br>
</span></li>
</ul>
<li><span class="new">SSLSocketOutputRecord.java</span></li>
<ul>
<li><span class="new">58, 97, 204: Typo, closedd --> closed</span></li>
</ul>
<li>TLSEngineClosureTest.java</li>
<ul>
<li>2: Copyright date fix</li>
<li>26: If this is a new test should the bug ID be different
than 8085979?</li>
</ul>
</ul>
<p>--Jamil<br>
</p>
<br>
<div class="moz-cite-prefix">On 08/07/2018 07:46 AM, Xuelei Fan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com">New
webrev:
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/">http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/</a>
<br>
<br>
Thanks for a find of Tim Brooks, that the SSLEngine
inbound/outbound status is incorrect if closing during handshake.
The above webrev is trying to fix the problems. See more in the
OpenJDK thread:
<br>
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html">http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html</a>
<br>
<br>
Please let me know your concerns before this Wednesday.
<br>
<br>
Thanks,
<br>
Xuelei
<br>
<br>
On 8/3/2018 1:55 PM, Xuelei Fan wrote:
<br>
<blockquote type="cite">Update:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/">http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/</a>
<br>
<br>
In webrev.01, the socket close may be blocked by super class
close synchronization. Updated the SSLSocketImpl.java to use
handshake only lock in the startHandshake() implementation.
<br>
<br>
Thanks,
<br>
Xuelei
<br>
<br>
On 8/1/2018 7:27 PM, Xuelei Fan wrote:
<br>
<blockquote type="cite">Update:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/">http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/</a>
<br>
<br>
Integrated the fix for JDK-8208642, "Server initiated TLSv1.2
renegotiation fails if Java client allows TLSv1.3".
SSLHandshake.java is updated to use negotiated version so that
TLS 1.2 HelloRequest is acceptable in TLS 1.3 client side.
<br>
<br>
Thanks,
<br>
Xuelei
<br>
<br>
On 7/30/2018 10:24 AM, Xuelei Fan wrote:
<br>
<blockquote type="cite"><loop in net-dev as well>
<br>
Please let me know your concerns by the end of August 1st,
2018.
<br>
<br>
Thanks,
<br>
Xuelei
<br>
<br>
<br>
On 7/30/2018 9:59 AM, Xuelei Fan wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
Please review the update for the TLS 1.3 half-close and
synchronization implementation:
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/">http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/</a>
<br>
<br>
Unlike TLS 1.2 and prior versions, for TLS 1.3, the
close_notify is use to close the local write side and peer
read side only. After the close_notify get handles, the
local read side and peer write side may still be open.
<br>
<br>
In this update, if an application calls
SSLEngine.closeInbound/Outbound() or
SSLSocket.shutdownInput/Output(), half-close will be
used. For compatibility, if SSLSocket.close() get called,
a duplex close will be tried. In order to support duplex
close, JDK will use the user_canceled warning alert even
the handshake complete.
<br>
<br>
In practice, an application may only close outbound even
it is intended to close the inbound as well, or close the
connection completely. It works for TLS 1.2 and prior
versions. But no more for TLS 1.3 because of the
close_notify behavior change in the TLS 1.3
specification. The application may be hung and
dead-waiting for read/close. It could be solved by
closing the inbound explicitly. In order to mitigate the
impact, a new System Property is introduced,
"jdk.tls.acknowledgeCloseNotify" if source code update is
not available. If the System Property is set to "true",
if receiving the close_notify, a close_notify alert will
be responded. It is a countermeasure of the TLS 1.3
half-close issues.
<br>
<br>
Thanks,
<br>
Xuelei
<br>
<br>
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>