Dissenys alternatius que (encara) no fem

Exigir que cada usuari de Tor sigui un repetidor ajudaria a escalar la xarxa per gestionar tots els nostres usuaris, i gestionar un repetidor Tor pot ajudar-vos al vostre anonimat. Tanmateix, molts usuaris de Tor no poden ser bons repetidors; per exemple, alguns clients de Tor operen des de darrere de tallafocs restrictius, es connecten mitjançant un mòdem o, d'altra manera, no es troben en una posició on puguin repetir trànsit. Proporcionar servei a aquests clients és una part fonamental per proporcionar un anonimat efectiu per a tothom, ja que molts usuaris de Tor estan subjectes a aquestes limitacions o similars i incloure aquests clients augmenta la mida del conjunt d'anonimat.

Dit això, volem animar els usuaris de Tor a gestionar repetidors, de manera que el que realment volem fer és simplificar el procés de configuració i manteniment d'un repetidor. Hem avançat molt amb una configuració fàcil en els últims anys: Tor és bo en detectar automàticament si és accessible i quanta amplada de banda pot oferir.

Tanmateix, hi ha quatre passos que hem de seguir abans de fer-ho:

  • En primer lloc, encara hem de millorar l'estimació automàtica de la quantitat adequada d'ample de banda a permetre. Podria ser que canviar al transport UDP sigui la resposta més senzilla aquí, que per desgràcia no és una resposta senzilla.

  • En segon lloc, hem de treballar l'escalabilitat, tant de la xarxa (com deixar d'exigir que tots els repetidors de Tor es puguin connectar a tots els repetidors de Tor) com del directori (com deixar d'exigir que tots els usuaris de Tor coneguin tots els repetidors de Tor). Canvis com aquest poden tenir un gran impacte en l'anonimat real i potencial. Consulteu la secció 5 del document Reptes per obtenir més informació. Un cop més, el transport UDP ajudaria aquí.

  • En tercer lloc, hem d'entendre millor els riscos de deixar que l'atacant enviï trànsit a través del vostre repetidor mentre també inicieu el vostre propi trànsit anònim. Tres estudis diferents descriuen maneres d'identificar els repetidors d'un circuit fent circular trànsit a través de repetidors candidats i buscant caigudes en el trànsit mentre el circuit està actiu. Aquests atacs d'obstrucció no són tan aterridors en el context de Tor, sempre que els repetidors mai no siguin també clients. Però si estem intentant animar més clients a activar la funcionalitat de repetidor (ja sigui com a repetidors de pont o com a repetidors normals), hem d'entendre millor aquesta amenaça i aprendre a mitigar-la.

  • En quart lloc, podríem necessitar algun tipus d'esquema d'incentius per animar la gent a repetir trànsit per als altres i/o convertir-se en nodes de sortida. Aquí teniu les nostres reflexions actuals sobre els incentius Tor.

Si us plau, ajudeu en tot això!

Seria bo deixar que els operadors del repetidors diguessin coses com rebutjar www.slashdot.org a les seves polítiques de sortida, en lloc d'exigir-los que aprenguin tot l'espai d'adreces IP que podria cobrir el lloc (i després també bloquejar altres llocs a aquestes adreces IP).

Hi ha dos problemes, però. En primer lloc, els usuaris encara podrien evitar aquests bloquejos. Per exemple, podrien demanar l'adreça IP en lloc del nom d'amfitrió quan surten de la xarxa Tor. Això significa que els operadors encara haurien d'aprendre totes les adreces IP de les destinacions en qüestió.

El segon problema és que permetria als atacants remots censurar llocs arbitraris. Per exemple, si un operador de Tor bloqueja www1.slashdot.org i, a continuació, algun atacant enverina el DNS del repetidor de Tor o canvia aquest nom d'amfitrió per resoldre'l a l'adreça IP d'un lloc de notícies important, de sobte aquest repetidor de Tor bloqueja el lloc de notícies.

No, no podeu confiar en la xarxa per triar el camí. Els relleus maliciosos us podrien guiar pels seus amics col·lusoris. Això donaria a un adversari la possibilitat de veure tot el trànsit d'extrem a extrem.

Això seria útil per diversos motius: Això faria que Tor fos més capaç de gestionar nous protocols com VoIP. Podria resoldre tota la necessitat de socksificar les aplicacions. Els repetidors de sortida tampoc haurien d'assignar molts descriptors de fitxers per a totes les connexions de sortida.

Anem en aquesta direcció. Alguns dels problemes difícils són:

  1. Els paquets IP revelen les característiques del sistema operatiu. Encara hauríem de fer la normalització de paquets a nivell d'IP per aturar coses com ara els atacs d'empremtes digitals TCP. Donada la diversitat i la complexitat de les piles TCP, juntament amb els atacs d'empremtes digitals del dispositiu, sembla que la nostra millor aposta és enviar la nostra pròpia pila TCP d'espai d'usuari.

  2. Els fluxos a nivell d'aplicació encara s'han de polir. Encara necessitarem aplicacions del costat de l'usuari com Torbutton. Així que no es convertirà només en una qüestió de capturar paquets i anonimitzar-los a la capa IP.

  3. Alguns protocols encara filtraran informació. Per exemple, hem de reescriure les sol·licituds DNS perquè s'enviïn a un servidor DNS no enllaçable en lloc del servidor DNS de la proveïdora d'Internet d'un usuari; per tant, hem d'entendre els protocols que estem transportant.

  4. DTLS (datagrama TLS) bàsicament no té usuaris, i IPsec segur que és gran. Un cop hàgim escollit un mecanisme de transport, hem de dissenyar un nou protocol Tor d'extrem a extrem per evitar atacs d'etiquetatge i altres problemes potencials d'anonimat i integritat ara que permetem caigudes, reenviaments, etcètera.

  5. Les polítiques de sortida per a paquets IP arbitraris signifiquen construir un Sistema de Detecció d'Intrusions (IDS) segur. Els nostres operadors de nodes ens diuen que les polítiques de sortida són una de les principals raons per les quals estan disposats a córrer Tor. L'addició d'un IDS per gestionar les polítiques de sortida augmentaria la complexitat de seguretat de Tor, i és probable que no funcioni de totes maneres, com ho demostra tot el camp de document IDS i de documents contra l'IDS. Molts problemes d'abús potencials es resolen pel fet que Tor només transporta fluxos TCP vàlids (a diferència de les IP arbitràries, inclosos els paquets mal formats i les inundacions d'IP). Les polítiques de sortida es tornen encara més importants a mesura que som capaços de transportar paquets IP. També hem de descriure de manera compacta les polítiques de sortida al directori Tor, de manera que els clients puguin predir quins nodes permetran que surtin els seus paquets. Els clients també han de predir tots els paquets que voldran enviar en una sessió abans de triar el seu node de sortida!

  6. Els espais de nom interns de Tor necessiten un redisseny. Donem suport a les adreces ".onion" del servei onion interceptant les adreces quan es passen al client Tor. Fer-ho a nivell IP requerirà una interfície més complexa entre Tor i el solucionador de DNS local.