7.2. Sécurité
SHA-1 est déprécié à des fins cryptographiques
L'utilisation du condensé de message SHA-1 à des fins cryptographiques a été supprimée dans RHEL 9. Le condensé produit par SHA-1 n'est pas considéré comme sûr en raison des nombreuses attaques réussies documentées basées sur la recherche de collisions de hachage. Les composants cryptographiques de base de RHEL ne créent plus de signatures à l'aide de SHA-1 par défaut. Les applications de RHEL 9 ont été mises à jour pour éviter d'utiliser SHA-1 dans les cas d'utilisation liés à la sécurité.
Parmi les exceptions, le code d'authentification des messages HMAC-SHA1 et les valeurs UUID (Universal Unique Identifier) peuvent encore être créés à l'aide de SHA-1, car ces cas d'utilisation ne présentent actuellement aucun risque pour la sécurité. SHA-1 peut également être utilisé dans des cas limités liés à d'importants problèmes d'interopérabilité et de compatibilité, tels que Kerberos et WPA-2. Pour plus de détails, consultez la section Liste des applications RHEL utilisant une cryptographie non conforme à la norme FIPS 140-3 dans le document de renforcement de la sécurité de 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.
(JIRA:RHELPLAN-110763)
SCP est obsolète dans RHEL 9
Le protocole de copie sécurisée (SCP) est obsolète car il présente des failles de sécurité connues. L'API SCP reste disponible pour le cycle de vie de RHEL 9, mais son utilisation réduit la sécurité du système.
-
Dans l'utilitaire
scp, SCP est remplacé par défaut par le protocole de transfert de fichiers SSH (SFTP). - La suite OpenSSH n'utilise pas SCP dans RHEL 9.
-
SCP est obsolète dans la bibliothèque
libssh.
(JIRA:RHELPLAN-99136)
Digest-MD5 dans SASL est obsolète
Le mécanisme d'authentification Digest-MD5 du cadre Simple Authentication Security Layer (SASL) est obsolète et pourrait être supprimé des paquets cyrus-sasl dans une prochaine version majeure.
(BZ#1995600)
OpenSSL supprime MD2, MD4, MDC2, Whirlpool, RIPEMD160, Blowfish, CAST, DES, IDEA, RC2, RC4, RC5, SEED et PBKDF1
Le projet OpenSSL a déprécié un ensemble d'algorithmes cryptographiques parce qu'ils ne sont pas sûrs, qu'ils sont peu utilisés, ou les deux. Red Hat déconseille également l'utilisation de ces algorithmes, et RHEL 9 les fournit pour migrer les données chiffrées afin d'utiliser de nouveaux algorithmes. Les utilisateurs ne doivent pas dépendre de ces algorithmes pour la sécurité de leurs systèmes.
Les implémentations des algorithmes suivants ont été déplacées vers l'ancien fournisseur d'OpenSSL : MD2, MD4, MDC2, Whirlpool, RIPEMD160, Blowfish, CAST, DES, IDEA, RC2, RC4, RC5, SEED et PBKDF1.
Consultez le fichier de configuration /etc/pki/tls/openssl.cnf pour savoir comment charger l'ancien fournisseur et activer la prise en charge des algorithmes obsolètes.
/etc/system-fips est désormais obsolète
La prise en charge de l'indication du mode FIPS par le fichier /etc/system-fips a été supprimée et le fichier ne sera pas inclus dans les versions futures de RHEL. Pour installer RHEL en mode FIPS, ajoutez le paramètre fips=1 à la ligne de commande du noyau lors de l'installation du système. Vous pouvez vérifier si RHEL fonctionne en mode FIPS à l'aide de la commande fips-mode-setup --check.
(JIRA:RHELPLAN-103232)
libcrypt.so.1 est désormais obsolète
La bibliothèque libcrypt.so.1 est désormais obsolète et pourrait être supprimée dans une prochaine version de RHEL.
fapolicyd.rules est obsolète
Le répertoire /etc/fapolicyd/rules.d/, qui contient les fichiers contenant les règles d'exécution d'autorisation et de refus, remplace le fichier /etc/fapolicyd/fapolicyd.rules. Le script fagenrules fusionne désormais tous les fichiers de règles de ce répertoire dans le fichier /etc/fapolicyd/compiled.rules. Les règles contenues dans /etc/fapolicyd/fapolicyd.trust sont toujours traitées par le cadre fapolicyd, mais uniquement dans un souci de compatibilité ascendante.
