« Tor, conception, fonctionnement et limites » : différence entre les versions
Aller à la navigation
Aller à la recherche
| Ligne 246 : | Ligne 246 : | ||
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 <ref name="Serjantov & Sewell, 2003">[https://gnunet.org/sites/default/files/10.1.1.5.2005.pdf Serjantov, A., Sewell, P., 2003, Passive attack analysis for connection-based anonymity systems]</ref>. 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 <ref name="Murdoch & Danezis, 2005">[http://sec.cs.ucl.ac.uk/users/smurdoch/papers/oakland05torta.pdf Murdoch, S.J., Danezis, G., 2005, Low-cost traffic analysis of Tor]</ref> | 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 <ref name="Serjantov & Sewell, 2003">[https://gnunet.org/sites/default/files/10.1.1.5.2005.pdf Serjantov, A., Sewell, P., 2003, Passive attack analysis for connection-based anonymity systems]</ref>. 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 <ref name="Murdoch & Danezis, 2005">[http://sec.cs.ucl.ac.uk/users/smurdoch/papers/oakland05torta.pdf Murdoch, S.J., Danezis, G., 2005, Low-cost traffic analysis of Tor]</ref> | ||
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% | 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%<ref name="Chakravarty et al."/>. | ||
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 | 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 <ref name="Tor blog">[https://blog.torproject.org/blog/traffic-correlation-using-netflows Traffic correlation using netflows]</ref> | ||
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. | 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 === | ||