Exiger que chaque utilisateur de Tor soit un relais aiderait à faire évoluer le réseau pour gérer tous nos utilisateurs, et faire fonctionner un relais Tor peut aider votre anonymat.
Cependant, de nombreux utilisateurs de Tor ne peuvent pas être de bons relais - par exemple, certains clients Tor opèrent derrière des pare-feu restrictifs, se connectent par modem, ou ne sont pas en mesure de relayer le trafic.
Fournir un service à ces clients est une partie essentielle de la fourniture d'un anonymat efficace pour tous, puisque de nombreux utilisateurs de Tor sont soumis à ces contraintes ou à des contraintes similaires et que l'inclusion de ces clients augmente la taille de l'ensemble d'anonymat.
Cela dit, nous voulons encourager les utilisateurs de Tor à faire fonctionner des relais, donc ce que nous voulons vraiment faire, c'est simplifier le processus de mise en place et de maintenance d'un relais.
Nous avons fait de gros progrès en ce qui concerne la facilité de configuration depuis quelques années : Tor sait détecter automatiquement s'il est joignable et quelle bande passante il peut fournir.
Il y a cependant quatre étapes à franchir avant de pouvoir le faire :
Tout d'abord, nous devons encore améliorer notre capacité à estimer automatiquement la bonne quantité de bande passante à autoriser.
Il se peut que passer au transport UDP soit la réponse la plus simple - ce qui, hélas, n'est pas une réponse très simple du tout.
Deuxièmement, nous devons travailler sur l'évolutivité, à la fois du réseau (comment arrêter d'exiger que tous les relais Tor soient capables de se connecter à tous les relais Tor) et de l'annuaire (comment arrêter d'exiger que tous les utilisateurs de Tor connaissent tous les relais Tor).
De tels changements peuvent avoir un impact important sur l'anonymat actuel et potentiel.
Voir la section 5 du document Challenges pour plus de détails.
Ici aussi, le transport UDP serait utile.
Troisièmement, nous devons mieux comprendre les risques liés au fait de laisser l'attaquant envoyer du trafic via votre relais alors que vous initiez également votre propre trafic anonyme.
Trois différents recherche Les articles décrivent les moyens d'identifier les relais dans un circuit en faisant passer le trafic par les relais candidats et en recherchant les baisses de trafic lorsque le circuit est actif.
Ces attaques par engorgement ne sont pas si effrayantes dans le contexte de Tor tant que les relais ne sont jamais des clients également.
Mais si nous essayons d'encourager davantage de clients à activer la fonctionnalité de relais (que ce soit en tant que relais de bridge ou en tant que relais normaux), nous devons mieux comprendre cette menace et apprendre à l'atténuer.
Quatrièmement, nous pourrions avoir besoin d'une sorte de système d'incitation pour encourager les gens à relayer le trafic pour d'autres, et/ou à devenir des nœuds de sortie.
Voici ce que nous pensons actuellement des mesures d'incitation de Tor.
Aidez-nous à résoudre tous ces problèmes !
Il serait bon de laisser les opérateurs de relais dire des choses comme rejeter www.slashdot.org dans leurs politiques de sortie, plutôt que de les obliger à apprendre tout l'espace d'adresses IP qui pourrait être couvert par le site (et de bloquer également d'autres sites à ces adresses IP).
Deux problèmes se posent cependant.
Tout d'abord, les utilisateurs peuvent toujours contourner ces blocages.
Par exemple, ils pourraient demander l'adresse IP plutôt que le nom d'hôte lorsqu'ils quittent le réseau Tor.
Cela signifie que les opérateurs doivent encore apprendre toutes les adresses IP des destinations en question.
Le deuxième problème est qu'il permettrait à des attaquants distants de censurer des sites arbitraires.
Par exemple, si un opérateur Tor bloque www1.slashdot.org, puis qu'un pirate empoisonne le DNS du relais Tor ou modifie ce nom d'hôte pour qu'il soit résolu à l'adresse IP d'un grand site d'information, ce relais Tor bloque soudain le site d'information.
Non, vous ne pouvez pas faire confiance au réseau pour choisir le chemin.
Des relais malveillants pourraient vous faire passer directement par leurs complices.
Un adversaire aurait ainsi la possibilité de surveiller l'ensemble de votre trafic de bout en bout.
Ce serait pratique pour plusieurs raisons :
Cela permettrait à Tor de mieux gérer les nouveaux protocoles tels que la VoIP.
Cela pourrait résoudre le problème de l'utilisation d'applications de sécurité.
Les relais de sortie n'auraient pas non plus besoin d'allouer un grand nombre de descripteurs de fichiers pour toutes les connexions de sortie.
Nous allons en ce sens. Les problèmes les plus difficiles à résoudre sont les suivants :
Les paquets IP révèlent les caractéristiques du système d'exploitation.
Nous devrions toujours procéder à une normalisation des paquets au niveau de l'IP, afin d'empêcher les attaques de type "empreinte TCP".
Compte tenu de la diversité et de la complexité des piles TCP, ainsi que des attaques par empreintes numériques, il semble que notre meilleure solution soit de créer notre propre pile TCP en espace utilisateur.
Les flux au niveau de l'application doivent encore être nettoyés.
Nous aurons toujours besoin d'applications côté utilisateur comme Torbutton.
Il ne s'agira donc pas simplement de capturer des paquets et de les rendre anonymes au niveau de la couche IP.
Certains protocoles continueront à laisser filtrer des informations.
Par exemple, nous devons réécrire les requêtes DNS pour qu'elles soient transmises à un serveur DNS non connectable plutôt qu'au serveur DNS du fournisseur d'accès à Internet de l'utilisateur ; nous devons donc comprendre les protocoles que nous transportons.
DTLS (datagramme TLS) n'a pratiquement pas d'utilisateurs, et IPsec est certainement très important.
Une fois que nous avons choisi un mécanisme de transport, nous devons concevoir un nouveau protocole Tor de bout en bout pour éviter les attaques de marquage et d'autres problèmes potentiels d'anonymat et d'intégrité maintenant que nous autorisons les abandons, les renvois, etc.
Les politiques de sortie pour les paquets IP arbitraires signifient la construction d'un système de détection d'intrusion (IDS) sécurisé.
Nos opérateurs de nœuds nous disent que les politiques de sortie sont l'une des principales raisons pour lesquelles ils acceptent de gérer Tor.
L'ajout d'un IDS pour gérer les politiques de sortie augmenterait la complexité de la sécurité de Tor, et ne fonctionnerait probablement pas de toute façon, comme le montre l'ensemble des articles sur les IDS et les contre-IDS.
De nombreux problèmes d'abus potentiels sont résolus par le fait que Tor ne transporte que des flux TCP valides (par opposition aux IP arbitraires, y compris les paquets malformés et les inondations IP).
Les politiques de sortie deviennent encore plus importantes lorsque nous sommes en mesure de transporter des paquets IP.
Nous avons également besoin de décrire de manière compacte les politiques de sortie dans l'annuaire Tor, afin que les clients puissent prédire quels nœuds autoriseront la sortie de leurs paquets.
Les clients doivent également prévoir tous les paquets qu'ils voudront envoyer au cours d'une session avant de choisir leur nœud de sortie !
Les espaces de noms internes à Tor devraient être repensés.
Nous prenons en charge les adresses ".onion" en interceptant les adresses lorsqu'elles sont transmises au client Tor.
Le faire au niveau de l'IP nécessitera une interface plus complexe entre Tor et les serveurs DNS locaux.