HTTPS — la séquence complète

DNS → TCP → TLS → HTTP — 4 étapes, 7 échanges réseau, une page chargée.

Quand ton navigateur charge https://example.com, il ne se contente pas d'envoyer une requête HTTP. Il traverse quatre couches de protocoles dans un ordre précis — chacune dépendant de la précédente.

Total minimal : 4 RTT pour une première connexion (sans cache DNS). Sur une ligne à 50 ms de latence, ça représente 200 ms avant le premier octet de HTML — même si le serveur répond instantanément.

La phase TLS est celle que ce cours explore en détail. Comprendre ses mécanismes — le handshake, les certificats, la négociation de clés — te donnera les outils pour diagnostiquer des lenteurs, des erreurs de certificat et des configurations faibles.

Le handshake TLS 1.3 — 1 aller-retour

ClientHello, ServerHello, 4 messages chiffrés, Finished — le protocole de poignée de main en 1 RTT.

TLS 1.3 (RFC 8446, 2018) a radicalement simplifié le handshake de son prédécesseur. Là où TLS 1.2 nécessitait 2 allers-retours avant d'envoyer des données applicatives, TLS 1.3 n'en nécessite qu'un seul.

Les messages du handshake TLS 1.3

Voici la séquence complète, dans l'ordre chronologique :

Pourquoi le certificat est-il chiffré ?

En TLS 1.2, le certificat voyageait en clair. N'importe quel observateur réseau pouvait voir quel site tu visitais (même sans déchiffrer la communication). En TLS 1.3, le certificat est dans Certificate, chiffré après ServerHello. Seul le SNI dans le ClientHello révèle encore le domaine cible — et ECH (Encrypted Client Hello, RFC en cours) est conçu pour chiffrer même ça.

Certificats X.509 — la chaîne de confiance

Leaf → Intermediate → Root — comment le navigateur vérifie qui tu es vraiment.

Un certificat X.509, c'est comme un passeport délivré par une autorité reconnue : il lie une clé publique à une identité, et porte la signature de quelqu'un en qui tout le monde fait confiance.

Les champs d'un certificat

La chaîne de confiance

Ton navigateur ne connaît pas directement le certificat de example.com. Il suit une chaîne de signatures jusqu'à un certificat racine (Root CA) qu'il stocke dans son trust store.

Pourquoi cette hiérarchie ? Les Root CA gardent leurs clés privées hors ligne, dans des HSM (Hardware Security Modules) en chambre forte. Signer directement des certificats feuilles les exposerait trop. Les Intermediate CA, eux, sont en ligne pour signer, mais leur compromission n'affecte pas le Root.

Types de certificats DV, OV, EV

Forward Secrecy et ECDHE

Des clés éphémères pour chaque connexion — même si la clé du serveur fuite demain, les sessions d'hier restent secrètes.

Imagine que quelqu'un enregistre tout ton trafic HTTPS chiffré aujourd'hui. Si dans 5 ans la clé privée du serveur fuite, pourra-t-il déchiffrer ce qu'il a capturé ? Avec le Forward Secrecy, la réponse est non.

Le problème sans Forward Secrecy (TLS 1.2 avec RSA)

Dans TLS 1.2 sans ECDHE, l'échange de clés fonctionnait ainsi :

1. Le client génère un pre-master secret aléatoire.
2. Il le chiffre avec la clé publique RSA du serveur (du certificat).
3. Le serveur déchiffre avec sa clé privée RSA.

Problème : si un attaquant a enregistré la session et vole plus tard la clé privée RSA du serveur, il peut déchiffrer le pre-master secret, reconstruire les clés de session, et déchiffrer toute la conversation.

ECDHE — Elliptic Curve Diffie-Hellman Ephemeral

Avec ECDHE, chaque connexion génère une paire de clés temporaires (éphémères) qui sont jetées après la session :

Les deux parties calculent indépendamment le même secret partagé :

• Client : secret = c · S = c · s · G
• Serveur : secret = s · C = s · c · G

Un observateur voit C et S, mais résoudre c ou s depuis un point de courbe elliptique est computationnellement infaisable (problème du logarithme discret sur courbe elliptique).

Pourquoi TLS 1.3 l'impose

TLS 1.3 a supprimé les cipher suites à échange RSA statique (TLS_RSA_WITH_*). Toutes les suites TLS 1.3 utilisent ECDHE (ou DHE). Le Forward Secrecy n'est plus optionnel — c'est la seule façon de faire.

Cipher suites TLS 1.3 — AEAD obligatoire

3 suites seulement, toutes AEAD — AES-GCM et ChaCha20-Poly1305, chiffrement authentifié sans exception.

TLS 1.2 supportait des centaines de cipher suites, incluant des algorithmes cassés (RC4), vulnérables (CBC sans HMAC-then-encrypt correct), ou simplement anciens. TLS 1.3 fait table rase : seulement 5 suites définies, toutes AEAD.

Les 5 cipher suites TLS 1.3

AES-GCM vs ChaCha20-Poly1305

Ce que TLS 1.3 a éliminé

Session resumption et 0-RTT

Le ticket PSK permet de reprendre une session sans refaire le handshake — 0-RTT envoie les données avant même le Finished.

Un handshake TLS 1.3 complet coûte 1 RTT. Pour les connexions répétées au même serveur (navigation sur un site, reconnexions après coupure réseau), TLS 1.3 propose de sauter ce coût grâce aux tickets PSK.

Session resumption 1-RTT avec PSK

Le serveur n'a pas besoin d'envoyer son certificat à nouveau — l'identité a déjà été vérifiée. La connexion est établie en 1 RTT, soit le même coût qu'un handshake initial.

0-RTT — Early Data

TLS 1.3 va plus loin : le client peut envoyer des données applicatives dans le premier message, avant même d'avoir reçu le Finished du serveur. C'est le 0-RTT.

Comparatif des modes de connexion

SNI et ALPN — négocier dans le handshake

SNI dit au serveur quel domaine tu veux. ALPN lui dit quel protocole applicatif tu parles.

Le ClientHello de TLS transporte deux extensions qui permettent au serveur de prendre des décisions avant même que le handshake soit terminé : SNI pour savoir quel certificat présenter, ALPN pour négocier le protocole applicatif.

SNI — Server Name Indication

Le problème que SNI résout : en HTTP, le header Host: permet le virtual hosting sur une seule IP. Mais en HTTPS, le serveur doit présenter son certificat avant de recevoir les headers HTTP. Sans SNI, impossible de faire du virtual hosting HTTPS avec plusieurs domaines sur une même IP.

ALPN — Application-Layer Protocol Negotiation

Le client envoie une liste de protocoles qu'il supporte (par ordre de préférence) :

// Dans ClientHello, extension ALPN :
"h2"          // HTTP/2
"http/1.1"    // HTTP/1.1

Le serveur répond avec le protocole choisi dans EncryptedExtensions :

// Dans EncryptedExtensions :
"h2"          // Le serveur choisit HTTP/2

Protocoles identifiants ALPN courants

SNI + ALPN ensemble dans ClientHello

Ces deux extensions voyagent dans le même ClientHello. Le serveur peut ainsi, en un seul message reçu du client, savoir :

• Quel domaine est demandé → choix du certificat (SNI)
• Quel protocole sera utilisé → préparation du contexte applicatif (ALPN)

HSTS, CAA et OCSP Stapling

Trois mécanismes complémentaires — forcer HTTPS, restreindre les CAs, prouver la non-révocation sans latence.

TLS seul ne suffit pas pour une sécurité HTTPS complète. Trois mécanismes complémentaires ferment des brèches que le handshake TLS ne couvre pas : le downgrade vers HTTP, l'émission de certificats non autorisés, et la vérification de révocation lente.

HSTS — HTTP Strict Transport Security

Le header se présente ainsi :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

CAA — Certification Authority Authorization

# Enregistrements DNS CAA pour example.com :
example.com  CAA  0  issue      "letsencrypt.org"
example.com  CAA  0  issuewild  "letsencrypt.org"
example.com  CAA  0  iodef      "mailto:security@example.com"

OCSP Stapling

Le problème de l'OCSP classique : le client doit contacter le serveur OCSP du CA à chaque connexion — ajoutant une requête réseau vers un tiers, de la latence, et révélant au CA quel site tu visites.

Lors du handshake TLS, le serveur inclut cette réponse dans le message CertificateStatus. Le client vérifie la signature sans contacter le CA.

Avantages de l'OCSP Stapling :

• Zéro latence OCSP pour le client
• Protection vie privée : le CA ne voit pas qui visite quoi
• Résilience : fonctionne même si le répondeur OCSP du CA est indisponible

Attaques historiques et protections

BEAST, POODLE, HEARTBLEED, BREACH — ce que chacune a cassé et ce que TLS 1.3 a corrigé.

L'histoire de TLS est jalonnée d'attaques qui ont forcé l'évolution du protocole. Comprendre ces attaques, c'est comprendre pourquoi TLS 1.3 est conçu comme il l'est.

BEAST — Browser Exploit Against SSL/TLS (2011)

POODLE — Padding Oracle On Downgraded Legacy Encryption (2014)

HEARTBLEED (2014)

BREACH — Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (2013)

Synthèse — configurer HTTPS correctement

Quelle version TLS, quel cipher, quel header — le guide de configuration sécurisée d'un serveur HTTPS.

Après avoir exploré chaque mécanisme individuellement, voici comment ils s'assemblent en une configuration HTTPS solide. Ce n'est pas une check-list exhaustive — c'est un guide de décision raisonné.

Quelle version TLS ?

Quelles cipher suites pour TLS 1.2 ?

Si tu dois maintenir TLS 1.2, n'accepte que :

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Toutes avec ECDHE (Forward Secrecy) et GCM ou ChaCha20 (AEAD). Pas de CBC, pas de RSA statique.

Checklist de configuration serveur

Ce que TLS ne couvre pas

TLS protège le transit des données entre client et serveur. Il ne protège pas :

• Les données au repos sur le serveur (chiffrement de base de données, disques)
• Les données en mémoire du serveur (attaques Heartbleed-like, accès root)
• La validité du contenu servi (un certificat valide ne prouve pas que le site est légitime)
• Les métadonnées de trafic : volumes, timing, destinations (visible malgré TLS)