La norme HTTPS surclassée par la nouvelle norme HSTS
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.
En début de semaine, 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. À l'origine du projet : Jeff Hodges de PayPal, Collin Jackson de l'Université Carnegie Mellon et Adam Barth de Google.
Bloquer les attaques « man-in-the-middle »
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.
Une correction des erreurs commises avec le SSL
Selon Ivan Ristic, directeur de l'ingénierie pour l'entreprise de sécurité Qualys, « le HSTS est l'une des meilleures choses qui puisse arriver au SSL car il corrige certaines erreurs commises il y a 18 ans lors de la conception du protocole ». Le HSTS « intègre également les changements survenus depuis, et qui ont modifié la façon dont les navigateurs Web fonctionnent aujourd'hui », a-t-il ajouté. « 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 », a déclaré Ivan Ristic. « Dans la majorité des cas, ce n'est pas un gros problème, mais dans 1% des cas, cela peut être dangereux », a-t-il dit. « Le HSTS ne repose pas sur les alertes des certificats. Si un problème est détecté dans la mise en oeuvre du HTTPS, le navigateur va tout simplement refuser la connexion sans laisser aux utilisateurs la possibilité de passer outre », a ajouté le directeur de l'ingénierie.
Mais, même avec le HSTS activé sur un site web, il reste encore une petite fenêtre pour les attaques, lorsque le navigateur visite le site pour la première fois et qu'il n'a pas sauvegardé la politique HSTS. À ce moment-là, un attaquant pourrait l'empêcher de parvenir à la version HTTPS du site et pourrait forcer la connexion à utiliser le protocole HTTP. Afin de résoudre ce problème, les navigateurs comme Chrome et Firefox sont livrés avec des listes de sites Web populaires préchargés pour lesquels le HSTS est appliqué par défaut.
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. « Mis à part un taux d'adoption globalement assez faible, quelques sites supportant la fonctionnalité ont des problèmes d'implémentation », a expliqué Ivan Ristic. Par exemple, certains d'entre eux ont fixé une durée de validité très courte - également connu sous la dénomination de temps de vie - à leurs politiques HSTS. « Pour que le HSTS soit efficace, les documents doivent être validés pour plusieurs jours, voire plusieurs mois », a-t-il estimé.
Selon le directeur de l'ingénierie, le fait que HSTS devienne une norme officielle ne va pas nécessairement pousser à son adoption. « Les opérateurs de sites web ont toujours été très opportunistes et ils implémentent toujours ce qui leur est utile, indépendamment du fait que ce soit un standard ou pas », a-t-il dit. « Le plus gros problème avec le HSTS, c'est l'éducation », a déclaré Ivan Ristic. « Les gens doivent savoir que ça existe ».
À 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.
