Hi Alexey,
Thanks for working on this issue. Do you plan to fix it for JDK 15, the
current JDK reposiroty?
I need more time for evaluate the fix. For example, I'm not sure if we
could always throw InterruptedIOException to applications, even for
getSession().
Regards,
Xuelei
On 2/24/2020 7:58 AM, Alexey Bakhtin 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
