Acest lucru ar fi util din mai multe motive:
Ar face Tor mai capabil să se ocupe de noi protocoale, cum ar fi VoIP.
Ar putea rezolva întreaga nevoie de a socksifia aplicațiile.
Releele nu ar trebui, de asemenea, să aloce o mulțime de descriptori de fișiere pentru toate conexiunile de ieșire.
Ne îndreptăm în această direcție. Unele dintre problemele dificile sunt:
Pachetele IP dezvăluie caracteristicile sistemului de operare.
Ar trebui să facem în continuare normalizarea pachetelor la nivel IP, pentru a opri lucruri precum atacurile de amprentare TCP.
Având în vedere diversitatea și complexitatea stivelor TCP, împreună cu atacurile de amprentare a dispozitivelor, se pare că cel mai bun pariu al nostru este transportul propriului stack TCP user-space.
Fluxurile la nivel de aplicație au nevoie în continuare de spălare.
Vom avea nevoie în continuare de aplicații pe partea utilizatorului, cum ar fi Torbutton.
Deci, nu va deveni doar o chestiune de captare a pachetelor și anonimizarea acestora la nivelul IP.
Anumite protocoale vor continua să scurgă informații.
De exemplu, trebuie să rescriem cererile DNS, astfel încât acestea să fie livrate unui server DNS nelinkabil, mai degrabă decât serverului DNS la ISP-ul unui utilizator; astfel, trebuie să înțelegem protocoalele pe care le transportăm.
DTLS (datagrama TLS) practic nu are utilizatori, și IPsec sigur este mare.
Odată ce am ales un mecanism de transport, trebuie să proiectăm un nou protocol Tor end-to-end pentru a evita atacurile de marcare și alte potențiale probleme de anonimitate și integritate acum că permitem picături, retrimite, etc.
Politicile de ieșire pentru pachetele IP arbitrare înseamnă construirea unui sistem securizat de detectare a intruziunilor (IDS).
Operatorii nodurilor ne spun că politicile de ieșire sunt unul dintre principalele motive pentru care sunt dispuși să ruleze Tor.
Adăugarea unui IDS pentru a gestiona politicile de ieșire ar crește complexitatea de securitate a Tor și probabil că nu ar funcționa oricum, după cum reiese din întregul domeniu al documentelor IDS și contra-IDS.
Multe probleme potențiale de abuz sunt rezolvate prin faptul că Tor transportă numai fluxuri TCP valide (spre deosebire de IP-ul arbitrar, inclusiv pachete malformate și inundații IP.)
Politicile de ieșire devin și mai importante pe măsură ce devenim capabili să transportăm pachete IP.
De asemenea, trebuie să descriem în mod compact politicile de ieșire din directorul Tor, astfel încât clienții să poată prezice ce noduri vor permite ieșirea pachetelor lor.
De asemenea, clienții trebuie să prezică toate pachetele pe care vor dori să le trimită într-o sesiune înainte de a-și alege nodul de ieșire!
Spațiile de nume interne Tor ar trebui să fie reproiectate.
Susținem adresele serviciului Onion ".onion" prin interceptarea adreselor atunci când acestea sunt transmise clientului Tor.
Acest lucru la nivel de IP va necesita o interfață mai complexă între Tor și resolver-ul DNS local.
Nu, nu puteți avea încredere în rețea pentru a alege calea.
Releele rău intenționate vă pot direcționa prin prietenii lor complice.
Acest lucru ar da un adversar capacitatea de a viziona tot traficul dumneavoastră se încheie.
Solicitarea ca fiecare utilizator Tor să fie un releu ar ajuta la scalarea rețelei pentru a se ocupa de toți utilizatorii noștri și rularea unui releu Tor vă poate ajuta anonimatul.
Cu toate acestea, mulți utilizatori Tor nu pot fi relee bune - de exemplu, unii clienți Tor operează din spatele firewall-urilor restrictive, se conectează prin modem sau altfel nu sunt într-o poziție în care pot relata traficul.
Furnizarea de servicii pentru acești clienți este o parte esențială a furnizării unui anonimat eficient pentru toată lumea, deoarece mulți utilizatori Tor sunt supuși acestor constrângeri sau unor constrângeri similare și inclusiv acești clienți cresc dimensiunea setului de anonimat.
Acestea fiind spuse, dorim să încurajăm utilizatorii Tor să ruleze relee, așa că ceea ce vrem cu adevărat să facem este să simplificăm procesul de configurare și menținere a unui releu.
Am făcut multe progrese în ceea ce privește configurarea ușoară în ultimii ani: Tor este bun la detectarea automată a faptului dacă este accesibil și a lățimii de bandă pe care o poate oferi.
Sunt patru pași pe care trebuie să-i abordăm înainte de a putea face acest lucru:
În primul rând, trebuie să ne îmbunătățim estimarea automată a lățimii de bandă potrivite pentru a permite.
S-ar putea ca trecerea la UDP transport este cel mai simplu răspuns aici - care, din păcate, nu este un răspuns foarte simplu, la toate.
În al doilea rând, trebuie să lucrăm la scalabilitate, atât a rețelei (cum să nu mai impunem ca toate releele Tor să se poată conecta la toate releele Tor), cât și a directorului (cum să nu mai impunem ca toți utilizatorii Tor să știe despre toate releele Tor).
Astfel de schimbări pot avea un impact major asupra anonimatului potențial și real.
A se vedea secțiunea 5 din documentul provocări pentru detalii.
Din nou, transportul UDP ar ajuta aici.
În al treilea rând, trebuie să înțelegem mai bine riscurile de a permite atacatorului să trimită trafic prin releu în timp ce inițiezi, de asemenea, propriul trafic anonimizat.
Trei diferit cercetare lucrări descriu modalități de identificare a releelor într-un circuit prin rularea traficului prin relee de candidați și căutarea unor scăderi în trafic în timp ce circuitul este activ.
Aceste atacuri de înfundare nu sunt atât de înfricoșătoare în contextul Tor, atâta timp cât releele nu sunt niciodată clienți prea.
Dar dacă încercăm să încurajăm mai mulți clienți să activați și funcționalitatea releului (fie ca relee de pod sau ca relee normale), atunci trebuie să înțelegem mai bine această amenințare și să învățăm cum să o atenuăm.
În al patrulea rând, am putea avea nevoie de un fel de schemă de stimulare pentru a încuraja oamenii să transmită trafic pentru alții și / sau să devină noduri de ieșire.
Aici sunt gândurile noastre actuale despre stimulentele Tor.
Vă rog să mă ajutați cu toate astea!
Ar fi frumos să-i lăsăm pe operatorii de relee să spună lucruri precum respingeți www.slashdot.org în politicile lor de ieșire, mai degrabă decât să le impunem să învețe tot spațiul de adrese IP care ar putea fi acoperit de site (și apoi să blocheze și alte site-uri la adresele IP respective).
Totuși, există două probleme.
În primul rând, utilizatorii ar putea obține în continuare în jurul acestor blocuri.
De exemplu, ei ar putea cere adresa IP, mai degrabă decât numele de gazdă atunci când ies din rețeaua Tor.
Acest lucru înseamnă că operatorii ar trebui să învețe în continuare toate adresele IP pentru destinațiile în cauză.
A doua problemă este că ar permite atacatorilor de la distanță să cenzureze site-uri arbitrare.
De exemplu, dacă un operator Tor blochează www1.slashdot.org și apoi un atacator otrăvește DNS-ul releului Tor sau schimbă în alt mod numele gazdei pentru a rezolva la adresa IP pentru un site de știri important, atunci brusc că releul Tor blochează site-ul de știri.
