Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/
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.
Thanks,
Xuelei
On 7/30/2018 10:24 AM, Xuelei Fan wrote:
<loop in net-dev as well>
Please let me know your concerns by the end of August 1st, 2018.
Thanks,
Xuelei
On 7/30/2018 9:59 AM, Xuelei Fan wrote:
Hi,
Please review the update for the TLS 1.3 half-close and
synchronization implementation:
http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/
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.
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.
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.
Thanks,
Xuelei
