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.
