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 22 juillet 2017 à 23:28
, 22 juillet 2017→Analyse de traffic
| Ligne 238 : | Ligne 238 : | ||
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 <ref name="Chakravarty et al.">[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 | 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="Chakravarty et al.">[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 ! | ]</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 ! | ||
| Ligne 245 : | Ligne 245 : | ||
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."/>. | 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 <ref name="Tor blog">[https://blog.torproject.org/blog/traffic-correlation-using-netflows Traffic correlation using netflows]</ref>. | 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 charge sur 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 === | ||