Chapitre 8.1 — Pourquoi HTTPS & TLS

⏱️ TL;DR — HTTPS, c’est HTTP dans un tunnel TLS. Ce tunnel apporte trois garanties : la confidentialité (personne au milieu ne lit le trafic), l’intégrité (personne ne le modifie sans être détecté) et l’authenticité (tu parles bien au vrai formacampus.fr, pas à un imposteur). En clair, sans lui : mots de passe lisibles, pages injectées par le wifi de l’aéroport, navigateur qui affiche « Non sécurisé », SEO pénalisé, et la moitié des APIs web qui refusent de démarrer. Le cœur technique tient en deux idées : un handshake au début de la connexion (le serveur prouve son identité avec un certificat et on se met d’accord sur une clé secrète), puis du chiffrement symétrique rapide pour tout le reste. Le certificat est signé par une autorité de certification (CA) que ton navigateur connaît déjà — c’est la chaîne de confiance. Let’s Encrypt est une CA gratuite et automatisée : c’est elle qu’on utilisera.

🎯 Objectifs

• Nommer les trois garanties de TLS et ce qu’on risque sans chacune.
• Lister les raisons pour lesquelles HTTPS est obligatoire (et pas juste recommandé).
• Décrire le handshake TLS en clair, sans jargon cryptographique.
• Comprendre ce qu’est un certificat, une CA, et la chaîne de confiance.
• Distinguer certificat auto-signé, certificat d’une CA payante et Let’s Encrypt.

HTTP en clair : ce que tout le monde peut voir

Une requête HTTP « normale » circule en texte lisible sur le réseau. Entre le navigateur du visiteur et ton serveur, il y a une dizaine d’équipements : sa box, son opérateur, le wifi du café, des routeurs. Chacun peut lire ce qui passe, et rien ne l’empêche de le modifier au passage.

Concrètement, sans HTTPS :

• Un visiteur se connecte à FormaCampus depuis un wifi public → son mot de passe part en clair, quiconque écoute le réseau le capte.
• Le fournisseur d’accès (ou un attaquant en position d’homme du milieu) peut injecter une pub, un script malveillant, ou modifier un montant dans une page.
• Le visiteur n’a aucune preuve qu’il parle à ton serveur : un attaquant peut se faire passer pour formacampus.fr et récolter tout ce qu’on lui envoie.

TLS répond aux trois d’un coup.

🔒 Sécurité — Retiens l’ordre : TLS ne fait pas que chiffrer. L’authenticité est tout aussi cruciale — un tunnel chiffré vers un imposteur ne protège de rien. C’est le certificat, validé par une autorité de confiance, qui garantit que le tunnel arrive bien chez toi. Chiffrement sans authentification = fausse sécurité.

Pourquoi c’est obligatoire, pas optionnel

En 2026, servir un site en HTTP nu n’est plus « pas idéal » : c’est cassé. Les raisons s’empilent.

• Le navigateur te dénonce. Chrome, Firefox et les autres affichent « Non sécurisé » sur toute page HTTP, et barrent carrément les formulaires de mot de passe. Le cadenas fermé, à l’inverse, rassure le visiteur en un coup d’œil.
• Le SEO. Les moteurs de recherche utilisent HTTPS comme signal de classement et privilégient les sites sécurisés. Un site en HTTP part avec un handicap.
• Les APIs web modernes l’exigent. Une longue liste de fonctionnalités du navigateur ne s’active que sur une origine sécurisée (« secure context ») : service workers (donc les PWA), géolocalisation, notifications, accès caméra/micro, Clipboard, et bien d’autres. En HTTP, elles sont désactivées.
• HTTP/2 et HTTP/3 ne sont, en pratique, servis par les navigateurs que sur TLS. Pas de HTTPS = tu restes sur HTTP/1.1, plus lent.
• La confiance, tout simplement. Personne ne saisit sa carte ni son mot de passe sur un site marqué « Non sécurisé ».

💡 Réflexe — Ne te demande plus « ai-je besoin de HTTPS ? ». La réponse est oui, toujours, même pour un site vitrine sans formulaire. C’est gratuit, automatisable, et ça débloque tout le web moderne. La seule question qui reste est comment l’installer proprement — c’est l’objet des chapitres suivants.

TLS ou SSL ? Une histoire de vocabulaire

Tu verras les deux termes partout, souvent mélangés (« certificat SSL », « SSL/TLS »). Mettons les choses au clair :

• SSL (Secure Sockets Layer) est l’ancêtre, conçu dans les années 90. Toutes ses versions sont aujourd’hui obsolètes et dangereuses (vulnérabilités connues) : on ne les active plus jamais.
• TLS (Transport Layer Security) est le successeur, celui qu’on utilise réellement. Les versions vivantes sont TLS 1.2 et TLS 1.3 (la plus récente et la plus rapide).

Dans le langage courant, « SSL » a survécu par habitude — on dit « certificat SSL » alors qu’on utilise techniquement TLS. Ce n’est pas grave, mais sache que derrière le mot SSL, c’est bien TLS qui tourne. Dans ce cours, on dit TLS.

Le handshake TLS, en clair

Quand un navigateur ouvre une connexion HTTPS (sur le port 443), il y a d’abord une poignée de main (handshake) avant le moindre octet de ta page. Voici l’idée, simplifiée mais fidèle :

Décortiquons les étapes qui comptent :

1. Client hello. Le navigateur annonce les versions de TLS et les algorithmes de chiffrement qu’il sait gérer.
2. Le certificat. Le serveur répond en présentant son certificat. Ce certificat contient son nom de domaine, sa clé publique, et une signature d’une autorité de certification.
3. La vérification. Le navigateur vérifie ce certificat : est-il signé par une CA en laquelle j’ai confiance ? Correspond-il bien au domaine demandé ? N’est-il pas expiré ni révoqué ? Si un seul de ces contrôles échoue → avertissement de sécurité rouge.
4. La clé de session. À l’aide de la cryptographie asymétrique (clé publique/privée), les deux camps se mettent d’accord sur une clé secrète partagée, connue d’eux seuls, sans jamais l’envoyer en clair sur le réseau.
5. Bascule en symétrique. Une fois cette clé établie, tout le reste de l’échange (ta page, les images, l’API) est chiffré avec un algorithme symétrique, beaucoup plus rapide. L’asymétrique n’a servi qu’à installer le secret ; le symétrique fait le gros du travail.

📚 La doc — Tu n’as pas à implémenter ce handshake : Nginx et OpenSSL le font pour toi. Mais la mécanique aide à déboguer (« pourquoi ce cert est-il rejeté ? »). Pour le détail, la référence officielle de TLS 1.3 est la RFC 8446, et la doc de Let’s Encrypt explique bien les concepts côté certificats.

Le certificat et la chaîne de confiance

Un certificat est un fichier qui lie un nom de domaine à une clé publique, le tout signé par une autorité de certification. C’est cette signature qui fait toute la valeur : n’importe qui peut générer une clé et prétendre être formacampus.fr, mais seule une CA reconnue peut produire une signature que les navigateurs acceptent.

Pourquoi ton navigateur fait-il confiance à cette signature ? Grâce à la chaîne de confiance, un système à trois étages :

• Au sommet, des CA racines dont les clés publiques sont préinstallées dans ton navigateur et ton système d’exploitation. C’est le socle de confiance : tu leur fais confiance « par défaut ».
• Une racine signe des CA intermédiaires (par sécurité, la racine reste hors ligne et ne signe pas directement les certificats du quotidien).
• L’intermédiaire signe ton certificat de domaine.

Quand le navigateur reçoit ton certificat, il remonte la chaîne jusqu’à une racine qu’il connaît. Si la chaîne est complète et valide → cadenas vert. Si un maillon manque (erreur fréquente : oublier de servir le certificat intermédiaire) → avertissement, alors même que le certificat de base est bon.

⚠️ Piège — Une chaîne incomplète est un grand classique : ton certificat est valide, mais tu n’as pas fourni le certificat intermédiaire avec. Résultat : ça marche dans ton navigateur (qui a l’intermédiaire en cache) mais casse ailleurs. Certbot, qu’on verra au chapitre suivant, installe la chaîne complète (fullchain.pem) tout seul — d’où l’intérêt de le laisser faire plutôt que de bricoler à la main.

Auto-signé, CA payante, ou Let’s Encrypt ?

Trois façons d’obtenir un certificat, très inégales :

• Auto-signé. Tu génères toi-même un certificat, signé par… toi. Techniquement valide pour chiffrer, mais aucun navigateur ne te fait confiance (tu n’es pas une CA reconnue) → gros avertissement rouge. Utile uniquement en interne ou pour des tests locaux, jamais pour un site public.
• CA commerciale payante. Tu achètes un certificat auprès d’une autorité reconnue. Ça marche, mais c’est payant, souvent manuel, et pour un simple certificat de domaine ça n’apporte rien de plus que le gratuit en termes de chiffrement.
• Let’s Encrypt. Une CA gratuite, reconnue par tous les navigateurs, et surtout automatisée de bout en bout. Tu obtiens un certificat en une commande, il se renouvelle tout seul. C’est le choix par défaut pour un serveur moderne, et celui de ce cours.

🧭 Sur FormaCampus — L’équipe a besoin de HTTPS sur trois noms : formacampus.fr, www.formacampus.fr (le front Next.js) et api.formacampus.fr (l’API Symfony). Sur son ancien PaaS, le certificat était « inclus, magique, invisible ». En rapatriant sur son VPS, elle doit le gérer elle-même — mais grâce à Let’s Encrypt, ça reste gratuit et automatique. Zéro ligne de budget certificat, un seul geste d’installation, renouvellement sans intervention. Exactement ce qu’on met en place dans les chapitres 8.2 et 8.3.

Où ça se branche dans l’architecture

Souviens-toi de la Partie 7 : c’est Nginx qui « termine » le TLS. Le navigateur établit le tunnel chiffré avec Nginx (sur le port 443) ; Nginx déchiffre, puis relaie la requête en clair à ton app locale (sur 127.0.0.1:3000, par exemple), qui n’a pas à se soucier de cryptographie. La réponse fait le chemin inverse : l’app répond en clair à Nginx, qui rechiffre et renvoie au visiteur. Le certificat vit donc au niveau de Nginx — et c’est là que Certbot va le poser.

✏️ Exercices

Exercice 1 — Nomme la garantie. Pour chaque situation, dis quelle garantie de TLS est en jeu : (A) un attaquant sur le wifi lit le mot de passe d’un visiteur ; (B) un opérateur injecte une bannière de pub dans une page ; (C) un faux serveur se fait passer pour ton domaine.

Exercice 2 — Le certificat rejeté. Un collègue génère un certificat auto-signé pour son site public et s’étonne que tous les visiteurs voient un avertissement de sécurité rouge, alors que « le certificat est valide ». Explique-lui le problème et la solution.

Exercice 3 — Symétrique ou asymétrique ? Pendant le handshake, on utilise de la cryptographie asymétrique ; ensuite, du symétrique. Pourquoi ne pas tout faire en asymétrique, puisque c’est ce qui permet la vérification d’identité ?

🧠 Quiz de révision

Chapitre suivant : Certbot & Let’s Encrypt — obtenir un vrai certificat, gratuit, en une seule commande.