JDK-8237474 : Default SSLEngine should create in server role
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 8u261,11,15
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-01-17
  • Updated: 2020-06-11
  • Resolved: 2020-04-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 15 JDK 8
11.0.8-oracleFixed 13.0.4Fixed 14.0.2Fixed 15 b19Fixed 8u261Fixed
Related Reports
CSR :  
JDK-8238593 - Default SSLEngine should create in server role
Sub Tasks
JDK-8245077 :  
Release Note: Default SSLEngine Should Create in Server Role - Resolved
Description
JDK 8u231 will not successfully handshake with a server started with JDK 8u251. The following error message is observed on the 8u251
started member:

<Warning> (thread=PacketListenerBT, member=1):
TcpDatagramSocket{bind=MultiplexedServerSocket[addr=0.0.0.0/0.0.0.0,port=7574, subport=2]}, exception regarding peer /127.0.0.1:57475, SSLv2Hello is not enabled
Comments
Fix request (13u): Requesting backport to 13u for parity with 11u. The original change applies cleanly.
11-06-2020
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.8-oracle. I needed to resolve this. http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/003029.html I checked with Oracle, they downported the comments, too.
18-05-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/74384366ec1d User: coffeys Date: 2020-04-14 14:18:05 +0000
14-04-2020
In the TLS 1.3 re-org, I changed the default SSLEngine mode from 'server' to 'client'. I don't think it does matters because applications MUST call SSLEngine.setUseClientMode() before handshaking. The setUseClientMode() will set to use 'client' or 'server' mode explicitly. So, I thought the default mode should have no impact at all. However, there is a compatibility impact between TLS 1.3 8u backpourt and JDK releases without backport. Prasad made a good research that the default mode is the root cause. I could not believe it because application MUST call SSLEngine.setUseClientMode() explicitly, otherwise the handshaking cannot perform at all. But I did miss the point that setUseClientMode() may be not the 1st method called after SSLEngine get instantiated. For example, application can call getEnabledProtocols���() and then setEnabledProtocols ���(), and then call setUseClientMode(). The behavior of calling sequence setEnabledProtocols���()->setUseClientMode() is different from the calling sequence setUseClientMode()->setEnabledProtocols���(). As we noticed in other JCA/JCE APIs, the calling sequence plays tricky again here. It would be good if we could avoid the calling sequence trap in the future.
06-02-2020
JDK 8u231 will not successfully handshake with a server started with JDK 8u251. The following error message is observed on the 8u251 started member: <Warning> (thread=PacketListenerBT, member=1): TcpDatagramSocket{bind=MultiplexedServerSocket[addr=0.0.0.0/0.0.0.0,port=7574, subport=2]}, exception regarding peer /127.0.0.1:57475, SSLv2Hello is not enabled
29-01-2020