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

Chrome remplace l’icône de verrouillage des adresses URL 

24 mai 2023
Depuis les années 90, nos navigateurs internet ont toujours affiché une icône de verrou devant les sites en protocole HTTPS. Ce dernier est d’ailleurs devenu une norme : 95% des pages web chargées sur Chrome (sur les systèmes d’exploitation Windows) passent par ce canal sécurisé et affichent l’icône de verrouillage : Cette icône est destinée à indiquer […]

Une rançon de 10 millions de dollars pour le Centre Hospitalier Sud Francilien (CHSF).

27 avril 2023
L’attaque « Une rançon fixée à 10 millions d’euros » Le 21 août 2022, aux alentours d’une heure du matin, le Centre Hospitalier Sud Francilien (CHSF) est victime d’un ransomware. L’attaque bloque tous les logiciels métiers de l’hôpital, les systèmes de stockage et le système d’information relatif aux admissions des patients. Les pirates leur réclament 10 millions […]
Partager cet article
Derniers articles

Chrome remplace l’icône de verrouillage des adresses URL 

Depuis les années 90, nos navigateurs internet ont toujours affiché une icône de verrou devant les sites en protocole HTTPS. Ce dernier est d’ailleurs devenu une norme : 95% des pages web chargées sur Chrome (sur les systèmes d’exploitation Windows) passent par ce canal sécurisé et affichent l’icône de verrouillage : Cette icône est destinée à indiquer […]

Une rançon de 10 millions de dollars pour le Centre Hospitalier Sud Francilien (CHSF).

L’attaque « Une rançon fixée à 10 millions d’euros » Le 21 août 2022, aux alentours d’une heure du matin, le Centre Hospitalier Sud Francilien (CHSF) est victime d’un ransomware. L’attaque bloque tous les logiciels métiers de l’hôpital, les systèmes de stockage et le système d’information relatif aux admissions des patients. Les pirates leur réclament 10 millions […]

Chronique d’une attaque annoncée : IOCs vs TTPs

Dans cet article je vous propose d’aborder le sujet de la détection des attaques informatiques et la manière de les contrer. La détection d’une attaque peut se faire en regardant les empreintes laissées par l’attaquant et ses outils, approche Indicateur de Compromission (IOC: Indicator Of Compromise), ou en s’appuyant sur une compréhension du comportement de […]

PCA, PRA, PCI, PRI, PCC : Stop à la confusion

En 2020, la crise sanitaire du COVID a mis toutes les sociétés à rude épreuve. Les moins structurées ont eu du mal à gérer leurs processus les plus essentiels et à s’organiser afin d’éviter des pertes financières considérables. Travaillant alors au sein d’un organisme certifié ISO 27001 dont l’une des exigences était notamment la mise […]