Échec de la négociation SSL avec des erreurs de navigateur : ERR_SSL PROTOCOL_ERROR, ERR_SSL FALLBACK_BEYOND MINIMUM_VER
S'APPLIQUE À : Oracle HTTP Server, WebLogic et Fusion Middleware
Oracle HTTP Server - Version 10.1.2.0.0 et ultérieures
Weblogic Web Server - Version 9.2 et ultérieures
Oracle Fusion Middleware - Version 10.1.2.0.0 et ultérieures
Oracle WebLogic Server - Version 12.1.1.0 à 12.1.1.0 [Release 12c]
Les informations de ce document s'appliquent à toutes les plateformes.
SYMPTÔMES
Échec de la négociation SSL avec des erreurs de navigateur
Les erreurs sont ERR_SSL_PROTOCOL_ERROR, ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION, SSL_ERROR_NO_CYPHER_OVERLAP et ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY.
Lorsque les utilisateurs accèdent à une application en https://, elle ne fonctionne pas. L'erreur affichée dépend du navigateur et des problèmes qu'il détecte, mais découle généralement de la mise à jour vers une version plus récente du navigateur, qui cherche à garantir que vous accédez à des sites sécurisés :
-- Chrome affiche une erreur très répandue, car il contrôle la négociation du protocole :
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION (en cas de problème de négociation TLS)
"Server has a weak ephemeral Diffie-Hellman public key" (lorsqu'une suite de chiffrement DHE_EXPORT est activée sur le serveur, mais pas sur le client)
-- Firefox affiche un message de ce type, selon la version et l'application, plutôt lié aux suites de chiffrement utilisées lors de la négociation :
Advanced info: ssl_error_no_cypher_overlap ou ssl_error_weak_server_ephemeral_dh_key ou NS_ERROR_NET_RESET
-- Les navigateurs Microsoft affichent généralement "Page Cannot be Displayed"
-- Les clients Java peuvent rencontrer des problèmes semblables ; une tentative de connexion peut échouer avec l'erreur suivante :
javax.net.ssl.SSLException: Received fatal alert: illegal_parameter
-- Dans les journaux d'Oracle HTTP Server, on observe les erreurs suivantes :
SSL call to NZ function nzos_Handshake failed with error 29014
SSL call to NZ function nzos_Handshake failed with error 29049
SSL call to NZ function nzos_Handshake failed with error 28864
Les erreurs peuvent varier selon la version et le serveur HTTP utilisés. Le symptôme de base est l'échec de la négociation SSL, suivi de la fermeture de la connexion par le client.
Il faut alors examiner la configuration SSL côté serveur pour vérifier qu'elle permet bien une négociation sécurisée, comme prévu. Le problème peut dépendre du protocole ou de la suite de chiffrement utilisés.
CHANGEMENTS
Mise à jour du client
Les problèmes surviennent après la mise à jour des navigateurs clients (Chrome, Firefox, Internet Explorer, etc.). Ils apparaissent à la suite de diverses alertes de sécurité SSL visant les anciennes versions de protocole et les suites de chiffrement faibles, autrefois répandues, mais désormais dépréciées en raison de leur manque de sécurité. Cela peut aussi se produire lors d'une nouvelle installation ou d'une nouvelle configuration de SSL.
- Le point essentiel : cela fonctionne avec un ancien navigateur, mais échoue avec un navigateur plus récent (ou un autre client).
- Notez que les erreurs sont différentes et que chacune a donc sa propre cause profonde. La solution peut se résumer à mettre à jour les protocoles, les suites de chiffrement et les certificats selon les nouvelles normes SSL.
CAUSE
Le serveur implémente incorrectement la négociation
Au départ, le problème vient des protocoles SSLv2 et SSLv3. Les anciennes suites de chiffrement et les anciens certificats utilisés peuvent aggraver le problème.
Les navigateurs récents et les autres clients les désactivent : la première étape consiste à faire de même côté serveur. Une fois ces protocoles désactivés, il se peut que seul TLSv1 reste disponible sur votre serveur, selon votre version. Les clients récents préfèrent TLSv1.2 et 1.1 à 1.0, sans toutefois désactiver complètement ce dernier par défaut. Lorsque la négociation se rabat sur un protocole inférieur, les navigateurs peuvent détecter un problème et fermer la connexion.
Un problème survient souvent lorsque seul TLSv1 (1.0) est disponible sur les anciennes versions de serveur HTTP. On croit souvent qu'il faut désactiver TLS 1.0 et n'autoriser que TLS 1.1 et 1.2. Cela évite effectivement le problème, mais ce n'est pas tout à fait exact : il suffit de vous assurer que la tentative de négociation avec TLS 1.0 est sécurisée. Les anciens serveurs Web ont reçu des mises à jour à ce sujet au fil des ans, mais ce n'est que récemment que les éditeurs de clients détectent et bloquent ce problème de façon systématique.
Voir le message suivant de Google : https://code.google.com/p/chromium/issues/detail?id=498998
"nous allons maintenant supprimer également le repli (fallback) vers TLS 1.0, ce qui porte la version minimale de repli à TLS 1.1. Cela ne cassera *pas* les serveurs TLS 1.0, seulement ceux qui implémentent incorrectement la négociation de version."
D'autres problèmes sont liés à l'utilisation de suites de chiffrement faibles et de certificats à clé de faible longueur. Certains éditeurs de clients appliquent par défaut des règles qui détectent ces cas côté serveur et ferment la connexion. Vous pouvez aussi voir ces erreurs si vous vous limitez aux protocoles supérieurs sans disposer des suites de chiffrement ou des certificats pris en charge par ces protocoles.
L'erreur SSL_ERROR_NO_CYPHER_OVERLAP du navigateur peut indiquer que celui-ci ne prend pas en charge la suite de chiffrement du serveur distant. Par exemple, WLS est configuré avec TLS_RSA_WITH_AES_256_CBC_SHA256, mais le navigateur ne prend pas en charge cette suite de chiffrement. Pour que la connexion SSL réussisse, le client (navigateur) et le serveur doivent s'entendre sur une suite de chiffrement commune. Vous pouvez consulter les suites de chiffrement prises en charge par le navigateur à l'aide d'outils tiers, par exemple
https://cc.dcsec.uni-hannover.de/
https://www.ssllabs.com/ssltest/viewMyClient.html
SOLUTION : normes SSL
Plusieurs étapes
Si vous n'avez pas la maîtrise du serveur, on applique généralement des solutions de contournement, que l'on trouve sur Internet. Comme les lecteurs de ce document ont vraisemblablement la maîtrise de leurs serveurs, et que des utilisateurs vous signalent peut-être ces erreurs, vous devez prendre des mesures pour sécuriser vos serveurs selon les attentes par défaut des clients. L'objectif est de faire en sorte que votre serveur traite les connexions https de façon sécurisée, et non de contourner le problème par une astuce dans le navigateur qui autorise les anciennes normes SSL. Il faut d'abord désactiver SSLv2 et SSLv3 ; si vous utilisez une version où seul TLSv1 est configuré, un correctif doit être appliqué sur certaines versions pour implémenter correctement la négociation. Bien que la cause soit différente, les autres problèmes liés aux suites de chiffrement faibles peuvent être traités en même temps, car les étapes requises sont semblables.
Remarque :
Il n'est pas nécessaire de désactiver complètement TLS 1.0, et vous devez être très prudent avec les solutions de contournement qui annulent le contrôle de sécurité du navigateur. Une solution de contournement comme "security.tls.version.fallback-limit" ou "--ssl-version-fallback-min=tls1" contourne le contrôle de sécurité du navigateur et peut vous exposer à d'autres problèmes. Ces solutions de contournement ne sont pas une solution approuvée par Oracle pour ces erreurs.
Les problèmes de ce type ont évolué avec le temps ; la bonne démarche consiste à suivre les étapes une à une pour sécuriser votre système. Vous en avez peut-être déjà effectué certaines, mais pas toutes : vérifiez-les donc toutes. Vous assurerez ainsi une compatibilité complète entre les composants installés et les clients pour les nouvelles normes SSL/TLS.
- Le nouveau document suivant a été créé pour éviter ce type de problème : Note 2131521.1 Proactively Updating SSL Protocols, Ciphers, and Certificates for Oracle Fusion Middleware
Pour résoudre ces problèmes et sécuriser votre système avec les normes SSL les plus récentes possible, suivez les étapes ci-dessous :
1. Assurez-vous d'utiliser une version du produit qui bénéficie du support complet de correction d'erreurs (Error Correction Support) :
- Si votre version ne bénéficie pas du support complet de correction d'erreurs, vous risquez d'être limité pour obtenir de nouveaux correctifs et du support pour les configurations requises par les nouvelles normes.
- Voir : Note 944866.1 Error Correction Support Dates for Oracle Fusion Middleware (10g/11g/12c/WLS)
- Si vous ne pouvez pas faire la mise à jour, vous pouvez tout de même effectuer la plupart des configurations indiquées ci-dessous. Une section présente d'anciens correctifs connus pour résoudre les anciens problèmes de négociation TLS 1.0.
2. Désactivez SSLv3 et SSLv2 :
- Si vous n'avez pas désactivé les protocoles SSL 2.2/3.0 (SSLv2/SSLv3), il est probable que les navigateurs les détectent et bloquent ces connexions.
- Vous devez tenir compte d'Oracle HTTP Server, d'Oracle Web Cache, d'Oracle WebLogic Server et des autres composants Oracle Fusion Middleware installés.
- Voir : Note 1936300.1 How to Change SSL Protocols (to Disable SSL 3.0) in Oracle Fusion Middleware Products
3. Activez JSSE sur WebLogic Server :
- L'ancienne implémentation Certicom est dépréciée, mais vous devez configurer JSSE manuellement :
- Voir http://docs.oracle.com/cd/E23943_01/web.1111/e13707/ssl.htm#SECMG494
- C'est possible à partir de la version 10.3.3, mais idéalement en 10.3.6, pour une compatibilité complète entre toutes ces étapes.
4. Mettez à jour le JDK vers la dernière version de Java 6 ou 7, selon ce qui est certifié ; cela touche les protocoles, les suites de chiffrement et la longueur de clé pris en charge par défaut dans WLS :
- Voir la Note 1492980.1 How to Maintain the Java SE Installed or Used with FMW 11g/12c Products
- Java 7 permet la prise en charge de TLS 1.1 et 1.2, mais son utilisation n'est pas obligatoire ; utilisez le dernier JDK 6 selon les certifications
- Le dernier JDK corrige les problèmes de négociation TLS 1.0, supprime les suites de chiffrement faibles et résout l'erreur ssl_error_weak_server_ephemeral_dh_key
5. Supprimez les suites de chiffrement faibles :
- Pour WLS, c'est automatique avec la mise à jour du JDK. Si elles ont été configurées manuellement auparavant, la configuration peut maintenant être incorrecte : vérifiez-la dans toutes vos installations.
- Voir : Note 1067411.1 How To Disable Anonymous and Weak Cipher Suites in WebLogic Server
- Autrement dit, si vous mettez à jour le JDK et activez JSSE, vous n'avez pas besoin de modifier le config.xml pour utiliser une seule suite de chiffrement
- Pour les autres produits, voir la Note 453079.1 Restricting Anonymous or Weak Ciphers in SSL (HTTPS) for Oracle Fusion Middleware 10g/11g/12c
6. Portez la longueur de clé des certificats au-delà de 1024 :
- C'est nécessaire si vous obtenez l'erreur ssl_error_weak_server_cert_key. Assurez-vous d'avoir d'abord mis à jour le JDK.
- Voir la Note 1607170.1 SSL Authentication Problem Using WebLogic 10.3.6 and 12.1.1 With JDK1.7.0_40 or Higher, JDK1.6.0_101, JRockit R28.3.7
Vous aurez peut-être besoin de SHA2 et d'une longueur de clé supérieure à 1024 :
Note 2098479.1 SSL Connections Fail to OHS 11.1.1.9 When Using IE and TLS 1.1/1.2 Only
7. Appliquez le dernier PSU à Weblogic Server :
- Les PSU sont publiés dans le cadre du programme Critical Patch Update pour fournir des correctifs de sécurité ; consultez le document suivant sur le programme et la façon d'obtenir le plus récent :
- Note 1306505.1 Announcing Oracle WebLogic Server PSUs (Patch Set Updates)
8. Appliquez les correctifs CPU à vos autres produits :
- Note 551453.1 How to Find the Correct Critical Patch Update Patches for Oracle Fusion Middleware Products
- Les correctifs CPU de FMW contiennent des corrections de problèmes SSL, notamment des mises à jour des protocoles et des suites de chiffrement
- Pour Oracle HTTP Server, veillez à récupérer les correctifs OHS, OPMN et "SSL/Networking"
- Si votre version ne bénéficie plus de l'Error Correction Support, consultez la section ci-dessous pour les anciens correctifs connus pour résoudre les anciens problèmes de négociation TLS 1.0
9. Si les problèmes persistent, vous avez au moins l'assurance de disposer des dernières mises à jour, ce qui vous rend le plus compatible possible avec les nouvelles versions des clients. Selon l'erreur obtenue, vous pouvez diagnostiquer la négociation SSL avec des outils tiers, comme ceux offerts sur wireshark.org. Il s'agit de déterminer ce que le client attend et que le serveur ne fournit pas, et s'il existe une configuration permettant de répondre à cette exigence.
Appliquer les correctifs de négociation TLS 1.0 aux anciennes versions
Comme indiqué plus haut, ces problèmes ont commencé avec d'anciennes versions des produits serveur et l'utilisation d'anciens protocoles, aggravés par la présence d'anciennes suites de chiffrement et d'anciens certificats. La première étape consiste à ajuster le protocole et à s'assurer que la négociation SSL est correcte. Les anciennes versions des produits serveur (de tous les éditeurs) utilisaient une ancienne méthode de négociation non sécurisée. Voici les mises à jour pour les produits Oracle.
Avis : l'absence d'une version dans cette liste ne permet de rien conclure. Oracle recommande fortement d'appliquer le dernier Patch Set de vos produits afin de bénéficier de toutes les corrections cumulatives, puis de suivre le programme CPU pour vous protéger contre les vulnérabilités. Si le problème persiste après la mise à jour d'une version toujours couverte par l'Error Correction Support, ouvrez une demande de service (Service Request) pour qu'une analyse soit effectuée et qu'un nouveau défaut soit éventuellement ouvert. TLS 1.0 doit fonctionner et implémenter correctement la négociation sur toutes les versions couvertes par le Premier Support et l'Extended Support avec correction d'erreurs. Les anciennes versions ont été corrigées par le passé, mais ne font pas l'objet de vérifications continues pour les nouveaux problèmes.
Oracle HTTP Server 10g :
11.1.1.3 : Patch 11716938 et Patch 10387726
11.1.1.2 : Patch 11716930 et Patch 10387726
10.1.3.5 :
- Appliquez le Patch Set 10.1.3.5, Patch 8626084 (voir la Note 397022.1)
- Appliquez la version mise à jour d'OPatch, Patch 6880880, en choisissant 10.1.0.0.0
- Consultez http://www.oracle.com/technetwork/topics/security/alerts-086861.html pour trouver le dernier avis (Advisory), ouvrez-le et cliquez sur le lien "Fusion Middleware" qu'il contient pour trouver le dernier Patch Availability Document cumulatif et, dans celui-ci, une section 10.1.3.5.x. Notez que si vous utilisez EBS, l'avis contient un document distinct avec des instructions propres à EBS.
10.1.2.3 et 10.1.4.3 :
- Voir la Note 405972.1 - Oracle Application Server 10g Examples for Critical Patch Updates
- Consultez la section 10.1.2 ou 10.1.4 pour les étapes exactes, qui comprennent des consignes sur les Patch Sets, à appliquer à un Oracle home à la fois
- C'est le "Primary CPU Bundle" qui est requis après les prérequis Patch Set et OPatch
Oracle WebLogic Server :
9.2 - 10.3.2 : Appliquez le Patch 9412909 - Disallow SSL renegotiation
WLS Plugins 1.0 : Patch 11845433
Java SE :
JDK 6 Update 19 ou ultérieure
JDK 5.0 Update 24 ou ultérieure
JDK 1.4.2 Update 26 ou ultérieure
Référence :
Note 1301699.1 How the SSL/TLS Renegotiation Protocol Change Affects Oracle HTTP Server and Oracle WebLogic Server