7 min de lecture

HTTP en profondeur - 09 - TLS et HTTPS : chiffrer le web

Comment TLS sécurisé HTTP, la différence entre TLS 1.2 et 1.3, les certificats, Let's Encrypt et HSTS.

HTTP web TLS HTTPS sécurité
HTTP en profondeur 10 / 22
  1. 01 HTTP en profondeur - 00 - Pourquoi comprendre HTTP change tout
  2. 02 HTTP en profondeur - 01 - Anatomie d'une URL
  3. 03 HTTP en profondeur - 02 - La requête HTTP
  4. 04 HTTP en profondeur - 03 - La réponse HTTP
  5. 05 HTTP en profondeur - 04 - Les méthodes HTTP
  6. 06 HTTP en profondeur - 05 - Les codes de statut
  7. 07 HTTP en profondeur - 06 - Les headers HTTP
  8. 08 HTTP en profondeur - 07 - Les cookies
  9. 09 HTTP en profondeur - 08 - Le cache HTTP : éviter les requêtes inutiles
  10. 10 HTTP en profondeur - 09 - TLS et HTTPS : chiffrer le web
  11. 11 HTTP en profondeur - 10 - La compression : réduire la taille des réponses
  12. 12 HTTP en profondeur - 11 - La negociation de contenu : servir le bon format
  13. 13 HTTP en profondeur - 12 - L'authentification HTTP : prouver qui tu es
  14. 14 HTTP en profondeur - 13 - CORS : les requêtes cross-origin demystifiees
  15. 15 HTTP en profondeur - 14 - Les redirections : guider le client ailleurs
  16. 16 HTTP en profondeur - 15 - Proxy : forward, reverse et les headers qui trahissent
  17. 17 HTTP en profondeur - 16 - HTTP/2 : multiplexage, compression et la fin des hacks
  18. 18 HTTP en profondeur - 17 - HTTP/3 et QUIC : UDP, 0-RTT et migration de connexion
  19. 19 HTTP en profondeur - 18 - WebSocket : full-duplex, frames et cas d'usage
  20. 20 HTTP en profondeur - 19 - Security headers : CSP, HSTS et compagnie
  21. 21 HTTP en profondeur - 20 - Debugger HTTP : curl, DevTools, Wireshark et les autres
  22. 22 HTTP en profondeur - 21 - Glossaire HTTP de A a Z
← Precedent Suivant →

09 - TLS et HTTPS : chiffrer le web

Ce que tu vas apprendre

  • Ce que TLS fait concrètement pour protéger le trafic HTTP
  • La différence entre le handshake TLS 1.2 et TLS 1.3
  • Comment les certificats et la chaîne de confiance fonctionnent
  • Le rôle de Let's Encrypt et du protocole ACME
  • Pourquoi HSTS est indispensable

Prerequisites

HTTP en clair, c'est une carte postale. Tout le monde entre toi et le serveur peut lire le contenu : ton FAI, le wifi du cafe, un attaquant sur le réseau. HTTPS, c'est la meme carte postale dans une enveloppe scellee. Le facteur la transporte, mais il ne peut pas la lire.

Le "S" de HTTPS, c'est TLS. Transport Layer Security. Une couche de chiffrement qui se glisse entre TCP et HTTP. Le protocole HTTP ne change pas. Les headers, les méthodes, les status codes sont identiques. Mais tout le contenu est chiffre avant d'etre envoye sur le réseau.

Le handshake TLS : la poignee de main

Avant d'échanger des donnees chiffrees, le client et le serveur doivent se mettre d'accord sur les clés. C'est le handshake.

TLS 1.2 : deux allers-retours

Client                          Serveur
  |--- ClientHello ------------->|    (cipher suites supportees)
  |<-- ServerHello --------------|    (cipher suite choisie)
  |<-- Certificate --------------|    (certificat du serveur)
  |<-- ServerKeyExchange --------|    (parametres Diffie-Hellman)
  |<-- ServerHelloDone ----------|
  |--- ClientKeyExchange ------->|    (cle pre-master chiffree)
  |--- ChangeCipherSpec -------->|
  |--- Finished ---------------->|
  |<-- ChangeCipherSpec ---------|
  |<-- Finished -----------------|
  |========= Donnees chiffrees =========|

Deux allers-retours complets avant la première donnee utile. Sur une connexion a 100ms de latence, ca fait 400ms rien que pour le handshake.

TLS 1.3 : un seul aller-retour

TLS 1.3 simplifie radicalement le processus. Le client envoie ses paramètres de clé directement dans le ClientHello. Le serveur répond avec tout ce qu'il faut en un seul message.

Client                          Serveur
  |--- ClientHello + KeyShare -->|
  |<-- ServerHello + KeyShare ---|
  |<-- Certificate --------------|
  |<-- Finished -----------------|
  |--- Finished ---------------->|
  |========= Donnees chiffrees =========|

Un seul aller-retour. 200ms au lieu de 400ms. Et avec le mode 0-RTT (reconnexion), le client peut envoyer des donnees des le premier message. Mais attention : le 0-RTT est vulnerable aux attaques par rejeu. A utiliser uniquement pour des requêtes idempotentes comme les GET.

TLS 1.3 a aussi supprime les cipher suites faibles. Plus de RC4, plus de CBC, plus de RSA pour l'échange de clés. Moins de choix, mais des choix surs par défaut.

Certificats et chaîne de confiance

Quand tu te connectes a example.com, comment sais-tu que c'est bien le vrai serveur et pas un imposteur ? Grace aux certificats.

Un certificat TLS contient :

  • Le nom de domaine (ou les noms, via SAN)
  • La clé publique du serveur
  • La signature d'une autorite de certification (CA)
  • Des dates de validite

La chaîne de confiance fonctionne ainsi : ton navigateur fait confiance a une liste de CA racines (environ 150). Ces CA racines signent des CA intermediaires. Les CA intermediaires signent les certificats des sites. Quand le serveur presente son certificat, le navigateur remonte la chaîne jusqu'a une CA racine qu'il connaît.

CA Racine (preinstalle dans le navigateur)
  |
  +-- CA Intermediaire (signe par la racine)
        |
        +-- Certificat de example.com (signe par l'intermediaire)

Si un seul maillon est manquant ou invalide, le navigateur affiche l'erreur redoutee "Votre connexion n'est pas privee".

Let's Encrypt et le protocole ACME

Avant 2015, un certificat TLS coutait entre 10 et 300 euros par an. Let's Encrypt a tout change en offrant des certificats gratuits et automatises via le protocole ACME.

Le principe est simple. Pour prouver que tu contrôles un domaine, le serveur ACME te donne un defi :

  1. "Place ce fichier a http://example.com/.well-known/acme-challenge/xyz"
  2. Tu le places
  3. Let's Encrypt vérifié qu'il peut le lire
  4. Tu obtiens ton certificat, valide 90 jours

Le renouvellement est automatique. Un cron job ou un outil comme Certbot s'en charge. Sur paltemps.fr, le certificat se renouvelle tout seul via Caddy, qui intégré ACME nativement. Zero intervention manuelle depuis la mise en place.

Il existe aussi le defi DNS : tu places un enregistrement TXT dans ta zone DNS. C'est nécessaire pour les certificats wildcard (*.example.com).

HSTS : forcer HTTPS définitivement

Tu as HTTPS. Bravo. Mais si un utilisateur tape http://example.com, il arrive d'abord en HTTP avant d'etre redirige en HTTPS. Pendant cette fraction de seconde, un attaquant peut intercepter la connexion.

HSTS (HTTP Strict Transport Security) resout ca :

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

Apres la première visite en HTTPS, le navigateur retient que ce domaine est HTTPS uniquement. Pendant deux ans (max-age=63072000), toute tentative HTTP est automatiquement convertie en HTTPS cote client, avant meme d'envoyer la requête.

Le includeSubDomains etend la protection a tous les sous-domaines. Le preload permet d'inclure ton domaine dans la liste HSTS prechargee des navigateurs (hstspreload.org). A ce stade, meme la première visite est protégée.

Le contenu mixte : le piège de la migration

Tu passes ton site en HTTPS, mais certaines images ou scripts sont encore charges en HTTP. C'est le contenu mixte.

Les navigateurs modernes bloquent le contenu mixte actif (scripts, iframes) et affichent un avertissement pour le contenu mixte passif (images). Dans les deux cas, ton cadenas vert disparaît.

La solution : des URLs relatives ou en https:// partout. Un Content-Security-Policy: upgrade-insecure-requests peut aussi aider pendant la transition en demandant au navigateur de convertir automatiquement les URLs HTTP en HTTPS.

Certificate Transparency

Comment savoir si une CA a emis un certificat frauduleux pour ton domaine ? Certificate Transparency (CT) est un système de logs publics ou chaque certificat emis est enregistre. Tu peux surveiller ces logs pour détecter des certificats suspects.

Des outils comme crt.sh permettent de chercher tous les certificats emis pour un domaine. Si tu vois un certificat que tu n'as pas demande, il y a un problème.

mTLS : quand le serveur aussi vérifié le client

En TLS classique, seul le serveur prouve son identité. En mTLS (mutual TLS), le client aussi presente un certificat. C'est courant dans les architectures microservices ou chaque service a son propre certificat. Le service mesh Istio, par exemple, utilise mTLS par défaut entre tous les services.

Pour le web grand public, mTLS est rare. Mais entre services internes, c'est une couche de sécurité supplementaire qui authentifié chaque partie sans token ni mot de passe.

Résumé

  • TLS chiffre le trafic HTTP sans changer le protocole lui-meme
  • TLS 1.3 réduit le handshake a un seul aller-retour et supprime les algorithmes faibles
  • Les certificats forment une chaîne de confiance des CA racines jusqu'au domaine
  • Let's Encrypt fournit des certificats gratuits via le protocole ACME
  • HSTS force le navigateur a utiliser HTTPS des le premier instant
  • Le contenu mixte casse la sécurité HTTPS et doit etre elimine
  • mTLS authentifié les deux parties, utile entre services internes

Article précédent : 08 - Le cache HTTP

Article suivant : 10 - La compression

Sources

Publie le · Mis a jour le

Articles liés

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.

Découvrir Pal'Temps