Comment désactiver les suites de chiffrement anonymes et faibles dans Oracle WebLogic Server
S'APPLIQUE À :
Oracle Fusion Middleware - Version 11.1.1.2.0 et suivantes
Oracle WebLogic Server - Version 8.1 et suivantes
Les informations de ce document s'appliquent à toutes les plateformes.
- Ce document s'applique à toutes les versions ; toutefois, les versions plus récentes ont de nouvelles valeurs par défaut qui éliminent les chiffrements faibles et anonymes utilisés auparavant.
OBJECTIF
Cet article présente les étapes pour désactiver les suites de chiffrement SSL anonymes et faibles dans Oracle WebLogic Server. On entend par faibles les chiffrements d'une force inférieure à 128 bits ou ceux qui se sont révélés vulnérables à des attaques. Des rapports d'analyse peuvent signaler "SSL Server Allows Anonymous Authentication Vulnerability" ou "SSL Server Allows Weak Ciphers", ou des clients peuvent renvoyer les erreurs ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY, sl_error_weak_server_ephemeral_dh_key ou ssl_error_no_cypher_overlap.
La réponse rapide consiste généralement à mettre à jour le JDK utilisé par WebLogic Server, soit avec le dernier JDK 6, soit avec le dernier JDK 7. Mais d'autres éléments sont à prendre en compte.
En suivant les recommandations d'Oracle pour les différents composants, voici le résumé des étapes à réaliser conjointement :
1. Désactivez SSLv3
- Voir Note 1936300.1 How to Change SSL Protocols (to Disable SSL 3.0) in Oracle Fusion Middleware Products
2. Appliquez le dernier PSU
- Voir Note 1306505.1 Announcing Oracle WebLogic Server PSUs (Patch Set Updates)
3. Activez JSSE en 10.3.6
- Voir http://docs.oracle.com/cd/E23943_01/web.1111/e13707/ssl.htm#SECMG494
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 chiffrements et la force de clé pris en charge)
- Voir Note 1492980.1 How to Maintain the Java SE Installed or Used with FMW 11g/12c Products
5. Supprimez les chiffrements faibles (automatique avec la mise à jour du JDK ; s'ils ont été configurés manuellement auparavant, ils peuvent désormais être incorrects)
- Voir les explications dans le Doc ID 1067411.1
6. Au besoin, portez la force de clé du certificat au-delà de 1024
- Voir Note 1607170.1 SSL Authentication Problem Using WebLogic 10.3.6 and 12.1.1 With JDK1.7.0_40 or Higher and JRockit R28.3.7
- Mettez à jour les certificats de démonstration à l'aide de la Note 2097194.1 Impact of Jan 19, 2016 JDK CPU Updates on SSL/TLS and WLS 10.3.6 Demo Certificates - WLS 10.3.6 w/SSL
SOLUTION
Quels chiffrements sont utilisés par défaut ?
Plusieurs facteurs déterminent les chiffrements utilisés dans une connexion SSL. Côté serveur, cela dépend d'abord de la version de WLS, de l'activation ou non de JSSE (par opposition à Certicom) et de la version du JDK utilisée. Les différentes versions du JDK autorisent des suites de chiffrement différentes, en raison de l'évolution des normes de l'industrie. Vous pouvez en outre installer Java Cryptography Extension (JCE) pour obtenir la force maximale (par exemple, tout en 256 bits). Si le JDK est une version encore prise en charge, le maintenir à la dernière mise à jour _xx (chaque version peut apporter des changements précis) supprime les anciens chiffrements anonymes/null et n'utilise que des chiffrements de 128 bits ou plus, reconnus par l'industrie. Tous ces facteurs influencent la liste des chiffrements disponibles côté serveur. À partir de cette liste, le chiffrement est négocié avec le client qui demande la connexion (et qui a sa propre liste de chiffrements pris en charge) lors de la négociation SSL (handshake). C'est cette négociation qui détermine en dernier ressort le chiffrement réellement utilisé.
WLS peut être configuré (par exemple dans config.xml) pour des chiffrements précis, mais on ne le fait normalement que pour imposer explicitement un ou quelques chiffrements, parce que vous savez ce que le client accepte (il peut aussi s'agir de connexions internes ou provenant d'autres serveurs), ou parce que des exigences d'affaires imposent, pour une raison ou une autre, cette liste restreinte. Les chiffrements sont parfois configurés manuellement parce que JSSE n'est pas activé et que le JDK n'est pas mis à jour (volontairement ou non). Si vous décidez d'exercer un contrôle plus fin sur la liste des chiffrements pris en charge par le serveur, vous pouvez la configurer manuellement après avoir vérifié que tous les clients potentiels les acceptent aussi ; sinon, des erreurs de négociation (handshake) se produiront.
Avertissement de compatibilité
L'ajout de chiffrements personnalisés peut perturber le fonctionnement de composants internes. Soyez très prudent et testez vos applications ainsi que les applications fournies par Oracle. En règle générale, il n'est pas conseillé de modifier les chiffrements par défaut avant d'avoir mis à jour WLS et le JDK, activé JSSE et appliqué les correctifs CPU/PSU. Toutes ces actions influent sur les chiffrements par défaut et les chiffrements disponibles, et corrigent des failles de sécurité connues. Les produits Fusion Middleware intégrés disposent de correctifs CPU qui mettent à jour les chiffrements qu'ils acceptent.
Remarques :
·
o Si, après avoir appliqué les correctifs CPU/PSU disponibles pour votre version, vous constatez l'utilisation d'un chiffrement ancien, faible ou non sécurisé, assurez-vous qu'une SR et un bogue sont ouverts pour le composant afin de demander une mise à jour des valeurs par défaut et/ou des indications sur la façon de le désactiver.
o Si vous cherchez des informations sur les protocoles SSL à harmoniser avec vos exigences de chiffrement, consultez la Note 1936300.1, "How to Change SSL Protocols (to Disable SSL 3.0) in Oracle Fusion Middleware Products".
Désactiver les suites de chiffrement anonymes et faibles dans Oracle WebLogic Server
La première étape consiste à modifier la suite de chiffrement par défaut afin d'obtenir la meilleure sécurité et le meilleur fonctionnement possibles pour votre serveur, en activant JSSE et en mettant à jour votre JDK (Note 1492980.1). Vous trouverez ci-dessous des explications pour chaque version :
Dans WLS 10.3.6, les chiffrements peuvent être configurés au moyen d'un paramètre JAVA_OPTIONS ou dans le fichier config.xml (voir la section suivante), mais d'autres considérations importantes s'appliquent lorsque vous maintenez cette version pour d'autres raisons :
L'implémentation SSL d'origine de Certicom est dépréciée au profit de JSSE, qui utilise des chiffrements plus récents et permet d'employer des chiffrements plus forts que Certicom. Pour la liste des suites de chiffrement autorisées avec Certicom et JSSE, et la façon de les configurer, consultez 10.3.6 Ciphers dans la documentation Oracle. Il est préférable d'activer JSSE avant d'effectuer des personnalisations. Si vous activez JSSE plus tard, vous devrez refaire vos tests pour des raisons de gestion du changement.
WLS 10.3.x est livré avec le JDK 1.6, qui ne désactive pas les algorithmes plus faibles, inférieurs à 128 bits. Cette fonctionnalité est apparue avec le JDK 1.7 Update 40. Le JDK 1.7 est pris en charge avec WLS 10.3.6 : c'est donc une option pour éliminer les algorithmes plus faibles, au chiffrement moins robuste. Si vous mettez à jour le JDK plus tard, vous devrez refaire vos tests pour des raisons de gestion du changement. Voir Note 1492980.1 - "How to Maintain the Java SE Installed or Used with FMW 11g/12c Products". Mettre à jour régulièrement votre JDK vous garantit les valeurs par défaut les plus récentes pour les protocoles SSL et les chiffrements.
Pour que le Node Manager puisse utiliser des chiffrements plus forts, WebLogic Server doit être au moins en version 10.3.6.0.10 (PSU livré initialement en janvier 2015).
Jusqu'à votre mise à niveau vers la 12c, il est recommandé d'être en version 10.3.6, d'appliquer le dernier PSU 10.3.6.0.10 (ou plus récent), d'activer JSSE et, si c'est certifié pour vos autres produits et applications, d'utiliser le dernier JDK 7 Update 40 (ou plus récent). Notez que tous les produits FMW ne sont pas certifiés avec le JDK 7, mais que le dernier JDK 6 peut être appliqué. Si des chiffrements indésirables posent encore problème, signalez-le à l'équipe de développement WLS et à Oracle Security afin de déterminer la meilleure marche à suivre. Si vous êtes certain que tous les clients SSL concernés peuvent utiliser un chiffrement donné, vous pouvez le configurer comme documenté. Notez que les "clients SSL" peuvent comprendre vos clients attendus, d'autres produits Oracle ou des composants FMW internes installés dans votre environnement.
Dans les versions WLS 12c, les recommandations rejoignent celles indiquées ci-dessus pour WLS 10.3.6 et plus, mais JSSE est activé par défaut. Consultez 12c Ciphers dans la documentation Oracle pour les mises à jour. Pour que le Node Manager puisse utiliser des chiffrements plus forts, WebLogic Server doit être au moins en version 12.1.1.0.10, 12.1.2.0.4 ou 12.1.3.0.2 (PSU livrés initialement en janvier 2015 pour les versions bénéficiant du support de correction d'erreurs). Par défaut, vous ne devriez pas avoir à modifier les chiffrements pour éliminer les chiffrements null ou inférieurs à 128 bits, mais vous pouvez utiliser JAVA_OPTIONS ou le fichier config.xml pour personnaliser les chiffrements. Prenez soin de recenser tous les chiffrements pris en charge par les clients, sachant que ces clients peuvent être d'autres processus middleware.
Important :
- Les versions récentes de Java désactivent par défaut les chiffrements anciens et faibles. Voir la Note 1492980.1 pour les emplacements de téléchargement et les étapes de mise à jour.
- Les chiffrements RC4 forment une suite de chiffrements qui a été supprimée. Voir les notes de version du JDK 1.7.0_85 et du JDK 1.6.0_101. Si vous avez configuré explicitement WLS avec des chiffrements comme TLS_RSA_WITH_RC4_128_SHA ou TLS_RSA_WITH_RC4_128_MD5 (très populaires par le passé), des erreurs peuvent apparaître après la mise à jour du JDK :
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
javax.net.ssl.SSLException: Received fatal alert: handshake_failure
Vous devez alors retirer ces chiffrements de votre configuration et configurer un nouveau chiffrement conformément à la documentation WLS de votre version. Si vous utilisez une version récente de WLS qui prend en charge la version récente du JDK et que JSSE est activé, vous ne devriez pas avoir à configurer explicitement les chiffrements (par exemple dans config.xml), à moins que vos exigences d'affaires n'imposent des paramètres plus précis.
Configurer les chiffrements manuellement ou explicitement
Selon votre version, vos décisions d'affaires et vos autres exigences, vous pourriez avoir besoin de configurer explicitement un chiffrement ou une liste de chiffrements. Vous pouvez, et devriez, désactiver explicitement les chiffrements qui permettent une communication en texte clair. Le serveur autorise la communication en texte clair soit parce qu'aucune suite de chiffrement forte n'est indiquée, soit parce que des suites de chiffrement null sont indiquées. Pour empêcher les communications en texte clair, évitez les chiffrements comme TLS_RSA_WITH_NULL_MD5 et TLS_RSA_WITH_NULL_SHA, dont la force de clé symétrique est de 0. Consultez la documentation Oracle propre à votre version pour connaître les chiffrements pris en charge.
Sur les anciennes versions 10.3 sans mise à jour récente du JDK, si aucune suite de chiffrement n'est explicitement indiquée dans le fichier config.xml, les suites de chiffrement permettant une communication en texte clair peuvent être activées. Pour désactiver ces suites de chiffrement en texte clair, définissez les options suivantes dans JAVA_OPTIONS au démarrage :
-Dweblogic.security.disableNullCipher=true
-Dweblogic.security.SSL.allowUnencryptedNullCipher=false
Pour toutes les versions, vous pouvez aussi configurer dans le fichier config.xml du domaine la suite de chiffrement que vous souhaitez utiliser. Pour indiquer une suite de chiffrement, ajoutez les attributs ci-dessous et indiquez les suites de chiffrement voulues (prises en charge par les deux côtés de la communication pour établir la négociation) :
Par exemple :
Dans WLS 10.3.x et 12c, vous pouvez ajouter la balise dans le fichier config.xml avec les chiffrements que vous souhaitez utiliser :
Assurez-vous qu'elle est ajoutée avant la balise, comme ci-dessous, pour les serveurs d'administration et les serveurs gérés :
AdminServer
true
enter_a_cipher_of_your_choice_here
enter_another_optional_cipher_of_your_choice_here
7002
25000
...
Il se peut que votre Admin Server ait un paramètre à "false" en raison de cette documentation. La modification se fait de la même façon, généralement uniquement parce qu'un outil détecte un chiffrement indésirable.
Dans WLS 9.x et plus, définissez dans le fichier config.xml les chiffrements souhaités, pris en charge par cette version et par le JDK utilisé :
Entre AdminServer et, ajoutez
true
enter_a_cipher_of_your_choice_here
enter_another_optional_cipher_of_your_choice_here
Dans WLS 8.1, définissez-le dans le fichier config.xml en utilisant des chiffrements pris en charge par cette version et par le JDK utilisé :
Ciphersuites="enter_comma_delimited_cipher_list_here"
Remarque : l'objectif doit être de configurer un chiffrement de votre choix, pris en charge selon la documentation Oracle et par tous les clients qui se connectent, et qui ne soit ni null, ni anonyme, ni inférieur à 128 bits. La configuration de chiffrements personnalisés peut produire des résultats imprévisibles entre les différents composants. Suivez bien la documentation et prévoyez le temps nécessaire pour tester l'ensemble de votre environnement. Suivez toujours le programme Critical Patch Update (CPU) en ce qui concerne les vulnérabilités de sécurité. Si vous suivez le programme CPU pour des versions bénéficiant du support de correction d'erreurs (Error Correction Support), vous n'aurez peut-être pas besoin de configurer explicitement les chiffrements, à moins que d'autres exigences d'affaires ne l'imposent.
Force de clé du certificat supérieure à 1024
Vous pourriez devoir porter la force de clé de votre certificat au-delà de 1024. Les versions récentes du JDK imposent cette limite ; voir :
Note 1607170.1 SSL Authentication Problem Using WebLogic 10.3.6 and 12.1.1 With JDK1.7.0_40 or Higher and JRockit R28.3.7
Note 2097194.1 Impact of Jan 19, 2016 JDK CPU Updates on SSL/TLS and WLS 10.3.6 Demo Certificates - WLS 10.3.6 w/SSL
SHA-256
Dans le même ordre d'idées, et en prévision de l'avenir, la norme de l'industrie évolue vers SHA2. Consultez la note suivante pour connaître l'état de la prise en charge de SHA2 dans les produits Oracle Fusion Middleware :
Note 1275428.1 Support Status for SHA2 in Oracle Fusion Middleware 11g/12c (including Weblogic Server) and Oracle Application Server 10g (10.1.2/10.1.3/10.1.4)
Node Manager
Pour que le Node Manager puisse utiliser des chiffrements plus forts, WebLogic Server doit être au moins en version 10.3.6.0.10, 12.1.2.0.4 ou 12.1.3.0.3 (versions PSU livrées début 2015 ; voir la Note 1470197.1 pour les plus récentes). Le fichier nodemanager.properties peut servir à personnaliser les chiffrements, mais cela ne fonctionnera pas correctement avec le Node Manager si les PSU ne sont pas appliqués. Une fois le PSU appliqué et le JDK mis à jour, il est recommandé de laisser le traitement par défaut s'appliquer. Soyez prudent si vous définissez ce paramètre manuellement. Vous devrez recenser tous les chiffrements pris en charge avec lesquels le Node Manager devra négocier, sachant qu'il peut s'agir d'autres processus middleware internes. Par défaut, si vous mettez à jour le JDK et appliquez les PSU, vous ne devriez pas avoir à modifier les chiffrements pour éliminer les chiffrements null, inférieurs à 128 bits, faibles ou vulnérables. Cette configuration n'est pas recommandée, sauf si une exigence d'affaires stricte impose de n'utiliser qu'un seul chiffrement, comme ci-dessous :
Dans le fichier nodemanager.properties
CipherSuite=enter_a_cipher_of_your_choice_here
Remarque :
a) Le chiffrement choisi doit commencer par SSL_ (même si vous utilisez TLS) et doit être compatible avec les autres entités qui ont besoin d'une connexion (par exemple d'autres outils et composants Fusion Middleware)
b) Vous ne pouvez configurer qu'un chiffrement pris en charge par le JDK installé (et certifié avec WLS) :
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
https://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
c) Vérifiez les autres paramètres JAVA_OPTION que vous auriez configurés auparavant et qui pourraient entrer en conflit avec celui-ci.