Ce que HTTPS protège

Objectifs

À la fin de cette leçon, vous saurez :

• expliquer ce que HTTPS ajoute à HTTP — et où exactement dans la pile ;
• identifier les trois menaces couvertes par TLS, avec un scénario concret chacune ;
• énoncer précisément ce que HTTPS ne garantit PAS — pour ne jamais surconfier.

🔗 Pour vous rafraîchir la mémoire : anatomie d'une requête HTTP

HTTP en clair : le problème démontré

Vous l'avez constaté avec nc au chapitre 9 : HTTP est du texte lisible par quiconque accède au flux. Or entre votre machine et le serveur, les paquets traversent des territoires que vous ne contrôlez pas : le Wi-Fi du café, la box, le réseau de l'opérateur, des backbones...

votre PC ── Wi-Fi café ── FAI ── Internet ── serveur
             ↑ n'importe qui sur ce Wi-Fi peut capter le trafic

Sur une connexion HTTP pure, un observateur du chemin peut tout faire :

Menace	Action	Exemple concret
Espionnage	LIRE tout ce qui circule	mots de passe, cookies de session, messages
Altération	MODIFIER en vol	injecter une pub ou un script malveillant dans la page
Usurpation	SE FAIRE PASSER pour le site	faux point d'accès Wi-Fi « Free_WiFi » qui héberge un faux site bancaire

Le pire ? Rien ne se voit côté utilisateur : la page s'affiche « normalement ». C'est toute la gravité d'un trafic non chiffré.

La réponse : TLS glissé entre TCP et HTTP

HTTPS = HTTP + TLS (Transport Layer Security), une couche insérée précisément entre transport et application :

HTTP          (application — inchangé !)
   ↓
TLS           ← chiffrement + intégrité + authentification
   ↓
TCP / IP      (transport — inchangé)

Deux changements visibles seulement : le port passe de 80 à 443, l'URL de http:// à https://. Le protocole applicatif lui-même est IDENTIQUE — vous pourriez parler HTTP à la main comme au chapitre 9 ; TLS chiffrerait chaque octet avant qu'il ne touche le réseau. Souvenez-vous d'ailleurs de curl -v, qui affichait la ligne :

* TLS 1.3 connection using TLS_AES_128_GCM_SHA256

— vous avez déjà vu le handshake sans savoir le lire. C'est maintenant fait.

Les trois garanties, menaces en face

Menace	Garantie TLS	Moyen technique
Espionnage	Confidentialité	chiffrement : le flux capté est illisible
Altération	Intégrité	codes d'authentification : tout octet modifié rend le paquet rejetable
Usurpation	Authentification	certificat signé par une autorité : le serveur prouve son identité

Chaque garantie répond exactement à UNE menace de la liste précédente — c'est le même tableau, retourné. La prochaine leçon détaille les mécanismes (clés, certificats, handshake) ; retenez aujourd'hui la cartographie.

Un bénéfice indirect mais majeur : ces garanties sont mutuelles avec la confiance des utilisateurs. Mots de passe, paiements, messageries : aucun usage sérieux du web serait possible si n'importe quel voisin de Wi-Fi pouvait lire le flux. C'est pourquoi le web moderne est passé à ~95 % de HTTPS, et pourquoi les navigateurs marquent désormais HTTP « Non sécurisé ».

Ce que HTTPS ne garantit pas — la partie honnête

Trois limites à graver, chacune source de malentendus fréquents :

1. Que le site soit honnête. Un site malveillant peut parfaitement avoir un certificat valide : le cadenas dit « le tunnel jusqu'à CE serveur est sûr », pas « ce serveur est de confiance ». Le phishing exploite précisément ce malentendu ;
2. Que vos données soient privées CHEZ le serveur. TLS protège le TRANSPORT, rien d'autre. Arrivées au serveur, vos données vivent en clair dans sa RAM, sa base, ses sauvegardes. Le hachage des mots de passe (chapitre authentification) existe pour ça — TLS ne s'en charge pas ;
3. L'anonymat. Même chiffré, le flux révèle QUEL domaine vous contactez (le DNS de la leçon précédente circule souvent en clair) et des métadonnées (tailles, horaires). Confidentialité du contenu ≠ anonymat de la communication.

Formule-synthèse à retenir : le cadenas couvre le trajet, pas le voyageur ni la destination.

Exercice

1. Un attaquant installé sur le même Wi-Fi peut-il lire vos échanges avec un site en HTTPS ? Avec un site en HTTP ? Que voit-il exactement dans le cas HTTPS ?
2. Un site affiche le cadenas : pouvez-vous lui confier n'importe quelle donnée sans crainte ?
3. Où se situe la frontière EXACTE de la protection TLS ? Nommez ce qui vit avant et après.
4. Votre application envoie le mot de passe de l'utilisateur vers votre API en HTTPS. Pourquoi faut-il quand même le hacher avant stockage ?

Résumé

• HTTPS = HTTP identique enveloppé dans TLS (port 443).
• Trois garanties face aux trois menaces : confidentialité/espionnage, intégrité/altération, authentification/usurpation.
• Limites : site honnête non garanti, données serveur hors périmètre, anonymat absent.
• Formule : le cadenas couvre le trajet, pas le voyageur ni la destination.