web-dev-qa-db-fra.com

JDK 11 Erreur SSL sur un certificat valide (fonctionnant dans les versions précédentes)

Le code suivant génère une erreur dans JDK 11:

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

L'erreur est:

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)

Cela fonctionnait dans n'importe quel JDK précédent (j'ai déjà testé 7, 8, 9 et 10). 

Le certificat semble valide car il est reconnu par les navigateurs ou par la plupart des tests SSL trouvés sur Internet.

J'ai essayé de désactiver le nom d'hôte en vérifiant, en désactivant cacerts, en ajoutant DigiCert au fichier cacerts sans aucune chance.

Cela ressemble à un bogue dans openJDK. Testé dans les versions 26, 27 et 28 (release candidate).

javasslopenssljava-securityjava-11
8
cocorossello

Le problème est actuellement résolu dans JDK 12 https://bugs.openjdk.Java.net/browse/JDK-8209965 et a été inclus dans ea-9.

Le backport vers JDK 11 a également été résolu https://bugs.openjdk.Java.net/browse/JDK-8210005 et sera inclus dans 11.0.3 (eta Q2 + 2019)

Vous trouverez quelques informations de base dans les commentaires ici https://github.com/openssl/openssl/pull/4463/files

TLS 1.3 ajoute un schéma pour que le serveur indique au client sa liste de groupes pris en charge dans le fichier Message EncryptedExtensions, mais aucun des messages pertinents les spécifications permettent l'envoi de supported_groups dans ServerHello.

Néanmoins (probablement en raison de la proximité avec l'extension "Ec_point_formats", autorisée dans ServerHello), plusieurs serveurs envoient cette extension dans le fichier ServerHello quand même. 

Jusqu'à la version 1.1.0 incluse, nous n'avons pas vérifié la présence d'extensions non autorisées, aussi, pour éviter une régression, nous devons autoriser cette extension dans le TLS 1.2 ServerHello également.

9
muttonUp

C'est maintenant résolu dans JDK 11.0.2, publié le 16 janvier 2019

0
cocorossello