16

The following code throws an error in JDK 11:

    HttpURLConnection con = (HttpURLConnection) new URL("https://sis.redsys.es/sis/realizarPago").openConnection();
    con.setRequestMethod("GET");
    con.getResponseCode();

The error is:

javax.net.ssl.SSLHandshakeException: extension (10) should not be presented in server_hello
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:312)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:268)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at java.base/sun.security.ssl.SSLExtensions.<init>(SSLExtensions.java:71)
at java.base/sun.security.ssl.ServerHello$ServerHelloMessage.<init>(ServerHello.java:169)
at java.base/sun.security.ssl.ServerHello$ServerHelloConsumer.consume(ServerHello.java:860)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:390)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:445)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877)
at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383)
at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)

It was working in any previous JDK (I've tested in 7, 8, 9 and 10).

The certificate seems valid as it's recognized by browsers or most SSL test i've found in internet.

I've tried disabling host name verifying, disabling cacerts, adding the DigiCert to the cacerts file without any luck.

It seems like a bug in openJDK. Tested in build 26, 27 and 28 (release candidate).

cocorossello
  • 1,289
  • 1
  • 17
  • 30
  • 4
    This seems to be an issue of the server. Until now it was accepted by all clients, however OpenSSL and other have started to be more strict on what is allowed: https://mta.openssl.org/pipermail/openssl-dev/2017-October/009802.html – Robert Aug 25 '18 at 13:27
  • 1
    I understand, but there is no compatibility flag (I couldn't see anything in the source code). So there is no workaround other than waiting for them to fix their certificate (which could take very long) or to create a "proxy" server to bypass the certificate. This is preventing us from upgrading to java 11 and it is a widely used payment system in spain – cocorossello Aug 25 '18 at 13:48
  • 5
    It is not the certificate it is the server sending incorrect data in the SERVER_HELLO message. – Robert Aug 25 '18 at 14:52
  • Sorry, you are right. I'll write them, let's see if they can fix it. – cocorossello Aug 25 '18 at 15:14
  • 2
    https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8209982 – cocorossello Aug 27 '18 at 12:32
  • The build [`JDK12-ea-9` is out](http://jdk.java.net/12/), were you able to test if this was fixed? – Naman Sep 02 '18 at 12:46
  • Yes, I can confirm it works in jdk 12. I hope that the backport will make it into 11, anyway I made a workaround using nginx as a "SSL proxy" so I can use jdk 11 for now. – cocorossello Sep 04 '18 at 06:12
  • the irony here is that Tomcat is one of the servers with the "bad" implementation. – Eric Twilegar Jan 16 '19 at 22:49

2 Answers2

13

The issue is currently resolved in JDK 12 https://bugs.openjdk.java.net/browse/JDK-8209965, and was included in ea-9.

The backport to JDK 11 has also been resolved https://bugs.openjdk.java.net/browse/JDK-8210005 and is included in

  • 11.0.3 (Oracle JDK)
  • 11.0.2 (OpenJDK)

Some background to this can be found in the comments here https://github.com/openssl/openssl/pull/4463/files

TLS 1.3 adds a scheme for the server to indicate to the client its list of supported groups in the EncryptedExtensions message, but none of the relevant specifications permit sending supported_groups in the ServerHello.

Nonetheless (possibly due to the close proximity to the "ec_point_formats" extension, which is allowed in the ServerHello), there are several servers that send this extension in the ServerHello anyway.

Up to and including the 1.1.0 release, we did not check for the presence of nonpermitted extensions, so to avoid a regression, we must permit this extension in the TLS 1.2 ServerHello as well.

muttonUp
  • 6,351
  • 2
  • 42
  • 54
-1

It's now solved in JDK 11.0.2, released in 16th January 2019

cocorossello
  • 1,289
  • 1
  • 17
  • 30