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.

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.

Lorsque HSTS est activé, le serveur envoie la même réponse 301 Moved définitivement, mais envoie également un en-tête disant: "Hé, je ne prend pas en charge 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, l'utilisateur 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; précharge

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; précharge; toujours;'

Et pour Apache, la commande est similaire, en utilisant le En-tête toujours défini ligne:

En-tête toujours défini 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:

serveur {
  écouter 80;
  retourne 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 sécurité de transport stricte 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 devriez 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 diriger vers le préchargement de la page de soumission, entrez votre nom de domaine et soumettez votre site Web.

Problèmes avec le 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 âge max est d'un an, et une fois que votre site est inscrit sur la liste, vous ne pouvez plus 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 regarder ça méta-liste des demandes de suppression pour voir quels sont les problèmes majeurs 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 définitivement au préchargement. Le projet Chromium recommande d'effectuer des tests à intervalles en définissant le âge max valeur d'abord à cinq minutes pour tester que cela fonctionne:

âge max = 300; includeSubDomains

Puis à une semaine pour un test plus long:

âge max = 604800; includeSubDomains

Ensuite, pendant un mois, jusqu'à ce que vous soyez certain qu'il n'y a pas de problème:

âge max = 2592000; includeSubDomains

Si quelque chose ne va pas et que vous définissez un très long âge max propriété, vous pouvez effacer l'indicateur local de Chrome net-internals page.

Une fois que vous êtes sûr que rien ne va pas avec le fait d'avoir uniquement HTTPS activé en permanence, vous pouvez configurer votre âge max à deux ans, ajoutez le précharge directive et soumettez votre site au préchargement.