Aurelien Hault

TLS : Bien choisir ses suites cryptographiques

Vous avez configuré votre serveur web, activé le chiffrement mais vous vous demandez encore ce que peuvent bien signifier toutes ces séquences de lettres et de chiffres dans votre configuration.

Si vous ne savez pas à quoi cela correspond, je vous invite à lire la suite pour avoir une vue d’ensemble qui vous permettra d’approfondir le sujet.

L’objectif n’est donc pas de couvrir tous les aspects mais bien de vous introduire dans le monde merveilleux des suites cryptographiques 🙂

Une breve introduction

Lors de la phase de sécurisation d’un site web, une étape cruciale intervient quand il s’agit d’activer et configurer la couche TLS.

Activer le TLS pour son serveur web et installer son certificat commandé chez un tiers de confiance ne suffit plus. Il a été maintes fois prouvé que des failles pouvaient exister et que des techniques étaient connues pour fragiliser le chiffrement utilisé par le serveur.

C’est là qu’intervient un choix capital, celui des suites cryptographiques (Cipher Suite en anglais) que vous allez autoriser pour votre site web (à noter que les conseils donnés dans ce post peuvent s’adapter à la configuration d’autres outils (STunnel par exemple) ou à d’autres protocoles (FTPS par exemple).

Qu'est-ce qu'une suite cryptographique ?

Description détaillée

Chaque suite cryptographique définit un algorithme d’échange de clés et d’authentification, de chiffrement par bloc et de code d’authentification de message (MAC) usuellement représentés dans cet ordre4,5.

  • L’algorithme d’échange de clés est utilisé pour déterminer la méthode permettant au client et au serveur d’établir un canal de communication sécurisé (chiffrement asymétrique)
  • L’algorithme d’authentification est utilisé pour déterminer si et comment le client et le serveur vont s’authentifier mutuellement durant la poignée de main
  • L’algorithme de chiffrement par bloc est utilisé pour chiffrer le flux de données (chiffrement symétrique). Il inclut également la taille de la clé ainsi que la longueur du vecteur d’initialisation (Nonce cryptographique)
  • L’algorithme de code d’authentification de message (MAC) est utilisé pour créer un condensat (ou empreinte) afin de vérifier l’intégrité de chaque bloc composant le flux de données

Exemple d’écriture

Il existe plusieurs conventions pour l’écriture des suites cryptographiques.
Celle normalisée par l’IANA et celle utilisée par OpenSSL sont les plus connues.

Prenons l’exemple pour la suite suivante :
Algorithme d’échange de clés : ECDHE
Algorithme d’authentification : RSA
Algorithme de chiffrement par bloc : AES 256bits en mode GCM
Algorithme de code d’authentification de message : SHA256

L’écriture sous la forme normalisée par l’IANA sera TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256. Si vous l’écrivez sous la forme OpenSSL, ce sera ECDHE-RSA-AES256-GCM-SHA256.

Recommandation

Version de TLS

Actuellement, les versions disponibles de TLS sont la 1.0, la 1.1 et la 1.2.

La version TLS 1.2 doit être privilégiée.
Les versions TLS 1.1 et 1.0, avec prise en charge de TLS_FALLBACK_SCSV peuvent être déployées en cas de nécesité comme la compatibilité client.

Algorithme d’échange de clés

La propriété de confidentialité persistante doit être assurée. Il faut pour cela employer une suite cryptographique reposant sur un échange Diffie-Hellman éphémère (ECDHE ou, à défaut, DHE).

Echanger les clés avec ECDHE

Les échanges de clés ECDHE doivent être privilégiés, à l’aide de courbes secp256r1, secp384r1, secp521r1, brainpoolP256r1, brainpoolP384r1 ou brainpoolP512r1.

Echanger les clés avec DHE

Les échanges DHE sont tolérés avec des groupes 2048 bits ou plus (3072 bits ou plus si l’information doit être protégée au-delà de 2030).

Algorithme d’authentification

Le mécanisme de chiffrement asymétrique RSA est conforme au Référentiel Général de Sécurité (RGS) à condition de respecter une taille de clés :
– Supérieure ou égale à 2048 bits ne devant pas dépasser l’année 2020
– Supérieure ou égale à 4096 bits pour une utilisation au-delà de 2020

Le mécanisme de chiffrement asymétrique ECDSA, à base de courbes elliptiques (ECC), est conforme au RGS à condition de respecter une taille qui est supérieure ou égale à 256 bits pour les clés.

Algorithme de chiffrement par bloc

Les suites mettant en oeuvre l’algorithme de chiffrement par bloc AES-256 sont à privilégier.
L’algorithme AES-128 constitue une alternative acceptable.

Bien que soumis à moins d’examens, Camellia et ARIA offrent à ce jour une sécurité comparable à AES et peuvent être envisagés comme alternatives.

Algorithme de code d’authentification de message

Le HMAC permettant l’authentification doit être construit à l’aide d’un représentant de la famille SHA2 : SHA-256 ou bien SHA-384.

L’usage de HMAC construits à l’aide de SHA-1 n’est à utiliser que si les clients ne supportent pas les algorithmes de la famille SHA-2.

Tableau récapitulatif
CONSEILLÉE ALTERNATIVE
Algorithme d’échange de clés ECDHE DHE
Algorithme d’authentification ECDSA
RSA
Algorithme de chiffrement par bloc AES-256
AES-128
GCM
CBC
CAMELLIA
ARIA
Algorithme de code d’authentification de message SHA-384
SHA-256
SHA-1
Suites recommandées

Suites recommandées pour un serveur disposant d’une clé ECDSA

CODE TLS SUITE CRYPTOGRAPHIQUE
0xC02C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
0xC02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
0xC0AD TLS_ECDHE_ECDSA_WITH_AES_256_CCM
0xC0AC TLS_ECDHE_ECDSA_WITH_AES_128_CCM
0xC024 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
0xC023 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

Suites recommandées pour un serveur disposant d’une clé RSA

CODE TLS SUITE CRYPTOGRAPHIQUE
0xC030 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
0xC02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
0xC028 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
0xC027 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Suites alternatives

En l’absence de prise en charge de ECC

CODE TLS SUITE CRYPTOGRAPHIQUE
0x009F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
0x009E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
0xC09F TLS_DHE_RSA_WITH_AES_256_CCM
0xC09E TLS_DHE_RSA_WITH_AES_128_CCM
0x006B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
0x0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

En l’absence de prise en charge des échanges Diffie-Hellman

L’utilisation des suites listées ci-dessous doivent être mises en oeuvre seulement si les équipements ne sont pas vulnérables à la faille Robot Attack (https://robotattack.org/).

Plus d’information ici : https://www.cert.ssi.gouv.fr/alerte/CERTFR-2017-ALE-020/

Vérification de la bonne application de votre configuration

Une fois fini, il est plus prudent d’évaluer la configuration qui a été appliquée. En plus de la consultation des logs produits, un test peut être réalisé depuis un service gratuit offert par Qualys.
Le site SSL Labs (https://www.ssllabs.com/ssltest/index.html) va vous permettre de renseigner l’url de votre serveur. Une fois le test terminé, vous aurez toutes les informations relatives à la qualité de l’implémentation de votre couche SSL/TLS.

Ci-dessous une capture écran avant l’optimisation des suites. A remarquer qu’une configuration par défaut n’est pas toujours souhaitable.

Suite à l’optimisation de la configuration, le niveau de sécurité à clairement été relevé. Et avouons-le, tout le monde aime avoir une bonne note 😉

Références
Articles associés

Les IA font évoluer les attaques

7 février 2024
  Jusqu’à présent, les attaques liées à l’ingénierie sociale (Social Engineering) étaient en tête sur la liste des vecteurs de compromission initiale. C’était sans compter sur l’IA (Intelligence Artificielle) qui est en passe de faire exploser les records !   Une accélération des attaques Depuis fin 2022, le nombre de phishing a été multiplié par […]

La méthode FAIR : un guide vers une gestion efficace des risques pour votre entreprise.

13 décembre 2023
  Cette méthode, qui gagne en popularité, offre une perspective unique et pragmatique pour évaluer et gérer les risques de manière plus efficace et précise. Cet article revient sur les principes fondamentaux de la méthode FAIR et son application concrète.     FAIR: Factor Analysis of Information Risk Le standard FAIR est un modèle analytique […]
Partager cet article
Derniers articles

Le groupe iDNA soutient le Challenge de Marine

Il y a quelques mois, nous avions lancé un appel à projets auprès de nos collaborateurs. Notre jury a décidé de soutenir le projet proposé par Marine : le Défi de la Muzelle. Elle répond à nos questions :   Qui es-tu et quel est ton poste au sein du groupe iDNA ? Je m’appelle Marine, je viens […]

Portrait de Francisca, Chargée des Ressources Humaines au sein du groupe iDNA

Depuis juin 2021, Francisca occupe le poste de Chargée des Ressources Humaines au sein du groupe iDNA. Elle a accepté de nous livrer son parcours, son poste et ses spécificités, mais aussi sa vision et ses valeurs.   Peux-tu te présenter rapidement ? Je m’appelle Francisca, j’habite en banlieue parisienne et je suis chargée des Ressources […]

Portrait d’Aurore, Responsable des Ressources Humaines au sein du groupe iDNA

Depuis 8 ans maintenant, Aurore occupe le poste de Responsable des Ressources Humaines au sein du groupe iDNA. C’est avec un grand sourire qu’elle a accepté de répondre à nos questions. Découvrez son parcours, son poste et ses spécificités, mais aussi sa vision et ses valeurs.    Peux-tu te présenter rapidement ? Je m’appelle Aurore, j’ai […]

Les IA font évoluer les attaques

  Jusqu’à présent, les attaques liées à l’ingénierie sociale (Social Engineering) étaient en tête sur la liste des vecteurs de compromission initiale. C’était sans compter sur l’IA (Intelligence Artificielle) qui est en passe de faire exploser les records !   Une accélération des attaques Depuis fin 2022, le nombre de phishing a été multiplié par […]