Qu’est-ce que le HSTS et comment le configurer ?
HTTPS est très sécurisé, mais il présente un défaut: il n’est pas activé par défaut. Un attaquant au milieu pourrait détourner la connexion d’un utilisateur avant que vous ne puissiez lui dire d’utiliser HTTPS. HSTS résout ce problème et active HTTPS à l’échelle du site.
Avoir le cryptage SSL en premier lieu est une condition préalable pour HSTS, car sinon l’activation de HSTS rendra simplement votre site inaccessible. Vous pouvez lire notre guide sur la configuration de certificats SSL gratuits avec LetsEncrypt pour activer HTTPS sur votre site Web.
Sommaire
Comment fonctionne le HSTS?
HSTS signifie HTTP Strict Transport Security et régit la manière dont le navigateur d’un utilisateur doit se connecter à votre site Web.
Voici comment fonctionne généralement la connexion à votre site. Un utilisateur souhaite se connecter à votre site Web et envoie une demande de connexion à votre serveur. Votre serveur fait la chose responsable et envoie une réponse 301 Moved définitivement au navigateur, lui indiquant que l’adresse HTTP qu’il a demandée doit être redirigée vers HTTPS. L’utilisateur continue normalement en naviguant en toute sécurité.
Cependant, un attaquant ayant le contrôle de la connexion (comme c’est le cas avec les attaques man-in-the-middle) pourrait facilement bloquer la réponse 301 et prendre le contrôle de la session de navigation de cet utilisateur. Il s’agit d’un problème majeur, car il va à l’encontre de l’objectif de chiffrement du site en premier lieu.
Avec HSTS activé, le serveur envoie la même réponse 301 Moved définitivement, mais envoie également un en-tête disant: « Hé, je ne supporte pas HTTP. N’essayez même pas de faire plus de requêtes HTTP, car je vais toutes les rediriger. » Le navigateur reçoit le message et se redirige vers HTTPS avant d’envoyer quoi que ce soit. Cela garantit que votre site est entièrement HTTPS, par défaut, tout le temps.
Préchargement HSTS
Cependant, le HSTS standard présente un défaut majeur: la toute première connexion établie par un utilisateur n’est toujours pas sécurisée. Si un utilisateur a déjà utilisé votre site, le navigateur respectera la demande HSTS à l’avenir. Mais la réponse initiale HSTS n’est pas sécurisée, donc si un utilisateur navigue dans un café et ouvre votre site pour la première fois (ou, pour la première fois sur un appareil mobile), sa connexion peut toujours être piratée.
Le préchargement HSTS est une initiative du projet Chromium pour résoudre ce problème. Le projet Chromium maintient une liste de sites Web sur lesquels le HSTS est activé en permanence. Cette liste est intégrée à la plupart des principaux navigateurs, et le navigateur la vérifie avant de faire des demandes à de nouveaux sites.
Si vous êtes sur la liste, même si un utilisateur n’a jamais interagi avec votre site auparavant, il agira comme s’il avait déjà vu votre en-tête HSTS et ne communiquera jamais avec HTTP. Cela rend la connexion entièrement sécurisée dès le départ.
Activer HSTS et rejoindre la liste de préchargement
HSTS peut être activé avec un simple en-tête, qui est ajouté à toutes les réponses envoyées par votre serveur:
Strict-Transport-Security: max-age=300; includeSubDomains; preload
Vous pouvez l’inclure dans le fichier de configuration de votre serveur Web. Par exemple, dans Nginx, vous pouvez définir l’en-tête en incluant un add_header ligne dans votre bloc serveur:
add_header Strict-Transport-Security 'max-age=300; includeSubDomains; preload; always;'
Et pour Apache, la commande est similaire, en utilisant le Header always set ligne:
Header always set Strict-Transport-Security "max-age=300; includeSubDomains; preload"
Cependant, il y a quelques étapes supplémentaires pour s’assurer que tout fonctionne correctement et pour être éligible au préchargement.
Tout d’abord, assurez-vous que vous redirigez toutes les requêtes HTTP vers HTTPS. Sur Nginx, vous pouvez le faire en écoutant toutes les requêtes du port 80 (HTTP) et en envoyant une requête 301 avec l’URL modifiée en équivalent HTTPS:
server {
listen 80;
return 301 https://$host$request_uri;
}
Pour bénéficier du préchargement, vous devez également vous assurer que tous vos sous-domaines sont couverts par votre certificat SSL et que vous les diffusez via HTTPS. Vous pouvez le faire avec un certificat générique, que vous pouvez obtenir gratuitement auprès de LetsEncrypt. Si vous n’effectuez pas de préchargement, ce n’est pas nécessaire mais est toujours conseillé.
Vous pouvez vérifier si HSTS fonctionne correctement en chargeant votre site avec l’en-tête activé, puis en accédant à chrome://net-internals/#hsts et en entrant le nom de votre site dans l’outil de recherche «Query HSTS / PKP domain». Si votre site affiche une sortie comme celle-ci, HSTS est activé.
De plus, vous devez vérifier si le strict-transport-security l’en-tête est inclus dans les en-têtes de réponse de votre site, ce que vous pouvez faire à partir de l’onglet Réseau de la console de développement Chrome:
Une fois que vous avez fait tout cela, vous devez vérifier que tout fonctionne et que rien ne s’est cassé lorsque vous avez activé le HSTS. S’il n’y a pas de problème, vous pouvez vous rendre sur la page de soumission de préchargement, saisir votre nom de domaine et soumettre votre site Web.
Problèmes de préchargement HSTS et HSTS
Avec HSTS, votre site est désormais obligé d’utiliser HTTPS pour tout. Cela inclut tous les sous-domaines, même les outils internes. Chaque sous-domaine que vous avez doit avoir un certificat SSL valide et être sécurisé avec HTTPS, sinon il sera inaccessible pendant la durée de l’en-tête HSTS (qui peut aller jusqu’à deux ans). Si vous disposez d’un certificat générique, vous pouvez résoudre certains de ces problèmes, mais vous devez effectuer des tests avant de l’activer pendant une longue période.
Le principal problème avec le préchargement HSTS est qu’il est très permanent. Le minimum max-age est d’un an, et une fois que votre site est inscrit sur la liste, vous ne pouvez pas quitter la liste sans passer par un long processus de suppression obligeant chaque utilisateur à effectuer une mise à jour du navigateur pour appliquer les modifications.
Vous pouvez consulter cette méta-liste des demandes de suppression pour voir quels sont les principaux problèmes dans la pratique. Uber a eu des problèmes avec les sous-domaines. Les sous-domaines de troisième niveau et de niveau supérieur peuvent ne pas être pris en charge sur les certifications génériques normales. Un site Web suédois rapporte même des revenus publicitaires considérablement inférieurs, car les annonceurs locaux ne chargent pas leurs ressources via HTTPS et HSTS bloque toutes les requêtes HTTP non sécurisées effectuées lorsque l’utilisateur est connecté à votre site Web.
La meilleure façon d’éviter ces problèmes est de déployer le HSTS par étapes avant de passer de façon permanente au préchargement. Le projet Chromium recommande d’effectuer des tests à intervalles en définissant le max-age valeur d’abord à cinq minutes pour tester que cela fonctionne:
max-age=300; includeSubDomains
Puis à une semaine pour un test plus long:
max-age=604800; includeSubDomains
Ensuite, pendant un mois, jusqu’à ce que vous soyez certain qu’il n’y a pas de problème:
max-age=2592000; includeSubDomains
Si quelque chose ne va pas et que vous définissez un très long max-age propriété, vous pouvez effacer l’indicateur local de Chrome net-internals page.
Une fois que vous êtes sûr que rien ne se passera avec le fait d’avoir uniquement HTTPS activé en permanence, vous pouvez configurer votre max-age à deux ans, ajoutez le preload directive et soumettez votre site au préchargement.
