Résumé

  • Un site transmettait Strict-Transport-Security après une connexion HTTPS sans erreur. Le navigateur mémorisait alors la règle pour les visites suivantes. La RFC 6797 nommait la première requête HTTP vers un hôte inconnu comme une fenêtre d’attaque.
  • En juin 2011, l’équipe Chromium annonçait que la navigation initiale vers Gmail passerait en HTTPS. La RFC de 2012 décrivait ensuite les listes préchargées par les fabricants de navigateurs comme réponse à cette fenêtre.

La consigne attendait de l’autre côté

Dans leur article ForceHTTPS de 2008, Collin Jackson et Adam Barth proposaient qu’un site, ou l’utilisateur, impose au navigateur un traitement strict de HTTPS. Leur extension Firefox expérimentale redirigeait les connexions non sécurisées, arrêtait la session en cas d’erreur de certificat et bloquait les contenus intégrés en HTTP. Les navigateurs toléraient des déploiements imparfaits pour ne pas casser les sites. La proposition donnait une voix aux exploitants qui voulaient une règle plus ferme.

La RFC 6797 a mis cette règle dans l’en-tête de réponse Strict-Transport-Security. Reçu sur une connexion sûre et sans erreur, il faisait du site un hôte HSTS connu pendant la durée max-age. Reçu en HTTP, il devait être ignoré. Un attaquant présent sur le canal non chiffré ne devait pas pouvoir dicter la politique censée le tenir à l’écart.

Le problème tenait à l’ordre des événements. Quand un navigateur neuf suivait un lien http vers un site encore inconnu, il n’avait aucun en-tête HSTS en mémoire. La RFC appelait cela la vulnérabilité d’amorçage face à un intermédiaire. Le serveur ne pouvait envoyer sa consigne qu’après le trajet initial. Une redirection ultérieure ne reprenait pas le contrôle de cette première requête.

La liste voyageait avec le logiciel

Le 14 juin 2011, l’équipe de sécurité de Chromium présentait deux réponses. Chromium 12 permettait aux utilisateurs avancés de forcer HTTPS pour les domaines choisis. Pour Chromium 13, l’équipe annonçait que toutes les connexions à Gmail, y compris une première visite après la saisie de gmail.com ou mail.google.com, prendraient HTTPS. Elle décrivait aussi des erreurs de certificat que l’utilisateur ne pourrait contourner. Le navigateur connaissait donc certains sites avant de les contacter.

La section 12.3 de la RFC 6797 décrivait la liste HSTS préchargée : un administrateur de site pouvait demander à un fabricant de navigateur d’inscrire sa politique dans le logiciel distribué. La documentation de Chromium explique la vulnérabilité d’une installation neuve ou d’un état local effacé, puis le rôle de sa liste. Pour les domaines retenus, le navigateur prend la décision avant la première réponse. L’exploitant doit fournir HTTPS ; l’éditeur du navigateur choisit les noms livrés avec le programme.

C’est ce deuxième choix qui changeait la première visite. L’en-tête protégeait celui qui avait déjà atteint le site sans incident. La liste protégeait celui dont le navigateur avait reçu la règle par un autre chemin. Une liste archivée de Chromium 13 et des mesures des premières visites diraient exactement quels domaines et usagers en ont profité. Les archives disponibles établissent le mécanisme et le déplacement de l’autorité.

Sources