-
Bug
-
Resolution: Not an Issue
-
P3
-
8, 9, 10
-
x86_64
-
linux
FULL PRODUCT VERSION :
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux hades.workgroup 4.11.6-201.fc25.x86_64 #1 SMP Tue Jun 20 20:21:11 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
When the default Key Manager is used with the default of just a single keystore (set by system property javax.net.ssl.keyStore), and the JVM acts as a server for incoming HTTPS requests, and a client for outgoing HTTPS requests, both of which require two-way SSL, the JVM is incapable of completing the handshake for both incoming and outgoing connections.
The problem is in two methods of the class SunX509KeyManagerImpl:
- chooseServerAlias
- chooseClientAlias
Both end up selecting the first alias, rather than using some more complex selection criteria such as "extended key usage" extensions of the certificates.
Full details are available here:
https://github.com/maxant/jvm-two-way-ssl
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run a downstream / backend server which requires two-way SSL for incoming connections, for example: https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/Back.java
Build a server/client application which will accept incoming connections and then make outgoing connections to the above backend server, for example https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/Middle.java
Connect to the socket on the middle application above, with a test client, for example https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/Front.java
The end to end connection from Front over Middle to Back will not be possible, either failing during SSL Handshake of the front to middle or middle to back, depending upon the hashcode of the alias/certificate combination.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The end to end connection from front over middle to back work, and no exceptions occur.
ACTUAL -
SSL Exceptions occur and SSL handshakes fail.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
See
https://github.com/maxant/jvm-two-way-ssl/blob/master/unsuccessful_client.md
and
https://github.com/maxant/jvm-two-way-ssl/blob/master/unsuccessful_server.md
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
https://github.com/maxant/jvm-two-way-ssl/blob/master/src/test/java/SunX509KeyManagerImplTest.java
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Either make the application use one keystore per certificate, or patch the SunX509KeyManagerImpl, for example as shown here:
https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/PatchedSunX509KeyManagerImpl.java
A possible fix is here:
https://github.com/maxant/jvm-two-way-ssl/blob/master/SunX509KeyManagerImpl.patch
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux hades.workgroup 4.11.6-201.fc25.x86_64 #1 SMP Tue Jun 20 20:21:11 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
When the default Key Manager is used with the default of just a single keystore (set by system property javax.net.ssl.keyStore), and the JVM acts as a server for incoming HTTPS requests, and a client for outgoing HTTPS requests, both of which require two-way SSL, the JVM is incapable of completing the handshake for both incoming and outgoing connections.
The problem is in two methods of the class SunX509KeyManagerImpl:
- chooseServerAlias
- chooseClientAlias
Both end up selecting the first alias, rather than using some more complex selection criteria such as "extended key usage" extensions of the certificates.
Full details are available here:
https://github.com/maxant/jvm-two-way-ssl
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run a downstream / backend server which requires two-way SSL for incoming connections, for example: https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/Back.java
Build a server/client application which will accept incoming connections and then make outgoing connections to the above backend server, for example https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/Middle.java
Connect to the socket on the middle application above, with a test client, for example https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/Front.java
The end to end connection from Front over Middle to Back will not be possible, either failing during SSL Handshake of the front to middle or middle to back, depending upon the hashcode of the alias/certificate combination.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The end to end connection from front over middle to back work, and no exceptions occur.
ACTUAL -
SSL Exceptions occur and SSL handshakes fail.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
See
https://github.com/maxant/jvm-two-way-ssl/blob/master/unsuccessful_client.md
and
https://github.com/maxant/jvm-two-way-ssl/blob/master/unsuccessful_server.md
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
https://github.com/maxant/jvm-two-way-ssl/blob/master/src/test/java/SunX509KeyManagerImplTest.java
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Either make the application use one keystore per certificate, or patch the SunX509KeyManagerImpl, for example as shown here:
https://github.com/maxant/jvm-two-way-ssl/blob/master/src/main/java/PatchedSunX509KeyManagerImpl.java
A possible fix is here:
https://github.com/maxant/jvm-two-way-ssl/blob/master/SunX509KeyManagerImpl.patch
- relates to
-
JDK-8272875 Change the default key manager to PKIX
-
- Open
-