5.2. Considérations de sécurité pour TLS dans RHEL 9
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 stratégies cryptographiques à l'échelle du système, FUTURE et LEGACY n'autorisent que TLS 1.2 et 1.3. Pour plus d'informations, voir Utilisation des stratégies 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.
La façon la plus simple de renforcer votre configuration TLS est de passer le niveau de politique cryptographique du système à FUTURE à l'aide de la commande update-crypto-policies --set FUTURE.
Les algorithmes désactivés pour la politique cryptographique LEGACY ne sont pas conformes à la vision de Red Hat de la sécurité de RHEL 9, et leurs propriétés de sécurité ne sont pas fiables. Envisagez d'abandonner l'utilisation de ces algorithmes au lieu de les réactiver. Si vous décidez de les réactiver, par exemple pour des raisons d'interopérabilité avec du matériel ancien, considérez-les comme non sécurisés et appliquez des mesures de protection supplémentaires, telles que l'isolation de leurs interactions réseau sur des segments de réseau distincts. Ne les utilisez pas sur des réseaux publics.
Si vous décidez de ne pas suivre les politiques cryptographiques du système RHEL ou de créer des politiques cryptographiques personnalisées adaptées à votre configuration, utilisez les recommandations suivantes pour les protocoles, les suites de chiffrement et les longueurs de clé préférés dans votre configuration personnalisée :
5.2.1. Protocoles
La dernière version de TLS offre le meilleur mécanisme de sécurité. TLS 1.2 est désormais la version minimale, même lorsque l'on utilise la politique cryptographique LEGACY. Il est possible de réactiver les versions antérieures du protocole en renonçant aux politiques cryptographiques ou en fournissant une politique personnalisée, mais la configuration qui en résultera ne sera pas prise en charge.
Notez que même si RHEL 9 prend en charge la version 1.3 de TLS, toutes les fonctionnalités de ce protocole ne sont pas entièrement prises en charge par les composants de RHEL 9. Par exemple, la fonctionnalité 0-RTT (Zero Round Trip Time), qui réduit la latence de la connexion, n'est pas encore totalement prise en charge par le serveur web Apache.
5.2.2. Suites de chiffrement
Les suites de chiffrement modernes et plus sûres doivent être préférées aux suites anciennes et peu sûres. Désactivez toujours l'utilisation des suites de chiffrement eNULL et aNULL, qui n'offrent aucun chiffrement ni aucune authentification. Dans la mesure du possible, les suites de chiffrement basées sur RC4 ou HMAC-MD5, qui présentent de sérieuses lacunes, doivent également être désactivées. Il en va de même pour les suites de chiffrement dites d'exportation, qui ont été rendues intentionnellement plus faibles et sont donc faciles à casser.
Bien qu'elles ne soient pas immédiatement non sécurisées, les suites de chiffrement qui offrent moins de 128 bits de sécurité ne devraient pas être envisagées en raison de leur courte durée de vie. Les algorithmes qui utilisent 128 bits de sécurité ou plus peuvent être considérés comme inviolables pendant au moins plusieurs années et sont donc fortement recommandés. Il convient de noter que si les chiffrements 3DES annoncent l'utilisation de 168 bits, ils offrent en réalité une sécurité de 112 bits.
Préférez toujours les suites de chiffrement qui prennent en charge le secret de transmission (parfait) (PFS), qui garantit la confidentialité des données chiffrées même en cas de compromission de la clé du serveur. Cela exclut l'échange de clés rapide RSA, mais permet d'utiliser ECDHE et DHE. Parmi les deux, ECDHE est le plus rapide et donc le meilleur choix.
Vous devriez également préférer les chiffrements AEAD, tels que AES-GCM, aux chiffrements en mode CBC, car ils ne sont pas vulnérables aux attaques de l'oracle de remplissage. En outre, dans de nombreux cas, AES-GCM est plus rapide qu'AES en mode CBC, en particulier lorsque le matériel dispose d'accélérateurs cryptographiques pour AES.
Notez également que lorsque vous utilisez l'échange de clés ECDHE avec des certificats ECDSA, la transaction est encore plus rapide qu'un échange de clés RSA pur. Pour prendre en charge les anciens clients, vous pouvez installer deux paires de certificats et de clés sur un serveur : l'une avec des clés ECDSA (pour les nouveaux clients) et l'autre avec des clés RSA (pour les anciens clients).
5.2.3. Longueur de la clé publique
Lorsque vous utilisez des clés RSA, préférez toujours des longueurs de clés d'au moins 3072 bits signées par au moins SHA-256, ce qui est suffisamment important pour assurer une sécurité réelle de 128 bits.
La sécurité de votre système est aussi forte que le maillon le plus faible de la chaîne. Par exemple, un cryptogramme puissant ne garantit pas à lui seul une bonne sécurité. Les clés et les certificats sont tout aussi importants, de même que les fonctions de hachage et les clés utilisées par l'autorité de certification (AC) pour signer vos clés.
