Rétrogradation HTTP et risques liés au contenu mixte

L’en-tête HTTP Strict Transport Security (HSTS) indique aux navigateurs de se connecter à un site uniquement via HTTPS pendant une période donnée. Une fois cet en-tête reçu, le navigateur refuse les connexions HTTP et convertit automatiquement les URL http:// en URL https://.

Un en-tête HSTS typique est le suivant : "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". La valeur max-age est exprimée en secondes (31536000 = 1 an). Une fois cette valeur mise en cache, le navigateur impose HTTPS pendant un an sans aucune intervention du serveur.

Le paramètre max-age définit, en secondes, la durée pendant laquelle le navigateur doit imposer des connexions exclusivement en HTTPS. Pour les sites en production, les valeurs recommandées sont d’au moins un an (31536000).

La directive includeSubDomains étend l’application de HSTS à tous les sous-domaines. Elle empêche les attaques au cours desquelles un attaquant rétrograde la connexion d’un sous-domaine vers HTTP et l’utilise pour voler les cookies définis sans l’attribut Secure sur le domaine principal.

Les navigateurs intègrent une liste codée en dur de domaines qui utilisent toujours HTTPS, même lors de la toute première visite. Cette liste, gérée sur hstspreload.org, comprend des milliers de sites importants.

Le préchargement élimine la vulnérabilité de la première visite : sans préchargement, un visiteur venant pour la première fois pourrait être intercepté avant de recevoir l’en-tête HSTS. Les sites préchargés utilisent HTTPS dès la toute première requête, quel que soit l’état du cache HSTS.

La rétrogradation de SSL, présentée par Moxie Marlinspike lors de Black Hat 2009, est une attaque MITM qui rétrograde les connexions HTTPS vers HTTP. L’attaquant intercepte la requête HTTP initiale de l’utilisateur, envoie des requêtes HTTPS au véritable serveur au nom de l’utilisateur, puis lui retransmet le contenu via HTTP.

La victime voit normalement le contenu, mais celui-ci est transmis via HTTP. Toutes les informations d’authentification saisies sont envoyées à l’attaquant. Avant HSTS, cette attaque était très efficace, car les utilisateurs ne remarquaient pas l’absence du cadenas.

HSTS neutralise la rétrogradation de SSL, car le navigateur refuse d’établir des connexions HTTP avec les domaines inscrits dans HSTS. Même si un attaquant tente de servir une page via HTTP, le navigateur refuse simplement de se connecter et affiche une erreur.

L’application de HSTS par le navigateur a lieu avant toute requête réseau, de sorte que l’attaquant ne peut pas intervenir. La seule vulnérabilité restante est la première visite, avant la réception de HSTS ; le préchargement l’élimine.

Un contenu mixte est présent lorsqu’une page HTTPS charge des ressources via HTTP. Le contenu mixte passif comprend les images, les fichiers audio et les vidéos chargés via HTTP. Ces ressources ne peuvent pas modifier directement la page, mais elles peuvent révéler des informations sur l’utilisateur par l’intermédiaire des en-têtes HTTP et permettre le suivi.

Le contenu mixte actif comprend les scripts, les feuilles de style, les cadres intégrés et les XMLHttpRequests chargés via HTTP. Un script HTTP peut compromettre entièrement la sécurité de la page HTTPS, car il dispose d’un accès complet au DOM et peut lire les cookies ainsi que les données des formulaires.

Par défaut, les navigateurs modernes bloquent le contenu mixte actif (scripts, feuilles de style et cadres intégrés via HTTP) lorsque la page qui les contient est en HTTPS. Une erreur est affichée dans la console et la ressource n’est pas chargée.

À partir de Chrome 81 (2020), les navigateurs ont commencé à convertir automatiquement le contenu mixte passif en HTTPS. Si la version HTTPS existe, elle est chargée. Dans le cas contraire, la ressource est bloquée.

La console de développement du navigateur affiche les avertissements et les erreurs de contenu mixte. Dans Chrome, ouvrez DevTools, accédez à l’onglet Console et filtrez sur « contenu mixte ». Chaque ressource bloquée affiche l’URL non sécurisée qui doit être mise à jour.

Le panneau Sécurité de DevTools présente une vue d’ensemble complète de la sécurité : détails du certificat, informations sur la connexion et liste de toutes les ressources non sécurisées de la page.

La directive « upgrade-insecure-requests » de la Content Security Policy (CSP) indique aux navigateurs de convertir automatiquement en HTTPS toutes les requêtes HTTP effectuées depuis la page. Elle permet de gérer les contenus anciens contenant des URL HTTP codées en dur.

Contrairement au blocage du contenu mixte, upgrade-insecure-requests tente d’abord de récupérer la version HTTPS. Cette directive est utile lors d’une migration de HTTP vers HTTPS, lorsque la mise à jour de toutes les URL intégrées dans les anciens contenus serait difficile à réaliser.

Sans HTTPS, les ISP peuvent injecter du contenu dans les réponses HTTP. Plusieurs ISP ont été pris en flagrant délit d’injection de publicités dans des pages qui n’en contenaient pas, d’ajout de pixels de suivi ou d’insertion de pages d’avertissement lorsque les utilisateurs approchaient de leur plafond de données.

Cette forme d’injection de contenu est impossible sur les pages HTTPS, car la réponse est authentifiée et chiffrée. Toute modification ferait échouer la vérification du MAC TLS, ce qui provoquerait une erreur de connexion au lieu de permettre la transmission d’un contenu modifié.

Avant qu’un navigateur ait reçu un en-tête HSTS pour un domaine, la toute première visite via HTTP est vulnérable. Un attaquant peut intercepter cette requête initiale et effectuer une rétrogradation de SSL sans déclencher le moindre avertissement du navigateur.

Cette vulnérabilité de « confiance lors de la première utilisation » explique l’existence de la liste de préchargement HSTS. Soumettre un site à cette liste garantit que les navigateurs imposent HTTPS pour ce domaine dès la toute première requête, ce qui ferme entièrement la fenêtre de vulnérabilité de la première visite.

Testez votre compréhension de la sécurité stricte du transport HTTP.

HSTS indique aux navigateurs d’imposer des connexions exclusivement en HTTPS pour un domaine pendant une durée donnée. La liste de préchargement étend cette protection aux toutes premières visites en intégrant les politiques HSTS en dur dans les navigateurs.

La rétrogradation de SSL (Moxie Marlinspike, 2009) convertit HTTPS en HTTP ; HSTS la neutralise. Le contenu mixte actif (scripts HTTP sur des pages HTTPS) est bloqué par les navigateurs. La directive CSP upgrade-insecure-requests automatise la migration de HTTP vers HTTPS pour les anciens contenus.