Établissement d’une connexion TLS

Maintenant que nous avons exploré les fondements cryptographiques et les certificats utilisés dans TLS, plongeons dans le fonctionnement concret d’une connexion sécurisée. Comment toutes ces briques technologiques s’assemblent-elles pour créer une communication sécurisée sur Internet ? C’est ce que nous allons découvrir dans cet article.

Le handshake TLS expliqué étape par étape

Quand vous vous connectez à un site sécurisé, votre navigateur et le serveur effectuent ce qu’on appelle un « handshake » (poignée de main) TLS. Ce processus fait intervenir les différentes briques cryptographiques de manière intelligente et complémentaire. Voici les étapes détaillées :

1. Initiation de la connexion

Bonjour initial : Votre navigateur envoie un message « ClientHello » au serveur, incluant :

Les versions TLS supportées
Une liste des suites cryptographiques supportées
Un nombre aléatoire généré par le client

Réponse du serveur : Le serveur répond avec un « ServerHello » incluant :

La version TLS choisie
La suite cryptographique sélectionnée
Un nombre aléatoire généré par le serveur

À ce stade, aucun chiffrement n’est encore appliqué, la communication est en clair.

2. Authentification du serveur

Présentation du certificat : Le serveur envoie son certificat TLS qui contient plusieurs éléments clés :

Sa clé publique (pour le chiffrement asymétrique)
Son identité (nom de domaine)
La signature numérique de l’autorité de certification

Vérification du certificat : Votre navigateur procède à plusieurs vérifications :

Il vérifie que le nom de domaine correspond au site visité
Il vérifie que le certificat n’est pas expiré
Il utilise des fonctions de hachage pour calculer l’empreinte du certificat
Il utilise le chiffrement asymétrique pour vérifier la signature du certificat grâce à la clé publique de l’autorité de certification
Il vérifie que le certificat n’a pas été révoqué (via CRL ou OCSP)

C’est ici que les signatures numériques jouent leur rôle crucial d’authentification : elles garantissent que le certificat a bien été émis par une autorité reconnue et qu’il n’a pas été modifié. Sans cette étape, un attaquant pourrait facilement se faire passer pour le site légitime.

Exemple concret : Quand vous vous connectez à votre banque en ligne, votre navigateur vérifie que le certificat a bien été émis pour « mabanque.fr » et qu’il est signé par une autorité de confiance comme DigiCert ou Let’s Encrypt.

3. Échange de clé et établissement du secret partagé

Cette étape combine ingénieusement le chiffrement asymétrique et symétrique pour obtenir le meilleur des deux mondes :

Échange de clé sécurisé : Selon la méthode négociée (généralement ECDHE ou RSA), votre navigateur et le serveur établissent un secret partagé. Par exemple, avec RSA :

Votre navigateur génère une « Pre-Master Secret Key » (clé secrète temporaire)
Il utilise la clé publique du serveur (chiffrement asymétrique) pour chiffrer cette clé
Il envoie cette clé chiffrée au serveur
Seul le serveur, avec sa clé privée, peut déchiffrer ce message

Cet échange utilise les avantages du chiffrement asymétrique pour résoudre le problème fondamental du chiffrement symétrique : comment partager une clé secrète sur un canal non sécurisé.

Génération des clés de session : À partir du secret partagé et des nombres aléatoires échangés précédemment, les deux parties dérivent de manière indépendante les mêmes clés de session en utilisant des fonctions de hachage.

Exemple concret : C’est comme si vous et votre banque aviez besoin d’échanger un coffre-fort, mais sans savoir quelle clé utiliser. Le chiffrement asymétrique permet d’envoyer la clé du coffre à travers un canal non sécurisé, sans qu’elle puisse être interceptée et utilisée par un tiers.

4. Communication sécurisée

Utilisation du chiffrement symétrique : Une fois les clés de session établies, toutes les communications ultérieures sont chiffrées avec ces clés en utilisant des algorithmes comme AES-256 ou ChaCha20.

Le système bascule donc vers le chiffrement symétrique pour la suite de la communication, car il est :

Beaucoup plus rapide que le chiffrement asymétrique
Tout aussi sécurisé pour des communications continues
Moins gourmand en ressources serveur

Vérification d’intégrité : Chaque message envoyé inclut également un code d’authentification (HMAC) créé à l’aide de fonctions de hachage, qui permet de vérifier que le message n’a pas été altéré en cours de route.

Exemple concret : Quand vous effectuez un virement bancaire en ligne, les détails de la transaction (montant, bénéficiaire, etc.) sont chiffrés avec AES-256. Même si quelqu’un parvient à intercepter ces données, il ne verra qu’une suite inintelligible de caractères.

Aperçu global du processus

En résumé, TLS utilise intelligemment les différentes briques cryptographiques selon leurs forces respectives :

Chiffrement asymétrique : Pour l’authentification et l’échange initial de clé
Chiffrement symétrique : Pour les communications continues une fois la connexion établie
Fonctions de hachage : Pour vérifier l’intégrité des données et générer des signatures
Signatures numériques : Pour authentifier les certificats et le serveur

Exemple complet : Quand vous tapez « https://www.gmail.com » dans votre navigateur, ce processus sophistiqué se produit en quelques millisecondes. Vous pouvez voir cette connexion sécurisée établie quand le cadenas apparaît dans votre barre d’adresse.

Les différences dans TLS 1.3

TLS 1.3, la version la plus récente du protocole, a significativement amélioré le processus de handshake :

Handshake en 1-RTT (aller-retour)

Dans TLS 1.3, le handshake a été simplifié pour ne nécessiter qu’un seul aller-retour (1-RTT) avant de commencer à envoyer des données chiffrées :

ClientHello : Le client envoie immédiatement :
- Les versions TLS supportées
- Les algorithmes cryptographiques supportés
- Les paramètres pour l’échange de clés (par exemple, les paramètres ECDHE)
ServerHello + données chiffrées : Le serveur répond avec :
- La version TLS et la suite cryptographique choisies
- Son certificat et sa signature
- Ses paramètres pour l’échange de clés
- Et peut déjà commencer à envoyer des données application chiffrées

Cette optimisation réduit considérablement la latence lors de l’établissement d’une connexion sécurisée.

0-RTT (zéro aller-retour)

TLS 1.3 introduit également une fonctionnalité encore plus rapide appelée « 0-RTT » :

Si le client s’est déjà connecté au serveur auparavant, il peut utiliser des informations stockées de la session précédente
Le client peut envoyer des données chiffrées dès le premier message, sans attendre de réponse du serveur
Cela permet d’établir une connexion sécurisée presque instantanément

Note importante : Le mode 0-RTT offre moins de garanties contre certaines attaques par rejeu, il est donc à utiliser avec précaution et uniquement pour certains types de requêtes.

Les suites cryptographiques

Une suite cryptographique (ou ciphersuite) est un ensemble d’algorithmes qui définissent comment la sécurité est assurée. Elle comprend généralement :

Un mécanisme d’échange de clés
Un algorithme d’authentification
Un algorithme de chiffrement pour la confidentialité
Une fonction de hachage pour l’intégrité

Format d’une suite cryptographique

Dans TLS 1.2, une suite cryptographique pourrait ressembler à :

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Décortiquons ce nom :

TLS : Le protocole utilisé
ECDHE : Méthode d’échange de clés (Elliptic Curve Diffie-Hellman Ephemeral)
RSA : Algorithme d’authentification
AES_256_GCM : Algorithme de chiffrement symétrique et son mode
SHA384 : Fonction de hachage pour l’intégrité

TLS 1.3 a simplifié les noms de suites cryptographiques, par exemple :

TLS_AES_256_GCM_SHA384

Choisir les bonnes suites cryptographiques

Un serveur correctement configuré devrait:

Privilégier les suites cryptographiques modernes et sécurisées
Désactiver les algorithmes obsolètes ou vulnérables
Respecter l’ordre de préférence du client (si raisonnable)

Exemple de configuration sécurisée pour un serveur web :

# Suites recommandées pour TLS 1.3
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Suites recommandées pour TLS 1.2 (si encore supporté)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Exemple pratique : Lorsque vous visitez votre banque en ligne, votre navigateur et le serveur de la banque négocient une suite cryptographique sécurisée. Vous pouvez voir laquelle est utilisée en cliquant sur le cadenas dans la barre d’adresse, puis en recherchant les détails de connexion.

L’évolution des versions TLS

Le protocole a évolué au fil du temps pour corriger des failles de sécurité :

SSL v2 et v3 : À proscrire (obsolètes et vulnérables)

Vulnérabilités notables :

POODLE (Padding Oracle On Downgraded Legacy Encryption) : Permettait d’intercepter des données chiffrées avec SSLv3
BEAST (Browser Exploit Against SSL/TLS) : Exploitation des vulnérabilités du chiffrement par bloc en mode CBC

Statut actuel : Totalement dépréciés et désactivés dans tous les navigateurs modernes.

TLS 1.0 et 1.1 : À proscrire (vulnérables à certaines attaques)

Vulnérabilités notables :

Vulnérables à BEAST (comme SSLv3)
Absence de support pour les algorithmes cryptographiques modernes
Problèmes avec les modes de chiffrement CBC

Statut actuel : Dépréciés et désactivés dans la plupart des navigateurs modernes depuis 2020.

TLS 1.2 : Acceptable sous certaines conditions

Améliorations :

Introduction de suites cryptographiques plus sécurisées (GCM, SHA-256)
Meilleure protection contre les attaques connues
Support pour l’authentification et le chiffrement AEAD (Authenticated Encryption with Associated Data)

Vulnérabilités potentielles :

La configuration du serveur est cruciale – une mauvaise configuration peut encore permettre des suites cryptographiques faibles
Certaines implémentations peuvent souffrir de la vulnérabilité ROBOT (dérivée de l’ancienne attaque Bleichenbacher)

Statut actuel : Encore largement supporté et utilisé, mais progressivement remplacé par TLS 1.3.

TLS 1.3 : Recommandé (plus sécurisé et plus rapide)

Améliorations majeures :

Simplification : Suppression de nombreux algorithmes obsolètes et vulnérables
Performance : Handshake plus rapide (1-RTT, voire 0-RTT)
Sécurité renforcée : Perfect Forward Secrecy obligatoire
Confidentialité améliorée : Chiffrement de plus de métadonnées pendant le handshake
Résistance aux attaques : Conçu pour résister aux attaques connues contre les versions précédentes

Statut actuel : Recommandé pour toutes les nouvelles implémentations et mises à jour de systèmes existants.

Forward Secrecy : Une notion fondamentale

La Perfect Forward Secrecy (PFS) ou confidentialité persistante parfaite est une propriété essentielle des connexions TLS modernes :

Principe

Si la clé privée du serveur est compromise dans le futur, les sessions passées ne peuvent pas être déchiffrées
Chaque session utilise des clés éphémères générées uniquement pour cette session
Ces clés temporaires ne sont jamais stockées et ne peuvent pas être recalculées, même avec la clé privée du serveur

Comment ça fonctionne

Utilisation de méthodes d’échange de clés comme ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
Le « E » à la fin est crucial : il signifie « Ephemeral » (éphémère)
Les paramètres de cette clé sont générés à la volée pour chaque session et jamais réutilisés

Exemple concret

Imaginez que vous ayez échangé des messages confidentiels avec votre banque pendant des années. Si un jour la clé privée du serveur de la banque est compromise :

Sans Forward Secrecy : Un attaquant qui aurait enregistré toutes vos communications passées pourrait les déchiffrer toutes
Avec Forward Secrecy : Même avec la clé privée du serveur, l’attaquant ne peut déchiffrer aucune de vos communications passées

Cette propriété est devenue obligatoire avec TLS 1.3, renforçant considérablement la sécurité à long terme des communications sur Internet.

Exemple complet : TLS en action

Imaginons que vous souhaitiez consulter votre compte bancaire en ligne. Voici ce qui se passe en coulisses :

Vous tapez https://www.mabanque.fr dans votre navigateur.
ClientHello : Votre navigateur établit une connexion avec le serveur de la banque et initie un handshake TLS en envoyant :
- « Je supporte TLS 1.2 et 1.3 »
- « Je peux utiliser ces suites cryptographiques… »
- « Voici un nombre aléatoire que j’ai généré… »
ServerHello : Le serveur répond :
- « Utilisons TLS 1.3 »
- « J’ai choisi cette suite cryptographique : TLS_AES_256_GCM_SHA384 »
- « Voici mon nombre aléatoire… »
Le serveur présente son certificat, signé par une autorité de certification reconnue.
Votre navigateur vérifie que :
- Le certificat est émis pour « www.mabanque.fr«
- Il n’a pas expiré
- Il est signé par une autorité de confiance
- Il n’a pas été révoqué (via OCSP ou CRL)
Échange de clés : Votre navigateur et le serveur établissent un secret partagé via ECDHE.
Les deux parties dérivent des clés de session à partir de ce secret.
Finished : Les deux parties confirment que le handshake s’est bien déroulé.
Un cadenas apparaît dans la barre d’adresse, indiquant une connexion sécurisée.
Toutes les données que vous échangez avec la banque (identifiants, numéros de compte, transactions) sont désormais chiffrées avec AES-256-GCM.
Si quelqu’un tente d’intercepter ces données, il ne verra qu’un flux de caractères incompréhensibles.

Conclusion

Le processus d’établissement d’une connexion TLS est un chef-d’œuvre d’ingénierie cryptographique. Il combine plusieurs technologies pour assurer une communication sécurisée sur un réseau non sécurisé comme Internet. Les versions récentes du protocole, notamment TLS 1.3, ont considérablement amélioré la sécurité et les performances.

Dans notre prochain et dernier article, nous verrons comment manipuler concrètement des certificats TLS à l’aide de l’outil OpenSSL, essentiel pour les administrateurs système et les développeurs travaillant sur des applications sécurisées.