La requête que votre redirection ne voit jamais
Presque tous les sites dotés d'un certificat font la même chose : répondre sur le port 80 par un 301 vers l'adresse https://. C'est correct, et vous devez le garder. Cela arrive simplement une requête trop tard.
Quand quelqu'un tape example.com dans la barre d'adresse, suit un lien depuis un vieil e-mail, ou ouvre un favori vieux de plusieurs années, le navigateur n'a aucune raison de supposer le HTTPS. Il ouvre une connexion HTTP en clair et demande la page. Votre redirection répond — mais la question a déjà été envoyée en clair, sur quel que soit le réseau où se trouve le visiteur : un café, un aéroport, un hôtel, un portail captif, un routeur domestique que personne n'a mis à jour.
Quiconque est en position de lire cette requête est aussi en position d'y répondre. Au lieu de relayer votre 301, il sert sa propre copie de votre site en HTTP et fait discrètement transiter tout le reste vers vous en HTTPS. Le visiteur voit une page qui a l'air correcte, à part un cadenas que presque personne ne vérifie, et y tape un mot de passe. On appelle cela le SSL stripping, et c'est une attaque de rétrogradation visant précisément la requête que votre redirection est censée corriger.
HSTS supprime cette requête du monde. Une fois que le navigateur a vu l'en-tête, il réécrit http://example.com/... en https://... en interne, avant que quoi que ce soit ne quitte l'appareil. Il n'y a plus de requête en clair à intercepter, ni d'avertissement de certificat que le visiteur pourrait ignorer d'un clic.
Ce que dit l'en-tête
Strict-Transport-Security: max-age=31536000 est en pratique l'essentiel de la chose. Trois réglages peuvent y figurer, et ils diffèrent énormément quant à ce à quoi ils vous engagent.
max-age est le seul obligatoire : combien de secondes le navigateur doit se souvenir que cet hôte est HTTPS uniquement. 31536000, c'est un an. L'horloge se réinitialise à chaque réponse, donc un site activement visité conserve en permanence une année entière devant lui, tandis qu'un site que personne ne visite finit par l'oublier.
includeSubDomains étend la règle à tous les noms sous le vôtre — www, api, shop, staging, et celui que vous aviez oublié. C'est réellement plus fort, parce qu'un cookie posé sur un domaine parent peut être attaqué via n'importe lequel de ses sous-domaines. C'est aussi le réglage qui casse des choses, parce qu'il s'applique à des hôtes que vous ne contrôlez peut-être pas et pour lesquels vous n'avez peut-être pas de certificats.
preload demande que votre domaine soit compilé directement dans les navigateurs, de sorte que le HTTPS uniquement s'applique avant même qu'un visiteur ne soit jamais venu sur votre site. Il exige includeSubDomains et un max-age long, et il est très difficile de faire marche arrière.
Une règle sous-tend les trois : l'en-tête ne compte que sur une réponse HTTPS. Les navigateurs l'ignorent délibérément en HTTP simple, parce que l'honorer là permettrait à n'importe qui sur le réseau d'épingler un domaine qu'il ne possède pas.
Pourquoi nous n'envoyons que max-age
Le préréglage sur cdn.com.tr envoie max-age=31536000 et rien d'autre. C'est un choix par défaut délibéré plutôt qu'une limitation, et cela vaut la peine de comprendre à quoi vous engageraient les deux autres réglages.
includeSubDomains atteint des noms qui ne sont pas sous vos yeux sur la page où vous l'avez activé : un vieil hôte mail. sur un serveur ancien, une page status., un outil interne sur un sous-domaine qui répond en HTTP simple depuis des années. Dès qu'un navigateur a la règle, chacun d'eux devient inaccessible dans ce navigateur — pas un avertissement, un échec pur et simple — et retirer l'en-tête ne répare rien, parce que le navigateur a déjà consigné la règle.
preload échoue dans le même sens, seulement plus lentement : le retrait est une soumission à une liste tierce suivie d'une attente que les versions des navigateurs se déploient, mesurée en mois.
Un max-age d'un an sur le nom d'hôte que vous servez réellement vous donne tout le bénéfice de sécurité pour ce nom d'hôte dès la première visite. Les réglages plus stricts valent la peine d'être ajoutés plus tard, délibérément, une fois que chaque nom sous votre domaine a été inventorié et basculé en HTTPS. Commencez là où vous pouvez être sûr plutôt que là où vous pourriez le regretter.
La liste de vérifications avant de l'activer
HSTS n'est pas risqué. L'activer sur un site qui n'est pas prêt l'est. Passez d'abord en revue ce qui suit.
Chaque page se charge en HTTPS. Pas seulement la page d'accueil : l'espace d'administration, l'API, les points de dépôt de fichiers, les cibles de webhooks, les vieilles URL de campagne. Tout ce qui ne fonctionne que sur le port 80 cesse de fonctionner pour quiconque a vu l'en-tête.
Le certificat est valide et se renouvelle tout seul. Sous HSTS, un certificat expiré n'est plus un avertissement qu'un visiteur peut ignorer — c'est un mur. Les certificats sur cdn.com.tr sont émis et renouvelés automatiquement, ce qui est exactement la propriété que HSTS suppose que vous avez.
Le contenu mixte a disparu. Les scripts, feuilles de style, images et iframes référencés avec http:// devraient déjà être corrigés ; HSTS ne fait que rendre leur échec plus bruyant.
Vous savez ce que font vos sous-domaines. Pas parce que vous activez includeSubDomains aujourd'hui, mais parce que vous voudrez le faire un jour, et l'inventaire est le vrai travail.
Votre redirection HTTP vers HTTPS reste en place. HSTS protège les navigateurs qui ont vu l'en-tête ; la redirection rattrape tous les autres. Ce ne sont pas des alternatives l'une à l'autre.
L'activer
Dans le panneau, ouvrez Règles de diffusion → Préréglages de sécurité. Le champ « Paramètre de sécurité » est une liste à sélection multiple des préréglages de périphérie qui s'appliquent au compte : choisissez Hsts et enregistrez. La page se trouve à /management/cdn/advanced-management.
Le réglage est par compte, donc un nom d'hôte qui n'est pas encore prêt peut simplement attendre sur son propre compte au lieu de retarder les autres.
Une fois enregistré, la périphérie ajoute l'en-tête aux réponses HTTPS pour ce compte, et seulement aux réponses HTTPS — une requête HTTP simple reçoit toujours votre redirection, sans en-tête attaché, ce qui est le comportement exigé par la spécification. Rien ne change côté origine : il n'y a aucun en-tête à ajouter dans nginx, Apache ou votre framework, parce que c'est en périphérie que se décide la réponse destinée au visiteur.
Le vérifier en dix secondes
Demandez les en-têtes et cherchez la ligne. Deux résultats comptent, et le second est celui que les gens sautent.
L'en-tête appartient aux réponses HTTPS, et à elles seules
# doit afficher : strict-transport-security: max-age=31536000
curl -sI https://example.com/ | grep -i strict-transport
# ne doit rien afficher du tout
curl -sI http://example.com/ | grep -i strict-transportCe dont le navigateur se souvient
La ligne de commande vous dit ce que vous envoyez. Le navigateur, lui, est l'endroit où l'en-tête fait réellement son travail, et cela vaut la peine de confirmer une fois que la règle a bien été retenue.
Visitez le site en HTTPS, puis ouvrez un nouvel onglet et tapez le nom d'hôte seul. La barre d'adresse devrait basculer directement sur https:// — la réécriture se produit à l'intérieur du navigateur, il n'y a donc aucune requête sur le fil à intercepter, ni de redirection à suivre. Chrome expose ce qu'il a enregistré sur chrome://net-internals/#hsts, y compris l'expiration, ce qui est utile quand vous testez plutôt que de deviner.
Deux habitudes évitent la confusion ici. Testez depuis un profil de navigateur qui n'a jamais visité le site quand vous voulez observer le comportement de première visite, et souvenez-vous qu'un navigateur qui a appris la règle avant que vous ne changiez quoi que ce soit continuera d'agir en conséquence — ce qui est le sujet de la section suivante.
Revenir en arrière, et ce que le retour en arrière ne peut pas faire
Désélectionnez Hsts dans la même liste à sélection multiple et enregistrez. La périphérie cesse immédiatement d'envoyer l'en-tête, et tout navigateur qui ne l'a jamais vu se comporte normalement à partir de là.
Ce qui ne se produit pas, c'est ce qui surprend les gens : les navigateurs qui ont déjà enregistré la règle continuent de l'appliquer jusqu'à ce que leur max-age s'épuise. Désactiver le préréglage ne les atteint pas. Avec un max-age d'un an, un visiteur qui a vu l'en-tête hier continuera d'imposer le HTTPS pendant un an, quoi que dise désormais votre serveur.
La spécification prévoit bien un moyen de désamorcer ce cas — envoyer l'en-tête avec max-age=0 indique à un navigateur d'oublier la règle lors de sa prochaine visite en HTTPS. Cela ne fonctionne que tant que le site reste accessible en HTTPS, et il faut continuer à l'envoyer jusqu'à ce que les navigateurs qui vous intéressent soient revenus, donc c'est une retraite planifiée plutôt qu'un interrupteur.
C'est pourquoi la liste de vérifications compte plus que le plan de retour en arrière. L'échec le plus probable n'est jamais « HSTS était une mauvaise idée pour nous » ; c'est « une seule URL ne fonctionnait qu'en HTTP et nous l'avons découvert après coup ». Corriger cette URL est presque toujours le chemin de retour le plus rapide.
La place de HSTS parmi vos autres protections
HSTS fait exactement une chose : il supprime la requête en clair. Cela vaut la peine d'être clair là-dessus, parce que « nous avons HSTS » se dit parfois comme si la question de la sécurité était désormais réglée.
Ce n'est pas un certificat — il en suppose un valide et rend un certificat invalide fatal. Ce n'est pas du chiffrement ; c'est TLS qui s'en charge, et HSTS garantit seulement que c'est bien TLS qui est utilisé. Il n'inspecte rien, donc il n'arrête aucune injection, aucun exploit et aucune charge malveillante : c'est le rôle d'un WAF. Il ne compte rien, donc la force brute et le scraping restent le travail du rate limiting. Et il ne dit rien de qui peut vous atteindre, ce qui est le rôle du blocage par pays et par ASN.
Ce qui rend ces cinq minutes rentables, c'est le rapport. Un en-tête, un réglage, aucune maintenance continue — et toute une classe d'attaque de rétrogradation cesse d'être possible contre vos visiteurs.
Questions fréquentes
HSTS suffit-il à lui seul ?
Non, et ce n'est pas sa vocation. HSTS garantit que la connexion est chiffrée ; il ne dit rien de ce qui y transite. Une requête portant une injection SQL arrive tout aussi facilement en HTTPS qu'en HTTP. Il vient s'ajouter à un certificat valide, un WAF, du rate limiting et des règles d'accès sensées — pas à leur place.
HSTS remplace-t-il ma redirection HTTP vers HTTPS ?
Non. Gardez la redirection. HSTS ne s'applique qu'après qu'un navigateur a vu l'en-tête au moins une fois en HTTPS, donc chaque nouveau visiteur, chaque nouvel appareil et chaque robot d'indexation arrivent encore sur le port 80 et ont besoin du 301. Les deux couvrent des moitiés différentes du même problème.
Couvre-t-il mes sous-domaines ?
Pas avec ce préréglage. Il n'envoie que max-age, donc la règle s'applique au nom d'hôte exact qui a servi la réponse. Couvrir les sous-domaines exige includeSubDomains, ce qui est un engagement bien plus important : il prend effet immédiatement dans le navigateur et ne peut pas en être retiré, donc chaque nom sous votre domaine doit fonctionner en HTTPS avant d'y songer.
Devrais-je soumettre mon domaine à la liste de préchargement HSTS ?
Seulement après que le HTTPS partout soit devenu ennuyeux de banalité pendant des mois. Le préchargement place votre domaine à l'intérieur du navigateur, il protège donc même la toute première requête d'un visiteur — mais le retrait nécessite une soumission à un tiers et une attente des versions du navigateur, donc une erreur dure longtemps. Un max-age d'un an vous donne l'essentiel du bénéfice tout en gardant un chemin de retour.
HSTS protège-t-il la toute première visite de quelqu'un ?
En soi, non — c'est la seule faille qu'il laisse ouverte. La première visite est ce qui apprend la règle au navigateur, et elle est protégée par votre redirection et un certificat valide plutôt que par HSTS. Le préchargement est le seul moyen de combler cette faille, c'est pourquoi la liste existe.
Cela affectera-t-il les performances ?
Marginalement, et en votre faveur. L'en-tête pèse quelques dizaines d'octets, et une fois qu'un navigateur l'a reçu, chaque lien http:// vers votre site est réécrit à l'intérieur du navigateur au lieu de coûter un aller-retour vers votre redirection. Les visiteurs qui passaient auparavant par un 301 l'évitent complètement.