HSTS preload : conditions d’inscription sur la liste de préchargement, risques et vérification de l’en-tête

1. Qu’est-ce que la liste de préchargement HSTS ?

HTTP Strict Transport Security est défini par la RFC 6797. Le serveur envoie Strict-Transport-Security: max-age=… en HTTPS, et le navigateur retient pendant max-age secondes que l’hôte ne doit être joint qu’en HTTPS. Tant que le navigateur d’un visiteur n’a pas reçu cet en-tête au moins une fois, rien ne protège la première requête http:// en clair, qu’un attaquant présent sur le même réseau peut intercepter. La RFC décrit cette faiblesse du premier contact et évoque des politiques préconfigurées comme réponse possible.

La liste de préchargement est cette réponse, mise en pratique. Le projet Chromium la maintient, et les nouvelles entrées sont inscrites en dur dans le code source de Chrome. D’après la page HSTS du projet Chromium et hstspreload.org, Firefox, Safari et Edge tiennent leurs propres listes à partir de celle de Chrome. Dans toute version du navigateur qui contient l’entrée, un domaine préchargé n’est joignable qu’en HTTPS dès le premier lancement ; et comme les inscriptions doivent comporter includeSubDomains, il en va de même pour chaque nom situé en dessous.

Trois points sont souvent mal compris :

• La directive preload n’a aucun effet dans le navigateur. Elle ne fait pas partie de la RFC 6797, et les navigateurs ignorent les directives qu’ils ne connaissent pas. Elle indique aux responsables de la liste que le titulaire du domaine consent à l’inscription. Dès que votre en-tête la contient, n’importe qui peut soumettre votre domaine via le formulaire.
• Seuls des domaines enregistrables entiers sont inscrits. On soumet example.com, pas www.example.com ni boutique.example.com, et l’entrée couvre tous les sous-domaines, y compris les noms internes inaccessibles depuis Internet.
• Certains domaines de premier niveau sont préchargés en bloc. Tout domaine en .app ou en .dev, par exemple, est déjà limité à HTTPS dans les navigateurs qui utilisent la liste, que son titulaire ait soumis quoi que ce soit ou non.

2. Le préchargement est-il encore utile ?

Pour la plupart des sites, probablement pas. Le site de soumission lui-même indique désormais que HSTS est recommandé, mais pas le préchargement HSTS. Chrome et Safari tentent automatiquement HTTPS pour les navigations qui commencent par http://, quelle que soit la politique HSTS ; la faille de la première visite que le préchargement devait combler s’est donc nettement réduite. Selon hstspreload.org, le préchargement n’apporte une protection supplémentaire que lorsque ces bascules automatiques échouent à cause d’un attaquant actif, et son bénéfice reste minime par rapport à HSTS lui-même.

Il peut malgré tout se justifier si les trois conditions suivantes sont réunies :

• une rétrogradation dès la toute première visite compte pour vous, par exemple parce que vos utilisateurs se connectent ou paient depuis des réseaux publics ;
• chaque sous-domaine actuel et futur, y compris internes et hébergés par des prestataires, peut servir HTTPS avec un certificat valide ;
• vous comptez garder le domaine, et HTTPS dessus, pendant des années.

Renoncez-y, ou reportez-le, si des équipes ou des prestataires gèrent des sous-domaines que vous ne maîtrisez pas entièrement, si des hôtes internes vivent sous le domaine public, si le domaine sert une campagne éphémère ou si vous pourriez le vendre ou le céder : l’entrée suit le domaine chez son prochain titulaire tant que personne ne demande le retrait. Un en-tête HSTS bien réglé, sans preload, protège déjà chaque visiteur qui revient.

3. Les conditions exactes d’inscription

hstspreload.org vérifie ces conditions au moment de la soumission, et vous devez continuer à les remplir ensuite : un domaine qui ne les remplit plus peut être retiré, et dès que preload disparaît de l’en-tête, le domaine devient immédiatement éligible au formulaire de retrait.

La règle des redirections piège beaucoup de sites. Si https://example.com/ redirige vers https://www.example.com/, c’est cette réponse de redirection elle-même qui doit porter l’en-tête complet. L’en-tête de la page www ne compte pas, car une politique définie par www.example.com ne s’applique jamais au domaine de base. Voici un en-tête qui passe la vérification :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

4. Les risques : pourquoi le préchargement est difficile à annuler

• Le retrait prend des mois. Un retrait est une modification du code source qui n’atteint les utilisateurs qu’avec les mises à jour du navigateur. La page de retrait indique qu’il peut falloir de 6 à 12 semaines pour toucher la plupart des utilisateurs de Chrome, et peut-être davantage pour les autres navigateurs. Un navigateur jamais mis à jour conserve l’ancienne entrée.
• Les sous-domaines sans HTTPS cessent de fonctionner. Cas typiques : hôtes d’intranet résolus uniquement par le DNS interne, interfaces d’administration d’imprimantes, de routeurs ou de NAS avec certificats autosignés, serveurs de préproduction oubliés, et services de prestataires derrière un CNAME, comme un centre d’aide, une page de statut ou les liens de suivi des clics dans les e-mails, qui ne répondent qu’en HTTP. Dans un navigateur où votre domaine est préchargé, ils échouent sans possibilité de passer outre l’erreur.
• Une erreur de certificat devient bloquante. Sur un hôte HSTS, la RFC 6797 impose au navigateur de couper la connexion à la moindre erreur de certificat, sans laisser le visiteur continuer. Un certificat expiré sur n’importe quel sous-domaine bloque tout le monde jusqu’à son remplacement : automatisez le renouvellement et surveillez les dates d’expiration avant de soumettre.
• Les visiteurs réguliers gardent leur politique. Quitter la liste n’efface pas ce que les navigateurs ont appris de votre en-tête. Avec un max-age de deux ans, cette copie dure deux ans, sauf si le visiteur revient et reçoit max-age=0 en HTTPS.
• Soumission accidentelle. Un en-tête copié depuis un modèle qui contient déjà preload suffit pour que n’importe qui soumette votre domaine. Laissez la directive de côté tant que le plan de la section suivante n’est pas terminé.

5. Un plan de max-age par paliers avant la soumission

hstspreload.org recommande d’augmenter max-age par paliers, avec includeSubDomains dès le premier. À chaque palier, cherchez les pages cassées et suivez vos indicateurs (trafic, connexions, chiffre d’affaires), corrigez ce qui apparaît, puis attendez au moins la totalité du max-age du palier avant de passer au suivant. Vous pouvez d’abord faire passer les paliers à un groupe de test, mais ensuite à tous les utilisateurs.

Sous nginx, envoyez l’en-tête depuis le bloc server HTTPS avec le paramètre always, pour que les pages d’erreur le portent aussi, et gardez la redirection HTTP sur le même hôte. Une ligne add_header dans un bloc location y remplace les en-têtes définis au niveau server (module d’en-têtes de nginx).

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # palier 1 : changez la valeur à chaque palier
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

La montée par paliers prend à elle seule plus de cinq semaines. Après la soumission, selon hstspreload.org, une nouvelle entrée peut mettre plusieurs mois à atteindre la version stable de Chrome : le préchargement n’est donc jamais une solution rapide à l’approche d’une date de lancement.

6. Comment vérifier votre en-tête HSTS

Depuis un terminal, contrôlez les trois réponses qui comptent :

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

La première doit renvoyer 301 ou 308 avec Location: https://example.com/ ; elle n’a pas besoin d’en-tête HSTS, car les navigateurs ignorent HSTS reçu en HTTP simple. La deuxième doit porter strict-transport-security avec les trois directives, même si elle redirige elle-même vers www. La troisième devrait aussi l’envoyer, car un visiteur qui n’ouvre que www ne reçoit jamais la politique du domaine de base. Sous Windows, appelez curl.exe et utilisez -o NUL.

Repérez ces erreurs :

• Deux en-têtes HSTS. Quand le CDN et le serveur d’origine en ajoutent chacun un, la RFC 6797 demande au navigateur de ne traiter que le premier, et la vérification de hstspreload.org signale « Multiple HSTS headers » comme une erreur. Décidez quelle couche est responsable de l’en-tête.
• Une directive mal orthographiée. Les navigateurs écartent sans avertissement les directives inconnues : un includeSubdomain sans le s final laisse les sous-domaines sans protection, en silence.
• Absent de certaines réponses. La page d’accueil a l’en-tête, mais pas les pages d’erreur, l’API ou les fichiers statiques servis par une autre couche.

Dans les DevTools de Chrome, ouvrez le panneau Network, puis tapez http://example.com/ dans la barre d’adresse une fois que le navigateur a enregistré la politique. La première entrée affiche 307 Internal Redirect avec Non-Authoritative-Reason: HSTS : le navigateur est passé de lui-même en HTTPS, avant qu’aucune requête n’atteigne le serveur. La référence MDN détaille la syntaxe de l’en-tête.

7. Comment vérifier votre statut sur la liste de préchargement

• hstspreload.org. Saisissez le domaine dans le formulaire. Il indique si le domaine est préchargé, en attente ou absent de la liste, avec les erreurs et avertissements au regard des conditions actuelles. Un domaine en attente n’est pas encore protégé : il doit d’abord arriver dans une version du navigateur.
• chrome://net-internals/#hsts. Dans Chrome, saisissez le domaine sous « Query HSTS/PKP domain ». Les champs qui commencent par static_ proviennent de la liste intégrée à cette version du navigateur ; ceux qui commencent par dynamic_ proviennent des en-têtes que le navigateur a reçus. « Delete domain security policies » n’efface que la partie dynamique : une entrée préchargée reste en place jusqu’à ce qu’une mise à jour du navigateur la retire.
• Autres navigateurs. Firefox, Safari et Edge distribuent leurs propres copies, dérivées de la liste de Chrome, selon leur propre calendrier : un ajout ou un retrait peut donc les atteindre à des moments différents.

Refaites la vérification après tout changement de DNS, de CDN ou de certificats. hstspreload.org précise que les domaines qui ne remplissent plus les conditions pourront être retirés automatiquement à l’avenir.

8. Quitter la liste : étapes et délais du retrait

1. Continuez à servir HTTPS avec un certificat valide sur le domaine de base ; le formulaire de retrait le vérifie.
2. Envoyez un en-tête HSTS sans preload. hstspreload.org considère cet en-tête comme la demande de retrait. Gardez includeSubDomains et un max-age long si vous voulez conserver HSTS, ou envoyez max-age=0 pour le désactiver complètement.
3. Soumettez le domaine dans le formulaire de retrait.
4. Pendant l’attente, dotez d’un certificat valide le sous-domaine à l’origine de la décision, ou déplacez-le vers un autre domaine : le retrait peut mettre de 6 à 12 semaines à atteindre la plupart des utilisateurs de Chrome, et davantage pour les autres navigateurs.
5. N’envoyez plus preload, sauf si vous souhaitez être de nouveau inscrit.

max-age=0 ne fonctionne qu’en HTTPS, et seulement pour les visiteurs qui reviennent et le reçoivent. Prévoyez le cas le plus lent : un navigateur obsolète qui garde l’entrée intégrée, ou une politique de deux ans déjà enregistrée, peut continuer à imposer HTTPS longtemps après votre changement de cap.

9. Ce que montre le snapshot gratuit de Sitelemetry

Le snapshot gratuit de Sitelemetry (Launch Readiness Snapshot) lance huit contrôles passifs sur un domaine public, sans inscription, et renvoie un score avec le résultat de chaque contrôle. Deux d’entre eux concernent HSTS :

• Le contrôle des en-têtes de sécurité HTTP lit la page d’accueil du domaine saisi, après au plus cinq redirections. Il classe en moyen l’absence de Strict-Transport-Security sur une cible HTTPS et affiche la valeur observée.
• Le contrôle de redirection HTTPS signale en faible un max-age inférieur à 180 jours (15 552 000 secondes) quand vous saisissez un domaine seul ou une adresse https://. Pendant les paliers 1 à 3 du plan, ce résultat est normal.

Il ne vérifie ni includeSubDomains, ni la directive preload, ni vos sous-domaines, ni votre statut sur la liste ; pour cela, utilisez hstspreload.org et les commandes curl ci-dessus. Pour afficher d’abord le résultat des en-têtes, utilisez le vérificateur gratuit d’en-têtes de sécurité, qui lance le même snapshot. Pour le volet certificat, lisez le guide sur le certificat SSL/TLS et HSTS ; la checklist de mise en ligne d’un site replace HSTS à côté des redirections, du DNS et des autres contrôles avant le lancement.