<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Xuelei,<br>
<ul>
<li>SSLSocket.java</li>
<ul>
<li>134: Nit - You can remove the first "both" in this sentence
since you use it later with the input/output stream closure.<br>
</li>
</ul>
</ul>
Looks good to me otherwise.<br>
<br>
--Jamil<br>
<br>
<div class="moz-cite-prefix">On 8/13/2018 11:31 AM, Xue-Lei Fan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:aceef383-91e6-80c9-b40c-ed7444e89ec2@oracle.com">One
more update:
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/">http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/</a>
<br>
<br>
It is desired to make a note in SSLSocket and SSLEngine
specification, so that users have a good sense that an application
should close the input and output stream always.
<br>
<br>
Updated for SSLEngine.java and SSLSocket.java only. No changes in
other files.
<br>
<br>
Please let me know your concerns by the end of today.
<br>
<br>
Thanks,
<br>
Xuelei
<br>
<br>
On 8/10/2018 4:02 PM, Jamil Nimeh wrote:
<br>
<blockquote type="cite">I'm good with the changes.
<br>
<br>
--Jamil
<br>
<br>
On 8/7/2018 5:24 PM, Xuelei Fan wrote:
<br>
<blockquote type="cite">Hi Jamil,
<br>
<br>
Thanks for comments. Here is the updated webrev:
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/">http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/</a>
<br>
<br>
Thanks,
<br>
Xuelei
<br>
<br>
On 8/7/2018 3:12 PM, Jamil Nimeh wrote:
<br>
<blockquote type="cite">Hi Xuelei, mostly small stuff:
<br>
<br>
* SSLEngineImpl.java
<br>
o 717: Nit, inbout --> inbound
<br>
* SSLEngineOutputRecord.java
<br>
o 162, 169: Nit, applicatoin --> application
<br>
o Same section: It looks like the "if" and "else if"
clauses take
<br>
the same actions with the same message. Maybe just
do "if
<br>
(isClosed())" ? Or were you planning to have
different messages
<br>
here?
<br>
* SSLSocketOutputRecord.java
<br>
o 58, 97, 204: Typo, closedd --> closed
<br>
* TLSEngineClosureTest.java
<br>
o 2: Copyright date fix
<br>
o 26: If this is a new test should the bug ID be
different than
<br>
8085979?
<br>
<br>
--Jamil
<br>
<br>
<br>
On 08/07/2018 07:46 AM, Xuelei Fan wrote:
<br>
<blockquote type="cite">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>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>