245
modifications
« Tor, conception, fonctionnement et limites » : différence entre les versions
Aller à la navigation
Aller à la recherche
Tor, conception, fonctionnement et limites (voir la source)
Version du 21 juillet 2017 à 21:33
, 21 juillet 2017→Time pattern
mAucun résumé des modifications |
|||
| Ligne 237 : | Ligne 237 : | ||
Il est cependant très facile de prévenir cette attaque. Il suffit d'interdire le Javascript via le plugin "NoScript" installé par défaut sur le TorBrowser. Cependant, comme expliqué ci dessus, beaucoup de sites du clearweb ne fonctionnent pas sans Javascript. En revanche, à cause de ces vulnérabilités maintenant connues, aucun service caché sérieux n'incluera de Javascript dans le code source de sa page. En d'autres termes, vous pouvez (vous devriez) désactiver Javascript sur le deep web sans vous poser de questions. Si un service caché a besoin de Javascript pour fonctionner, n'y allez pas. | Il est cependant très facile de prévenir cette attaque. Il suffit d'interdire le Javascript via le plugin "NoScript" installé par défaut sur le TorBrowser. Cependant, comme expliqué ci dessus, beaucoup de sites du clearweb ne fonctionnent pas sans Javascript. En revanche, à cause de ces vulnérabilités maintenant connues, aucun service caché sérieux n'incluera de Javascript dans le code source de sa page. En d'autres termes, vous pouvez (vous devriez) désactiver Javascript sur le deep web sans vous poser de questions. Si un service caché a besoin de Javascript pour fonctionner, n'y allez pas. | ||
=== | === Analyse de traffic === | ||
Le concept d’une attaque par analyse de traffic est assez simple. Supposons que deux personnes s’échangent des messages chiffrés et qu’un attaquant surveille cet échange. Etant donné que les messages sont chiffrés, l’attaquant n’a pas accès au contenu. En revanche, la fréquence d’échange des messages ainsi que leur taille sont des indications qui permettent à un attaquant de faire des déductions quant à leur contenu ou leur destination. | |||
Prenons un exemple très concret. Normalement, Tor est censé réactualiser le circuit Tor toutes les 10 minutes. Or il existe quelques exceptions à cette règle : lorsque vous maintenez un échange de données ininterrompu avec un serveur en passant par Tor (par exemple, en téléchargeant ou en uploadant), le circuit ne peut pas être réactualisé pendant l’échange(https://mice.cs.columbia.edu/getTechreport.php?techreportID=1545&format=pdf&). Supposons que vous téléchargiez vraiment un gros fichier, genre un film de 2h30 en full HD de 10Go sur youtube via le logiciel youtube-dl, et que ça prenne, mettons, 5 heures. Pendant 5 heures, vous allez garder le même circuit (Exemple quasi réel : j’ai déjà de cette façon réalisé des téléchargements qui ont duré plus de 10 minutes). Si un attaquant qui controle des relais Tor voit que le serveur de youtube fait rentrer par un relai un énorme fichier pendant 5 heures, et qu’à un autre endroit, un autre relai envoie à un utilisateur un autre gros fichier pendant 5 heures, il peut raisonnablement en conclure que vous êtes en train de télécharger un film sur youtube (sans pour autant avoir accès au fichier en question). Quant à vous, vous êtes grillés ! | |||
Il y a de multiples façons de faire de l’analyse de traffic. La plus simple est par exemple de regarder les demandes de connexions entrantes et sortantes et de les corréler entre elles (https://gnunet.org/sites/default/files/10.1.1.5.2005.pdf). Il est également possible de compter les paquets entrant et les paquets sortant. D’autres attaques un peu plus sophistiquées impliquent de router un traffic initié par l’attaquant à travers un relai Tor spécifique et à destination d’un serveur controllé par l’attaquant. Ce traffic va devoir être processé par le relai Tor en question, ce qui va influencer la latence de tous les traffics qu’il doit processer, leur imprimant à tous un pattern de débit. Il suffit ensuite au serveur compromis d’analyser le pattern de débit qui lui est personnellement destiné, et de voir où est ce que ce pattern se retrouve dans le réseau pour en déduire que ces traffics sont passé par ce relai spécifique (http://sec.cs.ucl.ac.uk/users/smurdoch/papers/oakland05torta.pdf). | |||
Il existe des tas et des tas d’autres façon de faire de l’analyse de traffic. Je terminerai en expliquant une dernière attaque très compromettante. Il s’agit d’imprimer activement des perturbations de débit dans les connexions à destination ou en provenance d’un serveur (comme un site web) en détournant le traffic avant qu’il n’entre dans le réseau Tor. Il suffit de voir ensuite où est ce que ces perturbations se retrouvent pour desanonymiser les gens qui ont contacté ce serveur, y compris à travers Tor. C’est de cette façon que 81% des utilisateurs de Tor peuvent être desanonymisés avec un taux de faux positifs de 6% (https://mice.cs.columbia.edu/getTechreport.php?techreportID=1545&format=pdf&). | |||
C’est réellement un problème car les solutions qui permettraient de fixer ce problème risquent de gravement nuire à l’utilisabilité de Tor. Par exemple on pourrait imaginer introduire du traffic “parasite” qui serait trié de façon transparente directement par le client et le serveur, mais on augmenterait alors drastiquement la bande passante de Tor. On pourrait également introduire des perturbations aléatoires de débit, mais celà ralentirait considérablement les connexions Tor qui sont déjà réputées être lentes. Cependant, le TorProject a mitigé les résultats de l’analyse par perturbation de traffic en argumentant que 6% de faux positifs, celà peu sembler peu, mais c’est en réalité énorme, suffisemment pour rendre l’attaque inexploitable en tant que tel (https://blog.torproject.org/blog/traffic-correlation-using-netflows). | |||
C’est précisément pour cette raison qu’il est dangereux d’utiliser un VPN en entrée du réseau Tor. Malgré ce que peuvent dire les conditions d’utilisation et la politique de confidentialité des prestataires de VPN, vous n’avez que leur seule parole qu’ils ne conservent pas de logs et qu’ils n’analysent pas votre traffic. Tor est un logiciel open source maintenu par le Torproject, une association à but non-lucratif. De plus, le TorProject fait activement la chasse aux relais qui analysent ou interagissent avec le traffic comme on l’a vu dans la rubrique “Noeuds sortants”, et l’analyse de traffic nécessite justement bien souvent de controller au préalable des relais (idéalement, les deux tiers, c’est à dire les relais d’entrée et de sortie). Or les VPN échappent complètement à la surveillance du TorProject et n’ont de compte à rendre qu’à ceux qui font pression sur eux. Le VPN devient donc de fait le maillon faible de la chaîne, ce qui réduit le nombre de relais Tor à controller. Si on prend l’attaque par injection de pattern temporel dans le débit et qu’il y a un VPN en entrée, il n’y a même pas besoin de controller un seul relai pour desanonymiser. | |||
=== Fingerprinting de la souris === | === Fingerprinting de la souris === | ||