Sam Greenhalgh a montré qu’on pouvait utiliser la fonctionnalité HSTS pour facilement tracer les utilisateurs. La faille est intéressante car elle est conceptuelle va être très compliquée à bloquer et touche quasiment tous les navigateurs web même les assez vieux ( >= Firefox 4 ).
Explication
Le principe d’ HSTS est simple. Lorsque le navigateur arrive sur un site web en HTTPS, et que le site web implémente HSTS, alors le navigateur reçoit du site web une directive indiquant qu’il doit toujours revenir en HTTPS sur le site web pour les prochaines visites sur ce nom de domaine.
HSTS permet ainsi de contenter les visiteurs qui veulent toujours accéder aux site web en HTTPS sans bloquer les autres visiteurs qui préfèrent utiliser HTTP.
Imaginons maintenant que http://1.toto.com renvoie un texte : « 0 » mais que https://1.toto.com renvoie une valeur différente : « 1 », ce qui est tout à fait faisable. Il n’y a pas d’obligation que les services HTTP et HTTPS soient des miroirs.
Donc si, sur mon site web « bidon.com », j’inclus un lien vers un contenu situé à l’adresse http://1.toto.com le contenu aura une valeur différente selon que l’utilisateur a déjà ou non visité « 1.toto.com » en HTTPS. Intéressant !
Avec seulement 33 requêtes différentes (1.toto.com, 2.toto.com, etc…, 33.toto.com) qui peuvent valoir 2 valeurs différentes : 0 ou 1 (HTTPS visité ou pas), j’ai 2^33 possibilités soit 8.6 milliards de valeurs différentes, soit suffisamment pour assigner une valeur différente à chaque humain sur Terre.
La faille est donc simple, un visiteur lambda arrive sur mon site « bidon.com », j’ai envie de lui coller un numéro, par exemple « 5 ». Je convertis ce numéro en binaire sur 33 bits ce qui fait 00000000000000000000000000000101. Je le fait charger des contenus en HTTP sur http://1.toto.com, http://2.toto.com, etc… sauf https://31.toto.com et https://33.toto.com où je lui donne des liens en HTTPS.
Quand le visiteur lambda reviendra sur mon site « bidon.com », je lui ferai encore charger charger mes 33 contenus mais en mettant des liens HTTP uniquement (http://1.toto.com, http://2.toto.com, etc…, http://33.toto.com). Normalement, ça devrait renvoyer 33 fois « 0 » sil m’était inconnu . Mais comme il a déjà visité 31.toto.com 33.toto.com en HTTPS, son navigateur va automatiquement modifier ses requêtes de http://31.toto.com et http://33.toto.com en https://31.toto.com et https://33.toto.com et ça renverra 00000000000000000000000000000101. Bingo, je l’ai reconnu.
Comment s’en protéger?
HSTS est enregistré comme préférence du site et non comme un cookie. Supprimer les cookies est donc inutile.
Votre identifiant peut être stocké dans dans les préférences de multiples sites web et non dans celui qui vous traque.
Or pour supprimer la préférence HSTS d’un domaine, il faut supprimer les toutes les préférences du site web depuis la page about:permissions sur Firefox, ce qui supprime aussi les mots de passe et son historique… Bref, pas très utilisable.
Bloquer Javascript sur le site du traqueur rend aussi la technique inefficace, mais difficile de savoir différencier le bon script du mauvais script sur un site web.
Dur dur…
Une question, concernant le « Quand le visiteur lambda reviendra sur mon site « bidon.com », je lui ferai encore charger charger mes 33 contenus mais en mettant des liens HTTP uniquement ». Comment savoir à ce moment là qu’il faut uniquement lui demander de charger du HTTP et pas du HTTPS ? (ou comment savoir lors de la première visite qu’il faut lui assigner un numéro pour lui faire charger du HTTPS ?)
Ce genre de fonctionnalité ne devrait être activée que pour le domaine qui apparaît dans la barre d’adresse. De manière générale, cela permettrait de réduire le tracking.
Mais je ne sais pas si les navigateurs web sont bien pensés pour permettre cela, même au niveau d’une extension.
@Jérémie: Pour chaque visiteur, tu lui fais d’abord télécharger les liens en HTTP uniquement.
A/ Sois il est nouveau, et ne te renverra que des 0 car aucun lien ne sera converti en HTTPS. A ce moment, tu le forces à quelques lien en HTTPS suivant le numéro que tu veux lui coller
B/ Sois il est déja connu et au moins un des liens va passer en HTTPS. Ca veut dire qu’il a un numéro.
@Mildred : Tu veux dire que les requêtes javascript inter-domaines ne devraient pas prendre en compte les préférences HSTS ? Effectivement ca pourrait résoudre le problème. Il faudrait également l’empecher de fonctionner pour les appels aux sous-domaines ! Ainsi le site ne pourrait accéder qu’à un bit de donnée personnelle. soir rien :-)
Et si on utilise la navigation privée, le navigateur enregistre quand même cette préférence HSTS? ou du moins n’est-elle pas supprimer à la fin de la session?