Si vous fréquentez [le blog de Dareboost], il ne vous aura pas échappé qu’il est urgent de passer au HTTPS. L’échéance est d’autant plus forte que les géants du Web ont déjà tiré leurs coups de semonce en affichant des alertes sur certaines pages en HTTP dans Google Chrome et Mozilla Firefox. Bientôt, ce seront tous les formulaires qui seront concernés.
Cela étant dit, avoir un site accessible en HTTPS ne suffit pas à basculer l’ensemble de son trafic automatiquement vers cette nouvelle version.
Mise en place d’une redirection : une technique qui présente des limites
Une des manières les plus efficaces de rediriger le trafic vers la version HTTPS de votre site est la mise en place d’une redirection permanente (code 301, avec un entête HTTP Location indiquant la page destination). Utilisateurs comme moteurs de recherche visitant le site HTTP seront ainsi redirigés automatiquement vers la version HTTPS.
Cela suffit-il ? Malheureusement non. Car cette redirection ne corrigera pas, pour la plupart des utilisateurs, l’action d’origine les ayant amenés à interroger cette URL non-sécurisée. Certains auront tapé directement l’URL en HTTP, d’autres auront cliqué sur une icône de leur barre de favoris, d’autres encore auront suivi un lien situé sur un site tiers. L’erreur étant humaine, vous n’êtes pas, vous-même, à l’abri de laisser traîner un lien interne en HTTP dans votre site Web HTTPS. Dans tous ces cas, la redirection ne suffit pas à garantir la sécurité du trafic de vos visiteurs et ajoute à la navigation le coût d’une requête supplémentaire, affectant ainsi la performance.
De plus, subir une redirection vers une version sécurisée implique que l’on a d’abord cherché à joindre une page non-sécurisée. Durant cette requête initiale, la navigation est susceptible d’être capturée. Si un individu mal intentionné a accès au réseau de votre visiteur, il sera en mesure d’intercepter le trafic et, pire encore, de le détourner pour acquérir des données de navigation. La liste des situations à risque est longue : bornes Wi-Fi publiques, connexion internet fournies par les compagnies de transport (qui sont parfois les premières à injecter des contenus dans le trafic non-sécurisé), réseau privé compromis, etc.
Que l’on parle de sécurité ou de performance, il est donc nécessaire d’éviter autant que possible cette redirection.
HSTS pour forcer le trafic vers HTTPS
HTTP Strict Transport Security (HSTS) est une directive, dont la spécification complète se trouve dans la RFC 6797. Elle se présente comme un entête de réponse envoyé par le serveur au navigateur lui déclarant que le domaine interrogé est destiné à être visité uniquement en HTTPS.
Le navigateur enregistre l’information et, si à l’avenir l’URL non-sécurisée est interrogée, il effectuera automatiquement une redirection interne (code 307) vers la version HTTPS. Comme HSTS ne concerne que les appels futurs, la mise en place de redirections 301 sur les appels HTTP reste pertinente.
La directive dispose une durée de validité exprimée en secondes dans le paramètre max-age. Une valeur à 300 ordonne au navigateur de mémoriser l’URL sécurisée pendant cinq minutes. Une valeur à 63072000, pendant deux ans.
Il est recommandé d’implémenter HSTS avec une faible durée de rétention, puis d’augmenter progressivement. À chaque étape, attendez a minima le temps paramétré dans max-age puis détectez les requêtes infructueuses et surveillez les métriques de votre domaine. Corrigez les problèmes constatés.
Voici un exemple d’implémentation avec Apache, pour une rétention de 5 minutes :
Header always set Strict-Transport-Security "max-age=300; includeSubDomains;"
Le paramètre includeSubDomains permet de forcer le HTTPS pour l’ensemble des sous-domaines : attention, si certaines de vos ressources sont uniquement accessibles en HTTP, mieux vaut ne pas activer cette option !
En cas d’erreur, sachez cependant qu’un retour en arrière est possible en modifiant votre directive HSTS avec un max-age à 0.
A max-age value of zero (i.e.,
max-age=0) signals the UA to cease regarding the host as a Known HSTS Host, including the includeSubDomains directive (if asserted for that HSTS Host). RFC6797, Section 6.1.1
Récapitulons. La directive HSTS permet, en complément d’une redirection 301, de sécuriser le trafic futur d’un visiteur pendant une période donnée, sur un contexte de domaine défini (domaine courant ou domaine et ensemble des sous-domaines). Reste toutefois un problème de sécurité : l’accès initial du visiteur à la version non-sécurisée.
Un trafic totalement sécurisé et fiable avec HSTS Preloading
Pour sécuriser davantage l’ensemble du trafic des sites sécurisés, le projet Chromium maintient une liste des domaines « valides HSTS », c’est-à-dire :
- disposant d’une version sécurisée à l’aide d’un certificat valide ;
- ayant mis en place des redirections 301 de HTTP vers HTTPS ;
- dont tous les sous-domaines sont sécurisés ;
- proposant une directive HSTS (y compris sur la redirection 301) d’une validité minimale de
18 semaines (10886400 secondes)un an (31536000 secondes)1, incluant les sous-domaines et spécifiant l’attributpreload.
Un site éligible pourra alors rejoindre le registre HSTS Preloading embarqué dans Chrome, Firefox, Opera, Safari, IE 11 et Edge. Toute requête non-sécurisée vers ce domaine bénéficiera alors d’une redirection interne (code 307) avant même que ne démarre la requête.
Redirection interne lors d’une tentative d’accès à Facebook en HTTP dans Chrome 60.
Attention : contrairement au chapitre précédent, modifier la directive pour revenir en arrière en cas d’erreur de votre part ne suffira pas. Des domaines peuvent être supprimés du registre, mais il faut des mois pour que tous les utilisateurs concernés voient leur navigateur mis à jour avec cette nouvelle liste. Ne demandez donc pas à être inclus à HSTS Preload à moins d’être sûr que vous supporterez HTTPS pour votre domaine et tous ses sous-domaines à long terme.
Protégez vos utilisateurs avec HSTS
La directive HSTS existe depuis plusieurs années. Elle permet de sécuriser le trafic futur de vos visiteurs et, couplée à l’inscription dans le registre HSTS Preloading, de fiabiliser même leur première connexion. Sa mise en place doit être faite avec précaution, car elle impose la sécurisation de l’ensemble des sous-domaines du domaine concerné. Une fois mise en place, elle fiabilise durablement le trafic sécurisé des visiteurs, améliore la performance en supprimant des redirections 301 et, dans la mesure où ce trafic sécurisé est valorisé par l’algorithme de Google, améliore le référencement.
Bonus : avec HSTS Preload, protégez votre domaine des attaques de type SSL strip
Celles et ceux qui suivent l’actualité du Web auront remarqué le danger représenté par Krack Attacks, une démonstration de piratage du protocole WiFi WPA2. Une des étapes de l’attaque consiste, pour le logiciel malveillant, à intercepter les requêtes SSL émises par l’internaute, les réaliser lui-même puis répondre le résultat en HTTP. Un simple instant d’inattention suffit alors pour qu’un pirate s’empare d’informations privées. Si votre domaine est indexé dans la liste HSTS Preload, alors le navigateur refusera de basculer en HTTP pour le visiter, protégeant ainsi vos visiteurs.
Lectures complémentaires
- [EN] HTTP Strict Transport Security – The Chromium Projects
- [EN] HTTP Strict Transport Security Cheat Sheet – OWASP
-
La valeur était de 18 semaines lorsque j’ai écrit l’article. Elle a été repoussée à une année entre le 11 et le 16 octobre 2017. Merci à @Thibault_Walle de me l’avoir signalé en commentaire. ↩