Introduction aux suites de chiffrement

La sécurité de pratiquement toutes les connexions internet dépend du cryptage SSL/TLS . Le choix d'une suite de chiffrement détermine le niveau de protection de ces connexions. Qu'est-ce qu'une suite de chiffrement ?

Les suites de chiffrement sont des ensembles d'instructions qui permettent de sécuriser les connexions réseau par le biais de Transport Layer Security (TLS), souvent encore appelé Secure Sockets Layer (SSL). En coulisses, ces suites de chiffrement fournissent un ensemble d'algorithmes et de protocoles nécessaires pour sécuriser les communications entre les clients et les serveurs.

Pour initier une connexion HTTPS, les deux parties - le serveur web et le client - effectuent une poignée de main SSL . Le processus de poignée de main est assez complexe et permet aux deux parties de se mettre d'accord sur une suite de chiffrement mutuelle. La suite de chiffrement est ensuite utilisée pour négocier une connexion HTTPS sécurisée.

Comme nous l'avons dit précédemment, la poignée de main SSL est un processus complexe, car elle s'appuie sur diverses fonctions cryptographiques pour établir la connexion HTTPS. Au cours de la poignée de main, le client et le serveur web utiliseront :

• Un algorithme d'échange de clés, pour déterminer comment les clés symétriques seront échangées.
• un algorithme d'authentification ou de signature numérique, qui détermine la manière dont l'authentification du serveur et l'authentification du client (le cas échéant) seront mises en œuvre.
• Un algorithme de chiffrement en bloc, utilisé pour chiffrer les données.
• une fonction de hachage/MAC, qui détermine la manière dont les contrôles d'intégrité des données seront effectués

Ces algorithmes de chiffrement sont nécessaires à différents moments de la connexion pour effectuer l'authentification, la génération et l'échange de clés, ainsi qu'une somme de contrôle pour garantir l'intégrité. Pour déterminer les algorithmes spécifiques à utiliser, le client et le serveur web commencent par décider mutuellement de la suite de chiffrement à utiliser.

Les suites de chiffrement sont nécessaires en raison de la diversité des serveurs, des systèmes d'exploitation et des navigateurs. Il doit y avoir un moyen de prendre en compte toutes ces combinaisons, et les suites de chiffrement sont donc utiles pour assurer la compatibilité.

Lors de l'établissement d'une connexion, lorsque le client et le serveur échangent des informations, le serveur web et le navigateur comparent leurs listes prioritaires de suites de chiffrement prises en charge, vérifient leur compatibilité et déterminent la suite de chiffrement à utiliser.

Le choix de la suite de chiffrement utilisée dépend du serveur web. La suite de chiffrement convenue est une combinaison de :

• Algorithmes d'échange de clés, tels que RSA, DH, ECDH, DHE, ECDHE ou PSK

• Algorithme d'authentification/signature numérique, comme RSA, ECDSA ou DSA

• Algorithmes de chiffrement en bloc, tels que AES, CHACHA20, Camellia ou ARIA

• Algorithmes de code d'authentification des messages, tels que SHA-256 et POLY1305

Revenons à notre paradigme de la suite de chiffrement. Voyons quelles sont les informations fournies par une suite de chiffrement.

En partant de la gauche vers la droite, l'ECDHE détermine que, pendant la poignée de main, les clés seront échangées par l'intermédiaire de l'algorithme ECDHE (Elliptic Curve Diffie Hellman) éphémère. ECDSA (Elliptic Curve Digital Signature Algorithm) est l'algorithme d'authentification. AES128-GCM est l'algorithme de chiffrement de masse : AES fonctionnant en mode compteur de Galois avec une taille de clé de 128 bits. Enfin, SHA-256 est l'algorithme de hachage.

Les suites de chiffrement sont importantes pour garantir la sécurité, la compatibilité et les performances des connexions HTTPS. Tout comme les recettes décrivent les ingrédients nécessaires à la réalisation d'une recette parfaite, les suites de chiffrement déterminent les algorithmes à utiliser pour établir une connexion sécurisée et fiable.

Comme nous l'avons mentionné précédemment, c'est le serveur web qui détermine finalement la suite de chiffrement qui sera utilisée. Par conséquent, la liste des suites de chiffrement classées par ordre de priorité sur le serveur web est très importante. Le choix des bons chiffrements à répertorier sur un serveur web est un exercice vital pour tout administrateur et il est largement déterminé par le type d'utilisateurs qui se connectent au serveur et par la technologie qu'ils utilisent.

Les utilisateurs sont également responsables de la sécurisation des connexions. Étant donné que les fournisseurs de navigateurs mettent à jour leur liste de suites de chiffrement prises en charge après la découverte d'une vulnérabilité, les utilisateurs doivent installer les derniers correctifs du navigateur afin de réduire la probabilité de rencontrer des problèmes de compatibilité lorsque des suites de chiffrement faibles sont supprimées du côté du serveur.

Avant d'examiner le nombre de suites de chiffrement différentes qui existent, rappelons que tous les protocoles TLS antérieurs à TLS 1.2 (c'est-à-dire TLS 1.0 et TLS 1.1) ont été abandonnés pour diverses raisons de sécurité. Actuellement, les seuls protocoles TLS acceptables sont TLS 1.2 et TLS 1.3.

À partir de TLS 1.2, le protocole prend en charge 37 suites de chiffrement différentes. Si ce chiffre vous semble élevé, imaginez que TLS 1.2 existe depuis près de dix ans, période au cours de laquelle de nombreux systèmes différents ont vu le jour. Si l'on ajoute que chaque suite de chiffrement se compose de quatre algorithmes différents, on obtient jusqu'à 40 combinaisons différentes de chiffrement.

Parmi toutes les suites de chiffrement prises en charge dans TLS 1.2, il est conseillé d'utiliser celles qui utilisent l'algorithme Diffie-Hellman éphémère. Les suites de chiffrement conseillées sont donc les suivantes :

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

Avec l'introduction de TLS 1.3, beaucoup de choses ont changé pour améliorer la sécurité du protocole. Tout d'abord, les anciens algorithmes de chiffrement peu sûrs ont été supprimés, notamment :

• RC4
• DSA
• MD5
• SHA-1
• Courbes elliptiques faibles
• Échange de clés RSA
• Diffie-Hellman statique (DH, ECDH)
• Chiffres en bloc (CBC)
• Chiffres non-AEAD

En outre, les suites de chiffrement de TLS 1.3 sont désormais beaucoup plus courtes que les suites respectives de TLS 1.2. Les suites de chiffrement ne mentionnent pas le type de certificat - RSA ou ECDSA - ni le mécanisme d'échange de clés - DHE ou ECDHE. Par conséquent, le nombre de négociations nécessaires pour déterminer les paramètres de chiffrement a été réduit de quatre à deux. Les suites de chiffrement dans TLS 1.3 se présentent comme suit :

Le client entame la poignée de main en sachant que l'algorithme Diffie-Hellman éphémère sera utilisé pour le processus d'échange de clés, et il peut envoyer sa part de clé pendant le message Client Hello. L'avantage est que la poignée de main TLS 1.3 est réduite à un seul aller-retour, au cours duquel le serveur répond avec toutes les informations nécessaires pour que les deux parties puissent dériver la clé de session et commencer à communiquer en toute sécurité.

Les suites de chiffrement prises en charge dans TLS 1 .3 ne sont plus que cinq et sont les suivantes :

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

TLS Les suites de chiffrement 1.3 ne sont pas interopérables avec les anciennes versions de TLS , car leur structure est différente. Cela signifie que les administrateurs de sites devront configurer leurs serveurs web de manière à permettre la compatibilité avec les deux versions des suites de chiffrement prises en charge, TLS 1.2 et TLS 1.3. Opter pour la prise en charge de la seule version TLS 1.3 n'est pas une solution judicieuse, car de nombreuses entreprises utilisent encore la version TLS 1.2.

Mozilla recommande trois configurations différentes de suites de chiffrement pour les serveurs web utilisant le protocole TLS .

• Moderne : cette configuration est destinée aux clients modernes qui prennent en charge TLS 1.3, sans besoin de rétrocompatibilité. La configuration moderne offre un niveau de sécurité extrêmement élevé.
• Intermédiaire : Il s'agit de la configuration recommandée pour un serveur polyvalent qui n'a pas besoin d'être compatible avec d'anciens clients, tels que Windows XP ou d'anciennes versions d'OpenSSL. Elle est hautement sécurisée et compatible avec presque tous les clients publiés au cours des cinq dernières années (ou plus).
• Ancien : Services accessibles par des clients ou des bibliothèques très anciens, tels qu'Internet Explorer 8 (Windows XP), Java 6 ou OpenSSL 0.9.8, et ne doivent être utilisés qu'en dernier recours.

Les suites de chiffrement sont une combinaison de chiffres utilisés lors de la poignée de main SSL/TLS pour déterminer les paramètres de sécurité d'une connexion HTTPS. Il est important de choisir et de maintenir les suites de chiffrement appropriées, tant au niveau du serveur web que du client, pour garantir la sécurité, les performances et la compatibilité de vos communications HTTPS.

La maintenance des suites de chiffrement prises en charge est une fonction importante de la gestion du cycle de vie des certificats, qui permet de s'assurer que ces derniers sont conformes aux meilleures pratiques du secteur. L'obtention d'une visibilité complète de tous les certificats et connexions dans votre paysage informatique est une première étape essentielle, suivie d'une surveillance continue, d'un renouvellement et d'un provisionnement automatisés.

Découvrez comment Keyfactor Command permet une visibilité de bout en bout et l'automatisation de toutes les clés et de tous les certificats numériques dans votre environnement. Consultez notre démonstration de produit à la demande.