Comment fonctionne SSL/TLS : Le handshake TLS expliqué

Chaque fois que vous visitez un site HTTPS, votre navigateur et le serveur effectuent un handshake TLS — un échange rapide qui authentifie le serveur, convient des paramètres de chiffrement et dérive une clé secrète partagée. Cela se produit en 1 à 2 allers-retours réseau (50–200 ms) avant le chargement de tout contenu de page.

Le handshake TLS 1.3 (standard actuel)

TLS 1.3 complète le handshake en un seul aller-retour (1-RTT) :

Étape 1 — Client Hello Votre navigateur envoie : les versions TLS prises en charge, les cipher suites prises en charge, un nombre aléatoire et les paramètres de partage de clé (pour l’échange de clés Diffie-Hellman).

Étape 2 — Server Hello + Certificate + Finished Le serveur répond avec : la cipher suite choisie, son certificat (prouvant son identité), son partage de clé et un message « Finished ». Dans TLS 1.3, le certificat est chiffré — les observateurs passifs ne peuvent pas voir à quel site vous vous connectez.

Étape 3 — Client Finished Le navigateur vérifie le certificat par rapport à sa liste de CA de confiance, calcule la clé de session partagée à partir de l’échange Diffie-Hellman et envoie son message « Finished ». Les données d’application chiffrées peuvent maintenant circuler.

Total : 1 aller-retour. Les connexions reprises (quand le client s’est déjà connecté) peuvent utiliser le 0-RTT — envoyant des données chiffrées dès le tout premier message.

Le handshake TLS 1.2 (encore largement utilisé)

TLS 1.2 nécessite 2 allers-retours :

1. Client Hello → versions prises en charge, ciphers, nombre aléatoire
2. Server Hello → cipher choisi, certificat, échange de clé serveur
3. Client Key Exchange → pre-master secret (chiffré avec la clé publique du serveur ou via Diffie-Hellman)
4. Change Cipher Spec + Finished (les deux côtés)

TLS 1.2 prend en charge davantage de cipher suites — y compris certaines faibles. Une configuration correcte est plus importante qu’avec TLS 1.3.

Ce qui se passe dans la connexion chiffrée

Après le handshake, toutes les données sont chiffrées avec la clé de session négociée en utilisant un chiffrement symétrique (typiquement AES-256-GCM ou ChaCha20-Poly1305) :

• Confidentialité — les données sont chiffrées ; seuls les deux points terminaux peuvent les lire
• Intégrité — chaque message inclut un MAC (code d’authentification de message) ; toute altération est détectée
• Authentification — le certificat du serveur prouve son identité (et optionnellement, celle du client)

Chaque requête et réponse HTTP — en-têtes, corps, cookies, URLs — transite par ce canal chiffré.

Forward Secrecy

Le TLS moderne utilise l’échange de clés Diffie-Hellman éphémère, ce qui signifie que chaque connexion génère une clé de session unique. Même si la clé privée du serveur est compromise ultérieurement, les conversations passées ne peuvent pas être déchiffrées.

TLS 1.3 rend le Forward Secrecy obligatoire. TLS 1.2 le prend en charge mais autorise aussi l’échange de clés RSA (qui ne fournit pas le Forward Secrecy). C’est pourquoi TLS 1.3 est préféré.

Le rôle du certificat

Le handshake TLS requiert que le serveur possède un certificat SSL/TLS valide. Le certificat fournit :

1. La clé publique du serveur — utilisée lors de l’échange de clés
2. Le(s) nom(s) de domaine — le navigateur vérifie qu’ils correspondent à l’URL
3. La signature de la CA — prouve qu’une autorité de certification de confiance se porte garante de ce certificat
4. Les dates de validité — le navigateur rejette les certificats expirés

Sans certificat valide, le handshake échoue et le navigateur affiche un avertissement de sécurité. Obtenir un certificat gratuit →

Performances

Sur du matériel moderne, le coût CPU du chiffrement est négligeable — les instructions AES-NI le gèrent en matériel. Le coût principal réside dans le(s) aller(s)-retour(s) supplémentaire(s), que TLS 1.3 minimise.

Ce qui est visible sur le réseau

Sans HTTPS (HTTP)

Un observateur sur le réseau voit tout :

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

Noms d’utilisateur, mots de passe, cookies, contenu des pages — tout en clair.

Avec HTTPS (TLS)

Le même observateur voit :

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

Il peut voir l’adresse IP de destination et le nom d’hôte SNI (dans TLS 1.2 — chiffré dans TLS 1.3 avec ECH). Il ne peut pas voir le chemin de l’URL, les en-têtes, le corps ou les cookies.

Comment le certificat s’intègre

Le handshake TLS requiert que le serveur possède un certificat SSL/TLS valide :

1. La clé publique du serveur — utilisée lors de l’échange de clés
2. Le(s) nom(s) de domaine — le navigateur vérifie qu’ils correspondent à l’URL
3. La signature de la CA — prouve qu’une autorité de certification de confiance se porte garante de ce certificat
4. Les dates de validité — le navigateur rejette les certificats expirés

Sans certificat valide, le handshake échoue et le navigateur affiche un avertissement de sécurité. Obtenir un certificat gratuit →

Cipher suites TLS courantes en 2026

TLS 1.3 (seulement 5 cipher suites — toutes sécurisées)

TLS_AES_256_GCM_SHA384       ← La plus courante
TLS_AES_128_GCM_SHA256       ← Largement utilisée
TLS_CHACHA20_POLY1305_SHA256 ← Optimale pour mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/embarqué
TLS_AES_128_CCM_8_SHA256     ← IoT/embarqué (tag court)

TLS 1.2 (utilisez uniquement les suites AEAD)

ECDHE-ECDSA-AES256-GCM-SHA384  ← Meilleur avec un certificat ECC
ECDHE-RSA-AES256-GCM-SHA384    ← Meilleur avec un certificat RSA
ECDHE-ECDSA-CHACHA20-POLY1305  ← Optimisé pour mobile

Évitez les suites non-AEAD (mode CBC) dans TLS 1.2 — elles ont été vulnérables à des attaques comme BEAST et Lucky13.

Questions fréquentes

HTTPS ralentit-il mon site web ?

Le handshake TLS ajoute un aller-retour (TLS 1.3) ou deux (TLS 1.2) à la première connexion. La reprise de session élimine cela pour les visiteurs de retour. Comme HTTPS active HTTP/2 (multiplexage, compression des en-têtes), les sites HTTPS sont souvent plus rapides dans l’ensemble.

Qu’est-ce qu’une cipher suite ?

Une cipher suite est une combinaison d’algorithmes utilisés pour l’échange de clés, le chiffrement et l’authentification des messages. Exemple : TLS_AES_256_GCM_SHA384 signifie TLS avec chiffrement AES-256-GCM et SHA-384 pour l’intégrité des messages. TLS 1.3 n’a que 5 cipher suites — toutes sécurisées. TLS 1.2 en a 37, dont certaines sont faibles.

Quelqu’un peut-il déchiffrer le trafic HTTPS plus tard ?

Pas avec le Forward Secrecy (échange de clés éphémère). Chaque session utilise une clé unique dérivée de l’échange Diffie-Hellman. Même si la clé privée à long terme du serveur est compromise, les clés de session passées ne peuvent pas être récupérées. TLS 1.3 impose cela ; TLS 1.2 le prend en charge lorsqu’il est correctement configuré.

Quel est le rapport entre GetHTTPS et tout cela ?

GetHTTPS génère le certificat qui rend le handshake TLS possible. Le certificat contient la clé publique que le serveur utilise lors de l’échange de clés. GetHTTPS crée cette paire de clés dans votre navigateur à l’aide de l’API Web Crypto et se connecte directement à l’API ACME de Let’s Encrypt pour la faire signer. Comment fonctionne GetHTTPS →