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:39
, 21 juillet 2017→Analyse de traffic
| Ligne 241 : | Ligne 241 : | ||
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. | 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 | 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 <ref name="wired-FBI">[https://mice.cs.columbia.edu/getTechreport.php?techreportID=1545&format=pdf& Chakravarty, S., Barbera, M.V., Portokalidis, G., Polychronakis, M., Keromytis, A.D. On the effectiveness of traffic analysis against anonymity networks using flow records | ||
]</ref>. 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 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). | ||