Destinée à empêcher certains types d'attaques contre des connexions HTTPS, la technologie HSTS est maintenant au point. Mais son adoption reste faible, car elle n'était pas une norme Internet officielle. C'est désormais chose faite sous la référence RFC 6797. Le mécanisme de sécurité qui promet de rendre les sites web HTTPS plus efficaces pour résister à différents types d'attaques a été approuvé et élevé au rang de norme Internet. Mais, à part certains sites de grande envergure, l'adoption de cette norme reste encore limitée. Le HTTP Strict Transport Security (HSTS) permet aux sites web d'être accessibles uniquement via une connexion HTTPS (HTTP sécurisé). Il a été conçu pour empêcher les pirates de forcer les connexions utilisateurs sur le HTTP ou de tirer profit d'erreurs dans les implémentations HTTPS pour compromettre l'intégrité du contenu. Récemment, l'Internet Engineering Task Force (IETF), l'organisme chargé de développer et de promouvoir les standards de l'Internet, a validé la spécification HSTS et l'a élevé au rang de norme officielle (le document porte la référence RFC 6797). C'est en 2010 que le groupe de travail chargé de la sécurité du web au sein de l'IETF a commencé à se pencher sur la question. A l'origine du projet : Jeff Hodges de PayPal, Collin Jackson de l'Université Carnegie Mellon et Adam Barth de Google. Le HSTS verrouille un peu plus les sites web HTTPS en évitant que les contenus mixtes en affectent la sécurité et l'intégrité. Les sites doivent gérer des contenus mixtes quand des scripts ou d'autres ressources embarquées dans un site web HTTPS sont chargés depuis un emplacement tiers via une connexion non sécurisée. Cette situation peut résulter d'une erreur de développement. Mais le recours à une source extérieure peut aussi être intentionnel. Lorsque le navigateur charge la ressource non sécurisée, il envoie une requête HTTP simple et peut également joindre le cookie de la session utilisateur. Un attaquant peut profiter de ce temps de connexion non sécurisé pour intercepter la requête à l'aide d'un renifleur de réseaux et récupérer le cookie et détourner le compte de l'utilisateur. Le mécanisme HSTS empêche les attaques de type «man-in-the-middle» où l'attaquant parvient à intercepter la connexion d'un utilisateur à un site web et à forcer son navigateur à accéder à la version HTTP du site au lieu de la version HTTPS. Cette technique est connue sous le nom de Stripping Attack HTTPS ou SSL, et il existe des outils pour automatiser le processus. Lorsque le navigateur se connecte via HTTPS à un site web qui prend en charge le HSTS, la politique de sécurité stricte est appliquée et renouvelée pour une période déterminée. De ce point de vue, tant que cette politique mise en cache n'expire pas, le navigateur va refuser d'engager des connexions non sécurisées avec le site. La politique HSTS est transmise à travers un en-tête de réponse HTTP appelé Strict-Transport-Security. Le même en-tête peut être utilisé pour mettre à jour et renouveler la politique. Le HSTS intègre également les changements survenus depuis, et qui ont modifié la façon dont les navigateurs Web fonctionnent aujourd'hui. Par exemple, c'était une erreur de se fier aux alertes des certificats parce que les utilisateurs ont pris l'habitude de les ignorer et de les neutraliser. Selon SSL Pulse, un projet qui surveille les implémentations HTTPS sur la plupart des sites Internet visités de la planète, seuls environ 1 700 des 180 000 premiers sites compatibles HTTPS supportent le HSTS. A l'heure actuelle, parmi les sites web qui prennent en charge le HSTS, on trouve PayPal, Twitter, les différents services de Google. Facebook est toujours en train de déployer le HTTPS à travers son site web, mais le réseau social ne supporte pas encore le HSTS.
