10.2. Crypto-politiques, composants cryptographiques de base RHEL et protocoles
Poursuite de la dépréciation de SHA-1
Dans RHEL 9, l'utilisation de SHA-1 pour les signatures est restreinte dans la stratégie cryptographique DEFAULT applicable à l'ensemble du système. À l'exception de HMAC, SHA-1 n'est plus autorisé dans les protocoles TLS, DTLS, SSH, IKEv2, DNSSEC et Kerberos. Les applications individuelles qui ne sont pas contrôlées par les politiques cryptographiques de l'ensemble du système RHEL abandonnent également l'utilisation des hachages SHA-1 dans RHEL 9.
Si votre scénario nécessite l'utilisation de SHA-1 pour la vérification des signatures cryptographiques existantes ou de tiers, vous pouvez l'activer en entrant la commande suivante :
# update-crypto-policies --set DEFAULT:SHA1
Vous pouvez également basculer les stratégies cryptographiques du système vers la stratégie LEGACY. Notez que LEGACY active également de nombreux autres algorithmes qui ne sont pas sécurisés. Pour plus d'informations, consultez la section Réactivation de SHA-1 dans le document de renforcement de la sécurité de RHEL 9.
Pour résoudre les problèmes de compatibilité avec les systèmes qui requièrent encore SHA-1, voir les articles KCS suivants :
- SSH ne fonctionne pas entre les systèmes RHEL 9 et RHEL 6
- Les paquets signés avec SHA-1 ne peuvent pas être installés ou mis à niveau
- Échec de la connexion avec les serveurs et clients SSH qui ne prennent pas en charge l'extension "server-sig-algs"
- Les enregistrements DNSSEC signés avec RSASHA1 ne sont pas vérifiés
Algorithmes désactivés à tous les niveaux de la politique
Les algorithmes suivants sont désactivés dans les politiques cryptographiques LEGACY, DEFAULT et FUTURE fournies avec RHEL 9 :
- TLS antérieur à la version 1.2 (depuis RHEL 9, était < 1.0 dans RHEL 8)
- DTLS antérieur à la version 1.2 (depuis RHEL 9, était < 1.0 dans RHEL 8)
- DH avec les paramètres < 2048 bits (depuis RHEL 9, était < 1024 bits dans RHEL 8)
- RSA avec une taille de clé de < 2048 bits (depuis RHEL 9, était < 1024 bits dans RHEL 8)
- DSA (depuis RHEL 9, était < 1024 bits dans RHEL 8)
- 3DES (depuis RHEL 9)
- RC4 (depuis RHEL 9)
- FFDHE-1024 (depuis RHEL 9)
- DHE-DSS (depuis RHEL 9)
- Camellia (depuis RHEL 9)
- ARIA
- SEED
- IDEA
- Suites de chiffrement à intégrité seule
- Suites de chiffrement TLS en mode CBC utilisant SHA-384 HMAC
- AES-CCM8
- Toutes les courbes ECC incompatibles avec TLS 1.3, y compris secp256k1
- IKEv1 (depuis RHEL 8)
- NSEC3DSA dans la configuration BIND (depuis RHEL 9.2)
Si votre scénario nécessite une politique qui a été désactivée, vous pouvez l'activer en appliquant une politique cryptographique personnalisée ou en configurant explicitement des applications individuelles, mais la configuration résultante ne sera pas prise en charge.
Changements apportés à TLS
Dans RHEL 9, la configuration de TLS est effectuée à l'aide du mécanisme de politiques cryptographiques à l'échelle du système. Les versions de TLS inférieures à 1.2 ne sont plus prises en charge. DEFAULT les politiques cryptographiques de RHEL 9, FUTURE et LEGACY n'autorisent que TLS 1.2 et 1.3. Pour plus d'informations, voir Utilisation des politiques cryptographiques à l'échelle du système.
Les paramètres par défaut fournis par les bibliothèques incluses dans RHEL 9 sont suffisamment sûrs pour la plupart des déploiements. Les implémentations TLS utilisent des algorithmes sécurisés dans la mesure du possible, tout en n'empêchant pas les connexions depuis ou vers les clients ou serveurs existants. Appliquez des paramètres renforcés dans les environnements soumis à des exigences de sécurité strictes, où les clients ou serveurs existants qui ne prennent pas en charge les algorithmes ou protocoles sécurisés ne sont pas censés se connecter ou ne sont pas autorisés à le faire.
SCP non pris en charge dans RHEL 9
Le protocole de copie sécurisée (SCP) n'est plus pris en charge car il est difficile à sécuriser. Il a déjà causé des problèmes de sécurité, par exemple CVE-2020-15778. Dans RHEL 9, SCP est remplacé par le protocole de transfert de fichiers SSH (SFTP) par défaut.
Par défaut, SSH ne peut pas se connecter depuis des systèmes RHEL 9 vers des systèmes plus anciens (par exemple, RHEL 6) ou depuis des systèmes plus anciens vers RHEL 9, car les algorithmes cryptographiques utilisés dans les anciennes versions ne sont plus considérés comme sûrs. Si votre scénario nécessite une connexion avec des systèmes plus anciens, vous pouvez soit utiliser les algorithmes ECDSA et ECDH comme clés sur le système hérité, soit utiliser la stratégie cryptographique héritée sur le système RHEL 9. Pour plus de détails, consultez les solutions SSH from RHEL 9 to RHEL 6 systems does not work et Failed connection with SSH servers and clients that do not support the server-sig-algs extension.
La connexion par mot de passe de la racine d'OpenSSH est désactivée par défaut
La configuration par défaut d'OpenSSH dans RHEL 9 interdit aux utilisateurs de se connecter en tant que root avec un mot de passe afin d'empêcher les pirates d'obtenir un accès par des attaques par force brute sur les mots de passe.
GnuTLS ne supporte plus TPM 1.2
La bibliothèque GnuTLS ne prend plus en charge la technologie Trusted Platform Module (TPM) 1.2. Vos applications utilisant le TPM via l'API GnuTLS doivent prendre en charge le TPM 2.0.
Le support de GnuTLS pour GOST a été supprimé
Dans RHEL 8, les algorithmes de chiffrement GOST ont été désactivés par le biais des politiques cryptographiques du système. Dans RHEL 9, la prise en charge de ces algorithmes de chiffrement a été supprimée de la bibliothèque GnuTLS.
cyrus-sasl utilise désormais GDBM au lieu de Berkeley DB
Le paquetage cyrus-sasl est maintenant construit sans la dépendance libdb, et le plugin sasldb utilise le format de base de données GDBM au lieu de Berkeley DB. Pour migrer vos bases de données SASL (Simple Authentication and Security Layer) existantes stockées dans l'ancien format Berkeley DB, utilisez l'outil cyrusbdb2current avec la syntaxe suivante :
cyrusbdb2current <sasldb_path> <new_path>
NSS ne prend plus en charge la DBM et les valeurs par défaut de pk12util ont été modifiées
Les bibliothèques Network Security Services (NSS) ne prennent plus en charge le format de fichier DBM pour la base de données de confiance. Dans RHEL 8, le format de fichier SQLite est devenu le format par défaut, et les bases de données DBM existantes ont été ouvertes en mode lecture seule et automatiquement converties en SQLite. Avant de passer à RHEL 9, mettez à jour toutes les bases de données de confiance de DBM à SQLite.
En outre, l'outil pk12util utilise désormais les algorithmes AES et SHA-256 au lieu de DES-3 et SHA-1 par défaut lors de l'exportation de clés privées.
Notez que SHA-1 est désactivé par la politique cryptographique par défaut à l'échelle du système pour toutes les signatures dans RHEL 9.
Les NSS ne prennent plus en charge les clés RSA de moins de 1023 bits
La mise à jour des bibliothèques Network Security Services (NSS) modifie la taille minimale des clés pour toutes les opérations RSA de 128 à 1023 bits. Cela signifie que les NSS n'exécutent plus les fonctions suivantes :
- Générer des clés RSA plus courtes que 1023 bits.
- Signer ou vérifier des signatures RSA avec des clés RSA de moins de 1023 bits.
- Chiffrer ou déchiffrer des valeurs avec une clé RSA inférieure à 1023 bits.
L'API d'extension OpenSSL ENGINE n'est pas prise en charge en mode FIPS
L'ancien système d'extension d'OpenSSL, l'API ENGINE, n'est pas compatible avec la nouvelle API du fournisseur. Par conséquent, les applications qui dépendent des fonctionnalités fournies par les moteurs OpenSSL, telles que les modules openssl-pkcs11 et openssl-ibmca, ne peuvent pas être utilisées en mode FIPS.
Le mode FIPS d'OpenSSL doit être activé pour fonctionner correctement
Si vous utilisez des valeurs autres que les valeurs par défaut dans le fichier de configuration openssl.cnf lorsque le mode FIPS est activé, et en particulier lorsque vous utilisez un fournisseur FIPS tiers, ajoutez fips=1 au fichier openssl.cnf.
OpenSSL n'accepte pas les paramètres explicites de la courbe en mode FIPS
Les paramètres de cryptographie à courbe elliptique, les clés privées, les clés publiques et les certificats qui spécifiaient des paramètres de courbe explicites ne fonctionnent plus en mode FIPS. La spécification des paramètres de courbe à l'aide d'identificateurs d'objets ASN.1, qui utilisent l'une des courbes approuvées par le FIPS, fonctionne toujours en mode FIPS.
Libreswan demande désormais l'ESN par défaut
Dans Libreswan, la valeur par défaut de l'option de configuration esn= est passée de no à either. Cela signifie que lors de l'établissement de connexions, Libreswan demande l'utilisation du numéro de série étendu (ESN) par défaut. En particulier, lorsque la décharge matérielle est utilisée, ce nouveau comportement empêche certaines cartes d'interface réseau (NIC) d'établir une connexion IPsec si elles ne supportent pas l'ESN. Pour désactiver l'ESN, définissez esn= sur no et l'option replay_window= sur une valeur inférieure ou égale à 32. Par exemple :
esn=no replay_window=32
L'option replay_window= est nécessaire parce qu'un mécanisme différent utilise ESN pour la protection anti-répétition avec des tailles de fenêtres supérieures à 32.
