HTTP, HTTPS et TLS
Comment fonctionne une requête web, ce que TLS protège vraiment (et ce qu'il ne protège pas), et ce qu'on peut encore voir dans un flux chiffré.
Elouan
Série Les fondations du réseau · article 7 sur 7
Le web représente l’essentiel du trafic d’une entreprise, et l’essentiel de ce trafic est chiffré. Il faut donc comprendre deux choses : comment fonctionne une requête HTTP, et ce qu’il reste visible une fois qu’elle est enveloppée dans TLS.
HTTP : demander, recevoir
HTTP (HyperText Transfer Protocol) fonctionne en requête / réponse. Le client demande une ressource, le serveur répond. Le protocole est sans état : chaque requête est indépendante, et c’est pour garder une session ouverte qu’on utilise des cookies ou des jetons.
Une requête ressemble à ceci :
GET /compte/factures?annee=2026 HTTP/1.1
Host: www.exemple.fr
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...
Cookie: session=8f3a91c2...
Et la réponse :
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=8f3a91c2...; Secure; HttpOnly
Les méthodes
| Méthode | Usage |
|---|---|
| GET | Lire une ressource. Les paramètres sont dans l’URL, donc dans les journaux. |
| POST | Envoyer des données (formulaire, connexion, envoi de fichier) |
| PUT / PATCH | Créer ou modifier une ressource (API) |
| DELETE | Supprimer une ressource |
| HEAD | Comme GET, mais sans le contenu (vérifier qu’une ressource existe) |
| OPTIONS | Demander les méthodes autorisées |
Les codes de statut
| Code | Sens | À retenir en sécurité |
|---|---|---|
| 200 OK | Succès | |
| 301 / 302 | Redirection | Chaînes de redirection dans le phishing |
| 304 | Pas modifié (cache) | |
| 400 | Requête mal formée | Souvent des scanners ou des injections maladroites |
| 401 | Non authentifié | Rafale de 401 = force brute |
| 403 | Interdit | Accès à une ressource protégée |
| 404 | Introuvable | Rafale de 404 = énumération de répertoires |
| 500 | Erreur du serveur | Une injection qui fait planter l’application |
| 502 / 503 | Passerelle ou service indisponible | Possible déni de service |
Lire un journal de serveur web
Une même adresse IP qui génère des centaines de 404 en quelques minutes sur des chemins comme /wp-admin, /.env, /backup.zip, c’est un outil d’énumération automatique. Un 200 au milieu de cette rafale mérite d’être regardé de près : l’outil a peut-être trouvé quelque chose.
TLS : ce qu’il protège
HTTPS, c’est simplement HTTP transporté dans un tunnel TLS (Transport Layer Security), le successeur de SSL. TLS apporte trois garanties :
- La confidentialité : personne sur le chemin ne peut lire le contenu.
- L’intégrité : personne ne peut le modifier sans que ça se voie.
- L’authentification du serveur : le certificat prouve qu’on parle bien au propriétaire du domaine.
La poignée de main TLS 1.3, simplifiée
Client Serveur
│ ── Client Hello ─────────────────────────► │ versions, algorithmes, nom du site (SNI), part de clé
│ ◄──────────────────────────── Server Hello │ choix des algorithmes, part de clé
│ ◄─────────── certificat, signature, Finished │ (déjà chiffrés en TLS 1.3)
│ ── Finished ─────────────────────────────► │
│ ════════════ données HTTP chiffrées ═══════ │
Le client et le serveur font un échange de clés Diffie-Hellman éphémère : chacun envoie une moitié, et les deux calculent la même clé de session sans jamais l’envoyer sur le réseau. Le serveur prouve son identité en signant l’échange avec la clé privée de son certificat. Le client vérifie que ce certificat est valide, qu’il correspond bien au nom demandé, et qu’il est signé par une autorité de certification de confiance (le détail est dans la partie Cryptographie).
Ce que TLS 1.3 a changé
Une poignée de main en un seul aller-retour (plus rapide), la confidentialité persistante obligatoire, et la suppression des algorithmes faibles (RC4, SHA-1, RSA sans échange éphémère…). SSL 3.0, TLS 1.0 et TLS 1.1 sont considérés comme obsolètes.
Le cadenas ne veut pas dire « site honnête »
C’est probablement la confusion la plus répandue, et une question piège classique.
Piège classique
Le cadenas prouve qu’on est bien connecté à ce domaine, de façon chiffrée. Il ne dit rien de qui est derrière. Un site connexion-banque-securite.com peut avoir un certificat parfaitement valide, obtenu gratuitement en quelques minutes. L’immense majorité des sites de phishing sont aujourd’hui en HTTPS.
Ce qu’on voit encore dans un flux chiffré
Le chiffrement cache le contenu, mais il laisse beaucoup de métadonnées. C’est sur elles que repose une grande partie de la détection réseau.
| Visible | Caché |
|---|---|
| Adresses IP et ports | URL complète (chemin, paramètres) |
| Le nom du site demandé (SNI), en clair sauf avec ECH | En-têtes HTTP (cookies, User-Agent…) |
| Le certificat du serveur (selon la version et l’outil) | Contenu des pages et des fichiers |
| Taille des échanges, durée, régularité | Identifiants saisis |
| Empreinte du client TLS (JA3 / JA4) | |
| Les requêtes DNS associées, si elles ne sont pas chiffrées |
Repérer un beacon chiffré
Un poste qui ouvre une connexion TLS vers la même adresse toutes les 60 secondes, à quelques secondes près, avec des échanges de taille presque identique, ressemble fortement au beaconing d’un implant de C2, même si on ne voit pas le contenu. Une empreinte JA3 connue pour être celle d’un outil comme Cobalt Strike, un certificat auto-signé ou un domaine enregistré la veille renforcent le soupçon.
L’inspection TLS en entreprise
Pour voir le contenu, certaines entreprises font de l’interception TLS sur leur proxy ou leur pare-feu : il déchiffre le flux, l’inspecte, puis le rechiffre vers le poste avec un certificat signé par une autorité interne, déployée sur tous les postes.
C’est efficace, mais ça a des contreparties :
- juridiques : information des salariés, et exclusion des catégories sensibles (banque, santé) ;
- techniques : certaines applications vérifient précisément le certificat attendu (certificate pinning) et cassent ;
- sécurité : le proxy voit tout en clair, il devient une cible de choix.
HTTP/2 et HTTP/3 en une phrase
HTTP/2 fait passer plusieurs requêtes en parallèle dans une seule connexion TCP. HTTP/3 fait la même chose sur QUIC, donc sur UDP/443, avec TLS 1.3 intégré (voir l’article sur TCP et UDP).
C’est la fin de la série sur le réseau : la suite passe aux systèmes Windows et Linux.
L'essentiel
- HTTP est un protocole requête / réponse, sans état. Méthodes principales : GET, POST, PUT, DELETE, HEAD, OPTIONS.
- Codes de statut : 2xx succès, 3xx redirection, 4xx erreur du client (401 non authentifié, 403 interdit, 404 introuvable), 5xx erreur du serveur.
- HTTPS = HTTP dans un tunnel TLS. TLS apporte la confidentialité, l'intégrité et l'authentification du serveur (grâce au certificat).
- Le cadenas prouve qu'on parle bien au propriétaire du domaine, pas que le site est honnête : les sites de phishing ont des certificats valides.
- Même chiffré, on voit l'IP de destination, le port, les volumes, le rythme des connexions, et souvent le nom demandé (SNI) et le certificat. Le contenu et l'URL complète sont cachés.
- TLS 1.3 : poignée de main en un aller-retour, confidentialité persistante obligatoire, algorithmes faibles supprimés. SSL, TLS 1.0 et 1.1 sont obsolètes.
Idées reçues
Un site en HTTPS avec un cadenas est-il sûr ?
L'erreur courante. Répondre oui.
En réalité. Le cadenas garantit seulement que la connexion est chiffrée et que le certificat correspond au nom du domaine. Il ne dit rien de l'honnêteté du site. Obtenir un certificat gratuit (Let's Encrypt) pour un domaine de phishing prend quelques minutes. La grande majorité des sites de phishing sont en HTTPS.
Avec HTTPS, que peut voir un attaquant ou un analyste qui observe le réseau ?
L'erreur courante. Répondre « rien, tout est chiffré ».
En réalité. Il voit les adresses IP, les ports, la taille et le rythme des échanges, et en général le nom du site demandé dans le SNI et le certificat présenté (avant TLS 1.3, le certificat circulait en clair). Il ne voit ni l'URL complète, ni les en-têtes, ni le contenu. Les requêtes DNS associées peuvent aussi être visibles si elles ne sont pas chiffrées.
Quelle est la différence entre 401 et 403 ?
L'erreur courante. Dire que c'est la même chose.
En réalité. 401 Unauthorized veut dire « tu n'es pas authentifié » (ou tes identifiants sont mauvais). 403 Forbidden veut dire « je sais qui tu es, mais tu n'as pas le droit ». En investigation, une rafale de 401 évoque une force brute, une série de 403 évoque une tentative d'accès à des ressources protégées.
Qu'est-ce que la confidentialité persistante (forward secrecy) ?
L'erreur courante. La confondre avec le chiffrement en général.
En réalité. Chaque session utilise une clé temporaire négociée par échange Diffie-Hellman éphémère. Si la clé privée du serveur est volée plus tard, on ne peut pas déchiffrer les anciennes sessions enregistrées. TLS 1.3 la rend obligatoire.
Comment une entreprise peut-elle inspecter le trafic HTTPS de ses postes ?
L'erreur courante. Dire que c'est impossible ou que TLS est cassé.
En réalité. Par interception TLS sur un proxy ou un pare-feu : il déchiffre, inspecte et rechiffre. Pour que les postes ne voient pas d'alerte, l'entreprise déploie le certificat de son autorité interne sur tous les postes. Ça pose des questions juridiques (information des salariés, exclusion des sites de santé ou de banque) et de sécurité (le proxy devient un point très sensible).
Tester ses connaissances
Références
- Bulletproof TLS and PKI (2e éd.)Ivan Ristić · Feisty Duck
- The Web Application Hacker's Handbook (2e éd.)Dafydd Stuttard, Marcus Pinto · Wiley
- Serious Cryptography (2e éd.)Jean-Philippe Aumasson · No Starch Press