Configurer RHEL 8 conformément à la politique de chiffrement liée au mode CBC

Dans cet article, nous allons voir comment supprimer le mode CBC (Cipher Block Chaining) en configurant la politique de chiffrement de Red Hat Enterprise Linux (RHEL) 8. Commençons par présenter ce mode ainsi que la politique de chiffrement par défaut de RHEL 8.

Au niveau de l'exploitation, les configurations système sont souvent complexes, avec trop ou pas assez d'informations disponibles pour tout comprendre. 

Par exemple, si on reçoit le message « Votre serveur prend en charge des blocs chiffrés CBC vulnérables qui ne sont plus recommandés », on va vouloir savoir si on est protégé contre une nouvelle vulnérabilité, demander au système de générer un rapport immédiat et de prendre des mesures de correction, le cas échéant. 

Quels outils va-t-on utiliser ? Quelles vérifications va-t-on effectuer ? Le système est-il correctement configuré ? Les serveurs sont-ils exempts de vulnérabilités connues ?

Les technologies disponibles dans RHEL 8 permettent de répondre à ces questions, dans le but d'améliorer l'efficacité de l'exploitation ainsi que la fiabilité et la compréhension des outils utilisés dans le cadre de la politique de chiffrement. 

Analyse du problème

Essayons de comprendre le problème à l'aide de cet article Wikipédia. 

Il est dit que le mode CBC, l'une des nombreuses formes du chiffrement par bloc, combine un bloc de texte par un OU exclusif au bloc précédent avant de le chiffrer. Il s'agit d'un mode d'opération couramment utilisé et recommandé par Niels Ferguson et Bruce Schneier. 

Parce qu'il a été inventé en 1976, on pourrait croire qu'il est dépassé et pas sécurisé. L'ancienneté n'est toutefois pas forcément synonyme de vulnérabilité. Le protocole d'échange de clés Diffie-Hellman date également de 1976, mais il est encore largement utilisé et considéré comme fiable.

Toutes ces informations ne nous avancent pas beaucoup. Il est fort probable que cette alerte provienne d'une analyse de vulnérabilité automatisée, qui a détecté que le serveur OpenSSH était prêt à utiliser les modes de chiffrement CBC en réponse à la CVE-2008-5161. Peut-être qu'une autre référence a été faite à ce document ou à un autre article tout aussi obscur. Certaines parties peuvent être rassurantes, par exemple lorsqu'il est écrit qu'il est donc très peu probable qu'une session interactive fasse l'objet d'une attaque exploitant cette faiblesse du protocole, et qu'un pirate s'attend à ce qu'il y ait environ 11 356 tentatives de suppression de connexion avant de réussir. On peut toutefois se demander si ce problème de sécurité datant d'une dizaine d'années a été traité dans RHEL.

Heureusement, Red Hat surveille et atténue les vulnérabilités de ses produits de manière proactive. Sur la page du NIST relative à la CVE-2008-5161 figure une déclaration de Red Hat indiquant que le problème a été corrigé à partir de RHEL 5. Red Hat a également fourni une solution de contournement pour désactiver les blocs chiffrés avec le mode CBC dans la configuration sshd.

Cet article précise également que des correctifs en amont ont été appliqués, ce qui protège davantage les systèmes contre l'attaque. Les outils d'analyse des vulnérabilités ignorent ces informations. Ils recherchent les versions de paquets spécifiques, les associent aux versions concernées et transmettent les résultats. Ces outils ne sont pas parfaits et ne peuvent pas détecter ces corrections. 

En cas de doute sur la sécurité d'un algorithme, pourquoi ne pas le désactiver complètement ? Il faut s'intéresser à la compatibilité avant d'effectuer un tel changement. 

Ces blocs chiffrés avec le mode CBC pourraient être la seule façon d'assurer l'interopérabilité avec des clients et serveurs SSH plus anciens, et il faut trouver l'équilibre entre des configurations par défaut plus sécurisées et la compatibilité lors de la création des distributions. 

Fedora 33, par exemple, désactive les blocs chiffrés avec le mode CBC en cas d'utilisation de SSH, comme vu dans cette demande de fusion en amont. Distribution d'entreprise lancée un an plus tôt, RHEL 8 les conserve cependant activés par défaut en raison de la présence de corrections et du besoin de compatibilité (page Bugzilla : 1818103 – SSH Server CBC Mode Ciphers Enabled in RHCOS).

Les configurations par défaut doivent être équilibrées, mais elles sont aussi faites pour être modifiées. La situation de chaque utilisateur est unique et il lui appartient de prendre les décisions qui lui conviennent. Pour répondre à ce besoin, RHEL 8 a adopté un nouveau mécanisme centralisé d'activation et de désactivation des algorithmes de chiffrement : les politiques de chiffrement. Voyons comment utiliser ces politiques pour désactiver les blocs chiffrés avec le mode CBC.

Configuration et fonctions liées à la politique de chiffrement de RHEL 8

Pour mieux comprendre la situation, il faut examiner la politique par défaut de RHEL 8 :

sudo less /usr/share/crypto-policies/policies/DEFAULT.pol 
# A reasonable default for today's standards. It should provide 
# 112-bit security with the exception of SHA1 signatures needed for DNSSec 
# and other still prevalent legacy use of SHA1 signatures.

D'autres politiques peuvent être définies dans RHEL 8 pour répondre aux exigences de sécurité supplémentaires concernant les politiques de chiffrement : 

• FIPS.pol : utilise uniquement un algorithme FIPS approuvé.

• FUTURE.pol : offre un niveau de sécurité raisonnable, permettant de résister aux attaques à court terme. 

• LEGACY.pol : fournit des paramètres qui garantissent une compatibilité maximale avec les systèmes existants.

Il est même possible de modifier ces politiques en créant des sous-politiques et de créer entièrement une politique. Il existe un article de blog publié par Red Hat qui présente l'outil update-crypto-policies, ses fonctions et son utilisation.

Il existe aussi une section de la documentation de RHEL 8 sur ce sujet : « Using system-wide cryptographic policies ».

Configuration de la politique de chiffrement de RHEL 8 pour supprimer le mode CBC

Revenons à notre problème initial. L'outil d'évaluation des vulnérabilités a signalé le problème suivant : « Vulnerability Name: SSH CBC Mode Ciphers Enabled, Description: CBC Mode Ciphers are enabled on the SSH Server ».

De nombreux utilisateurs affirment pouvoir configurer leur système pour corriger le problème et ainsi réussir l'analyse de vulnérabilité. Concrètement, ils configurent le processus sshd pour qu'il n'utilise pas les blocs chiffrés avec le mode CBC. Des instructions expliquent même comment appliquer cette solution de contournement. 

Cette pratique s'applique uniquement au processus sshd, et non à l'ensemble du serveur. Les modifications sont effectuées au niveau d'un processus plutôt qu'au niveau du système. Bien que le mode SSH CBC soit validé, des blocs chiffrés CBC restent sur le serveur. Il est plutôt recommandé d'effectuer la modification au niveau du système, et c'est exactement à cela que sert l'outil update-crypto-policies.

D'abord, affichons la politique de chiffrement actuellement utilisée dans le serveur RHEL 8 :

update-crypto-policies --show 
DEFAULT

Comme RHEL 8 utilise la politique de chiffrement DEFAULT, essayons de trouver les blocs chiffrés CBC dans /usr/share/crypto-policies/policies/DEFAULT.pol.

tls_cipher = ... AES-256-CBC ...AES-128-CBC 
cipher = ... AES-256-CBC CAMELLIA-256-CBC AES-128-CBC CAMELLIA-128-CBC

(Les blocs chiffrés non liés ont été supprimés pour plus de clarté.)

Six blocs chiffrés liés au mode CBC sont utilisés dans la politique DEFAULT.

La situation se complique à partir de là. Au moment de la rédaction de cet article, aucun fichier de politique ne montre des exemples du paramètre de chiffrement supplémentaire ssh_cipher. Celui-ci est mentionné dans une page du manuel sur les politiques de chiffrement : […] ssh_cipher : facultatif ; liste des algorithmes de chiffrement symétrique autorisés (y compris les modes) à utiliser avec le protocole SSH. S'il est absent, la valeur est dérivée de cipher[…]. 

Bien qu'il ne soit pas clairement visible dans la politique DEFAULT, le paramètre ssh_cipher existe et doit être exclu de la sous-politique si l'on souhaite supprimer efficacement tous les blocs chiffrés avec le mode CBC.

On peut créer une sous-politique qui modifie la politique DEFAULT utilisée. Pour ce faire, il faut créer un fichier de sous-politique :

 /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod

Remarque : la convention de dénomination est importante. Le nom de la sous-politique doit être en majuscules et le nom de l'extension .pmod en minuscules.

Ce fichier doit contenir les modifications à apporter à la politique DEFAULT.

Pour supprimer les blocs chiffrés avec le mode CBC du serveur en modifiant le profil DEFAULT, il faut ajouter ce qui suit :

tls_cipher = -AES-256-CBC -AES-128-CBC 
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC 
ssh_cipher = -AES-128-CBC -AES-256-CBC

Pour supprimer l'algorithme CBC du serveur pour sshd uniquement, il faut ajouter ce qui suit :

ssh_cipher = -AES-128-CBC -AES-256-CBC

Remarque : il n'existe aucun exemple pour ssh_cipher. On pourrait donc supposer que la valeur est la suivante :

ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

En réalité, on ne définit pas ces paramètres -CAMELLIA, car ils ne semblent pas être réellement présentés ou utilisés par sshd, comme on l'a déjà observé avec man sshd_config | grep -i cbc

                   3des-cbc                    
                   aes128-cbc                    
                   aes192-cbc                    
                   aes256-cbc )

Le paramètre 3des-cbc n'est pas présenté non plus par le serveur RHEL 8.2, comme vu avec ssh -vv et dans « Their offer: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr ».

Il faut définir la sous-politique configurée de manière à supprimer les blocs chiffrés avec le mode CBC :

sudo update-crypto-policies --set DEFAULT:DISABLE-CBC

Vérifions qu'elle est correctement définie avec la commande suivante : 

sudo update-crypto-policies --show  
DEFAULT:DISABLE-CBC

Le serveur doit ensuite redémarrer pour appliquer la politique et la sous-politique.

À ce stade, le serveur ne doit plus utiliser aucun bloc chiffré avec le mode CBC. Pour le vérifier, on peut utiliser sshd en exécutant cette commande à partir d'un serveur RHEL 8 :

ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 

Les informations de connexion doivent s'afficher et l'utilisateur doit être en mesure de se connecter à l'aide d'informations d'identification valides.

Si aucun bloc chiffré avec le mode CBC n'est présent pour sshd, la sortie suivante devrait s'afficher :

Unable to negotiate with 127.0.0.1 port 22: no matching cipher found. 

Le processus sshd affiche ensuite les blocs chiffrés proposés par ce serveur, par exemple : «  Their offer: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr ».

Résumé

Dans cet article, nous avons vu comment configurer un serveur RHEL 8 pour respecter l'exigence d'une politique de chiffrement. Nous avons montré comment supprimer les blocs chiffrés avec le mode CBC d'un serveur après avoir identifié le problème de sécurité. Nous avons utilisé des outils tels que update-crypto-policies pour assurer la conformité en matière de sécurité au niveau du serveur, au lieu d'agir au niveau des composants individuels.