Sam Greenhalgh, un consultant britannique, a démontré comment une caractéristique du protocole web sécurisé HTTPS peut être transformée en une fonction de suivi qui s’avère, dans le cas de certains navigateurs, indéracinable.Dans le RFC 6797 que vous trouverez cité en source, HSTS (http Strict Transport Security) est décrit comme étant un mécanisme dont l’objectif est d’aider les sites web à rediriger leurs visiteurs d’une version HTTP vers une version chiffrée HTTPS : « cette spécification définit un mécanisme permettant à des sites Web de se déclarer uniquement accessibles via des connexions sécurisées et /ou pour les utilisateurs d’être en mesure de diriger leur user agent(s) pour une interaction avec lesdits sites exclusivement sur des connexions sécurisées ». Concrètement, si un utilisateur entre dans la barre de recherche http://www.google.fr, ce sera donc HSTS qui le redirigera vers https://www.google.fr.
Le hic c’est que le fait que votre user agent (en l’occurrence votre navigateur) doit passer par une redirection chaque fois qu’il visite un site qui s’est déclaré uniquement accessible en HTTPS a dû être perçu comme problématique puisque les auteurs du protocole HSTS ont pensé à un mécanisme afin que les navigateurs se souviennent de la politique HSTS appliquée aux sites qui ont été visités.
C’est donc ce mécanisme que Greenhalgh a identifié comme étant une espèce de super-cookie HSTS. Selon lui, « cette redirection automatique protège votre accès au site face aux interceptions, mais pourrait aussi être utilisée par un site malveillant pour stocker un numéro unique afin de suivre votre navigateur Web. Un numéro peut être codé comme étant une série de bits (valeurs vraie et fausse) et sauvegardé en accédant à un ensemble d'adresses Web. Chaque adresse Web répond à un HSTS activé ou désactivé en fonction de l'adresse. Une fois que le numéro est enregistré il pourrait être lu par d'autres sites à l'avenir. La lecture du numéro nécessite simplement de tester si les demandes pour les mêmes adresses Web sont redirigés ou non ».
Et il poursuit en disant que « parce que HSTS est une fonctionnalité de sécurité et n’a pas été pensé pour suivre la navigation des utilisateurs, les navigateurs web la traite différemment des cookies. C’est uniquement une mauvaise application intentionnelle faite de HSTS qui peut être exploitée afin de traquer les utilisateurs ».
Sa démonstration est simple. Une fois que quelqu'un visite sa page en mode de navigation normale, un identificateur unique sera persisté et il apparaîtra même lorsque vous actualiserez la page, ouvrirez la même page en mode incognito ou privé, visiterez la page sur différents dispositifs iOS synchronisés avec le même compte iCloud ou même effacerez vos cookies et actualiserez la page. C’est cet identifiant qui permettra à d’autres sites par exemple de suivre vos habitudes sur le web.
Il avançait qu’effacer les cookies sur les navigateurs Chrome, Firefox ou Opera effaçait également les drapeaux HSTS et de facto toutes les valeurs qui auraient pu être enregistrées. Cependant, contrairement aux cookies, les drapeaux HSTS s’ils existent sont partagés avec les sites même dans les modes « incognito » ou « privé ». En clair, vous pouvez toujours être pisté même si vous choisissez ces modes pour échapper à de telles pratiques.
C’est surtout le comportement de Safari, le navigateur d’Apple, qui a attiré son attention : « lorsque vous utilisez Safari sur un dispositif Apple, il s’avère qu’il n’y a pas de possibilité pour un utilisateur de supprimer les drapeaux HSTS. Les drapeaux HSTS sont même synchronisés avec le service iCloud afin qu’ils soient restaurés au cas où le dispositif était formaté. Dans ce cas, le dispositif peut effectivement être « marqué » d'une valeur de suivi indélébile que vous n’avez aucun moyen de supprimer ». Il note une exception notable à Internet Explorer qui n’a pas encore de support de HSTS puisqu’il est encore en développement.
Le 04 janvier dernier, les membres de l’équipe dédiée à la sécurité du navigateur Web de Google ont mis en évidence les discussions qui ont conduit à un certain nombre de correctifs dans le code de base de chromium dans une tentative visant à atténuer les effets dudit problème. Le 07 janvier 2015, il a remarqué que la dernière version de Firefox (Firefox 34.0.5) ne supporte plus la persistance des super-cookies HSTS en mode privé.
Greenhalgh a également rappelé que ce problème a déjà été signalé en avril 2012 par Mikhail Davidov.
Source : radicalresearch (billet de Sam Greenhalgh), ietf (hsts), billet de Mikhail Davidov
