Elouan

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
  1. Adresses IP, masques et sous-réseaux
  2. Le modèle OSI et la pile TCP/IP
  3. Ports et protocoles courants
  4. TCP et UDP
  5. Le DNS, de la requête à l'attaque
  6. ARP, DHCP, NAT et VLAN : la plomberie du réseau local
  7. HTTP, HTTPS et TLS

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éthodeUsage
GETLire une ressource. Les paramètres sont dans l’URL, donc dans les journaux.
POSTEnvoyer des données (formulaire, connexion, envoi de fichier)
PUT / PATCHCréer ou modifier une ressource (API)
DELETESupprimer une ressource
HEADComme GET, mais sans le contenu (vérifier qu’une ressource existe)
OPTIONSDemander les méthodes autorisées

Les codes de statut

CodeSensÀ retenir en sécurité
200 OKSuccès
301 / 302RedirectionChaînes de redirection dans le phishing
304Pas modifié (cache)
400Requête mal forméeSouvent des scanners ou des injections maladroites
401Non authentifiéRafale de 401 = force brute
403InterditAccès à une ressource protégée
404IntrouvableRafale de 404 = énumération de répertoires
500Erreur du serveurUne injection qui fait planter l’application
502 / 503Passerelle ou service indisponiblePossible 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 :

  1. La confidentialité : personne sur le chemin ne peut lire le contenu.
  2. L’intégrité : personne ne peut le modifier sans que ça se voie.
  3. 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.

VisibleCaché
Adresses IP et portsURL complète (chemin, paramètres)
Le nom du site demandé (SNI), en clair sauf avec ECHEn-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

Textes de référence en ligne