HTTP Strict Transport Security est un mécanisme de politique de sécurité qui aide à protéger les sites Web contre les attaques par rétrogradation de protocole et le détournement de cookies. Il permet aux serveurs Web de déclarer que les navigateurs ne doivent interagir avec eux que via des connexions HTTPS sécurisées. Une fois configuré, HSTS empêche les utilisateurs de contourner les avertissements de certificat et garantit des connexions cryptées.
HTTP Strict Transport Security est un en-tête de réponse qu'un serveur envoie en HTTPS, par exemple Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Dès qu'un navigateur le voit, il retient pour la durée indiquée par max-age que cet hôte ne doit être joint qu'en HTTPS. Pendant cette période, le navigateur réécrit tout lien http:// vers le site en https:// avant qu'une requête ne quitte la machine, et il transforme les avertissements de certificat TLS habituellement contournables en erreurs strictes et impossibles à ignorer. L'option includeSubDomains étend la règle à chaque sous-domaine, et preload permet d'intégrer la politique directement dans les navigateurs afin qu'elle s'applique dès la toute première visite.
Une simple redirection du HTTP vers le HTTPS expose tout de même une requête non sécurisée, et cette première requête est précisément l'endroit où opère un attaquant par SSL stripping : il se place sur le réseau, conserve sa propre connexion en HTTP clair avec la victime, et relaie discrètement vers le vrai site en HTTPS, récoltant au passage cookies et identifiants. HSTS supprime cette fenêtre en refusant purement et simplement d'émettre la requête non sécurisée. Il empêche également les utilisateurs de passer outre les avertissements de certificat, ce qui déjoue les attaques man-in-the-middle reposant sur un certificat falsifié ou invalide. En résumé, HSTS transforme HTTPS d'une préférence dont l'utilisateur peut être détourné par la ruse en une garantie imposée.
Vérifiez d'abord que chaque nom d'hôte et chaque sous-ressource fonctionne réellement en HTTPS, car une fois qu'un navigateur a mis la politique en cache, il n'existe aucune échappatoire simple avant l'expiration de max-age. Déployez avec un max-age court, vérifiez que rien ne casse, puis portez-le à un an ou plus. N'ajoutez includeSubDomains que lorsque vous êtes certain qu'aucun sous-domaine n'a besoin du HTTP, et ne soumettez à la liste preload que lorsque l'ensemble de l'arborescence du domaine est prêt pour le HTTPS. HSTS fait partie de plusieurs en-têtes de sécurité ; il protège le transport, mais pas le contenu qui l'emprunte. Surveiller ce que font réellement les scripts third-party, comme le fait cside via l'analyse de charge utile, demeure une couche distincte et complémentaire.
Sans preloading, le navigateur n'a jamais vu l'en-tête : la première requête peut donc encore passer en HTTP et reste vulnérable au SSL stripping. La liste de preload HSTS résout ce problème en embarquant la politique dans le navigateur lui-même, de sorte que l'application s'impose dès la toute première connexion au domaine.
Pas pour les utilisateurs qui ont déjà mis la politique en cache. Envoyer max-age=0 indique aux navigateurs de l'oublier, mais cela ne prend effet que la prochaine fois que chaque navigateur atteint le site en HTTPS. Les domaines preloadés sont encore plus lents à retirer. C'est pourquoi vous devez tester méticuleusement la couverture HTTPS avant de vous engager sur un max-age long.
We answer client-side security questions every day. Bring yours.