Chapitre 2.3 — HTTPS/TLS : ce qu’il protège

⏱️ TL;DR — HTTPS, c’est HTTP dans un tunnel TLS. Ce tunnel garantit trois choses sur le transport : la confidentialité (personne sur le réseau ne lit le trafic), l’intégrité (personne ne le modifie en route) et l’authenticité du serveur (tu parles bien à formacampus.fr, prouvé par un certificat). C’est indispensable — mais son périmètre est le transport, point. HTTPS ne protège pas contre un XSS, une injection SQL, un IDOR, une auth faible ou un serveur compromis : ces failles vivent aux extrémités du tunnel, là où TLS ne va pas. Le cadenas dit « la ligne est sûre », pas « l’appli est sûre ».

🎯 Objectifs

• Comprendre ce que TLS garantit : confidentialité, intégrité, authenticité du transport.
• Savoir ce qu’est un certificat et comment le navigateur vérifie l’identité du serveur.
• Lister précisément ce que HTTPS ne protège pas (et pourquoi).
• Comprendre pourquoi HTTPS est un prérequis de la sécurité, pas une garantie de sécurité.

Ce que TLS met dans le tunnel

Sans HTTPS, une requête HTTP circule en clair : n’importe qui sur le chemin (un Wi-Fi public, un routeur compromis, un FAI, un attaquant en man-in-the-middle) peut lire ton mot de passe, ton cookie de session, tes données — et même modifier la page à la volée (injecter une pub, un script). Inacceptable.

TLS (Transport Layer Security, l’évolution de SSL) établit un canal chiffré entre le navigateur et le serveur, et apporte trois garanties sur ce qui transite :

Le tout est négocié lors du handshake TLS, qui met en place les clés de session. En pratique moderne, on utilise TLS 1.2 ou 1.3 ; les vieux protocoles (SSL, TLS 1.0/1.1) sont obsolètes et à désactiver côté serveur.

Le certificat : prouver « je suis bien ce serveur »

Le chiffrement ne suffirait pas : il faut aussi être sûr de à qui on parle (sinon un attaquant pourrait établir un tunnel chiffré… avec lui-même). C’est le rôle du certificat.

Un certificat TLS lie un nom de domaine à une clé publique, et il est signé par une autorité de certification (CA) en qui les navigateurs ont confiance. À la connexion, le serveur présente son certificat ; le navigateur vérifie qu’il est :

• signé par une CA de confiance (chaîne de confiance jusqu’à une racine connue) ;
• valide dans le temps (pas expiré) ;
• émis pour le bon domaine (le nom correspond à l’URL).

Si l’une de ces vérifications échoue, le navigateur affiche un avertissement (le fameux « votre connexion n’est pas privée »). Let’s Encrypt fournit gratuitement ces certificats (validité 90 jours, renouvellement automatique) — voir le cours Serveur Linux pour la mise en œuvre avec Certbot.

📚 La source — Les détails des suites cryptographiques, versions de TLS et politiques de certificat évoluent. Pour la config serveur (protocoles à activer, ciphers, HSTS), la référence pratique est le Mozilla SSL Configuration Generator et le test SSL Labs ; côté OWASP, la Transport Layer Protection Cheat Sheet. On enseigne ici le rôle de TLS, pas une liste de ciphers qui vieillira.

Ce que HTTPS ne protège PAS (le point crucial)

C’est le message le plus important du chapitre, car c’est un malentendu extrêmement répandu : « on est en HTTPS, donc on est sécurisés ». Faux. HTTPS sécurise le transport, c’est-à-dire le trajet entre les deux extrémités. Les failles applicatives, elles, vivent aux extrémités — dans ton code serveur et dans le navigateur — là où le tunnel s’ouvre et où les données sont en clair pour être traitées.

HTTPS ne fait rien contre :

• Le XSS : le script malveillant s’exécute dans le navigateur, après déchiffrement. TLS a livré fidèlement… du HTML piégé.
• L’injection SQL : la requête concaténée s’exécute sur le serveur, après déchiffrement. TLS a transporté fidèlement… un payload d’injection.
• Le broken access control / IDOR : le serveur renvoie les données d’un autre utilisateur, chiffrées impeccablement jusqu’à l’attaquant.
• Une authentification faible : un mot de passe « 123456 » passe très bien dans un tunnel TLS.
• Un serveur compromis, une dépendance vérolée, un secret qui fuit : hors périmètre de TLS.
• Le phishing : un site formaçampus.fr (avec une cédille) peut avoir un certificat parfaitement valide pour son domaine — le cadenas ne dit pas « site honnête », il dit « connexion chiffrée vers ce domaine-là ».

⚠️ Piège — Le cadenas vert (ou l’icône) dans la barre d’adresse ne signifie pas « ce site est sûr / honnête ». Il signifie « la connexion vers ce domaine est chiffrée et le domaine est authentifié ». Un site de phishing en HTTPS avec un certificat Let’s Encrypt valide affiche le même cadenas que ta banque. Ne confonds jamais sécurité du transport et sécurité/honnêteté de l’application.

Alors pourquoi HTTPS est-il indispensable ?

Parce qu’il est le prérequis de tout le reste. Sans lui, toutes tes autres défenses fuient : le cookie Secure n’a de sens qu’en HTTPS, l’attribut HttpOnly ne sert à rien si le cookie part en clair sur le réseau, une auth solide est inutile si le mot de passe est sniffable en transit. HTTPS n’est pas « la » sécurité, c’est le sol sur lequel les autres couches tiennent. On le complète immédiatement par HSTS (chapitre 2.4) pour forcer son usage.

💡 Réflexe — Formule à garder : HTTPS est nécessaire mais pas suffisant. Nécessaire (aucune sécurité applicative ne tient sans lui), pas suffisant (il ne touche pas aux failles applicatives). Quand quelqu’un dit « c’est bon, on est en HTTPS », entends « le transport est protégé » — et continue à sécuriser le reste.

🧭 Sur FormaCampus — FormaCampus est en HTTPS partout (front app. et API api.), certificats Let’s Encrypt auto-renouvelés, TLS 1.2/1.3 seulement, HTTP redirigé vers HTTPS et HSTS activé. C’est acquis — et l’équipe sait que ça ne règle rien des failles applicatives : les notes des apprenants restent exposées à un IDOR, à une injection ou à un XSS malgré le cadenas. HTTPS protège le trajet ; le reste du cours protège les extrémités.

✏️ Exercices

Exercice 1 — Vrai / Faux argumenté. Un chef de projet affirme : « Le site est passé en HTTPS, on peut retirer la protection anti-XSS et la validation d’entrée, c’est chiffré maintenant. » Réponds.

Exercice 2 — Le cadenas trompeur. Une victime reçoit un lien vers https://formacampuz-connexion.fr (avec un « z »), voit le cadenas, et fait confiance. Explique pourquoi le cadenas est présent alors que le site est un piège.

🧠 Quiz de révision

Chapitre suivant : En-têtes de sécurité — les instructions qu’on envoie au navigateur pour le durcir : CSP, HSTS, anti-clickjacking et compagnie.