Hi Alexey, Thanks for the update. I glossed over the changes.
Observation: I don’t see a regression test in your webrev, is this still a work in progress ? I am very surprised, how a simple socket feature such as this, escape the JSN-test dragnet in the first place ? Kumar On Feb 24, 2020, at 7:58 AM, Alexey Bakhtin <ale...@azul.com<mailto:ale...@azul.com>> wrote: Hello, I have been working on this issue for some time already. The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) Tested with JDK11 and higher. JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 Thank you, Alexey On 22 Feb 2020, at 15:00, security-dev-requ...@openjdk.java.net<mailto:security-dev-requ...@openjdk.java.net> wrote: I will look into the issue. BTW, I closed JDK-8239788 as duplicate of JDK-8239798. Thanks, Xuelei On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: Hi security-folk, At VMware while upgrading our application to OpenJDK11u, we have encountered what seems to be a serious behavior issue. The issue AFAICT seems to have stemmed from the work for TLS1.3 and JDK-8196584 <https://bugs.openjdk.java.net/browse/JDK-8196584>. Overview: With OpenJDK11 the end-points are closed immediately with TLS alerts raised when an exception is received. This is not the case with JDK8 the socket is not closed allowing retries. I have filed: JDK-8239798 (with a reproducer), this issue was also reported ?to Azul and they have filed: JDK-8239788. Can you please evaluate this at the earliest, this is a serious show stopper for VMware. Thank Kumar Srinivasan VMware
