Názory k článku
Onion routing v p2p sieťach - TOR

Zde jde identita uživatelů najít snadno, podle množství dat poslaných mezi jednotlivými uzly.

Spíš by to chtělo nějakou synchronní síť, kde se packety mezi routery budou posílat pořád stejnou rychlostí bez ohledu na to, jestli někdo komunikuje nebo ne --- to by pak prolomit nešlo, ale bylo by to pomalé a drahé. Existuje něco takového?

jak to myslis s tou identifikaci identity ?

Pokud bude mít nějaká organizace na jednotlivých routerech internetu počítadla množství přenesených dat, tak pak, pokud si v síti TOR stáhneš soubor třeba o velikosti 750MB, tak se z těch počítadel dá snadno vystopovat, přes které uzly jsi to stahoval --- a bude vidět kdo si kolik dat od koho stáhl (nebude však vidět, o jaká data šlo).

Spávně by se to mělo řešit tak, že jednotlivé uzly anonymní sítě, pokud nemají zrovna co na přenášet, si mezi sebou budou posílat náhodné packety. Pak nepůjde vystopovat, kdo od koho kolik dat stáhl, ale bude to žrát víc přenosové kapacity. --- Ještě je tu jeden problém: pokud sledovatel má podezření, od koho soubor pochází, může mu krátkodobě přerušit nebo zahltit linku a zjišťovat, zda se zpomalí download souboru --- tomu by se dalo bránit tak, že soubor bude rozdroben na kousíčky, které budou distribuovány mezi všechny účastníky sítě.

Počítadlá na routeroch vlastne znamenajú globálneho pasívneho útočníka alebo začiatok a koniec tunela musí viesť cez útočníkove routery. Pravdepodobnosť, že tunel bude viesť cez útočníkove routery závisí od zlomku routerov, ktoré v TORe ovláda (binomické rozdelenie). Obecne musí ovládať O(sqrt(n)) routerov zo siete n, aby mal nejakú rozumnú šancu, ale dá sa urobiť oveľa lepší odhad v závislosti od počtu hopov v tuneli

Napr. pravdepodobnosť, že útočník bude mať 2 alebo 3 routre v tuneli ak ovláda p=1/3 siete, je cca 26% (a celkom prudko klesá s nižším podielom v sieti). Tá pravdepodobnosť klesá ako 3*p^2-2*p^3 ako sa p blíži k nule.

Inak podozrenie vlastne znamená traffic confirmation attack, proti ktorému sa TOR nebráni. Ide o to, aby to podozrenie bolo dosť ťažké nájsť.

Zahltiť linku a sledovať či sa spomalí download:
1) útočník musí byť schopný sledovať samotnú linku príjemcu (nevie odkiaľ čo sťahuje ak nevidí aj druhý koniec)
2) útočník musí byť schopný sledovať linku odkiaľ sa sťahuje (=podozrenie=traffic confirmation attack)

Ako som už raz písal, TOR posiela bogus pakety, ale je ich pomerne málo. Na druhej strane, ešte som nevidel, že by sa cez TOR dalo prenášať rýchlejšie než cca. 15-20 kB/s (a 1-5 kB/s je tiež dosť bežná rýchlosť).

Rozdrobenie na kúsočky: fungovalo by to, podobný princíp používa ANts, volá sa to MANET protokol (http://www.myjavaserver.com/~gwren/home.jsp?page=custom&xmlName=resources, pozrite dole na linky). Cena za to je zrejme spoľahlivosť prenosu.

Na druhej strane, častá zmena trasy napomáha predecessor attacku (zistenie, kto je zdrojom komunikácie). Zase závisí na podieli útočníkových routerov v sieti, ako dlho útok musí trvať a akú pravdepodobnosť úspechu zaručuje.

Ten odhad od druhého odstavca je pre tunel dlžky 3, nejak mi to vypadlo.

A O(sqrt(n)) vymeňte za \Omega(sqrt(n))

Pokud vim, tak napr i2p uzlu se rekne, kolik pasma ma k dispozici a on to pasmo vyuziva +- stale => nelze rict, zda prave komunikuje nekdo pres ten uzel nebo zda komunikuje primo dotycny uzel. Respektive tech voleb je tam povicero a cim vic se blizi maximalni dostupne pasmo a pasmo povolene pro routovani, tim bezpecnejsi takovy uzel pro sveho uzivatele je.

TOR používa "relay drop" celly na skrývanie množstva odoslaných dát. Relay drop je v podstate "prázdny paket". Podľa množstva odoslaných dát a ich časovania by bol globálny pasívny útočník (global passive adversary) monitorujúci traffic všade pravdepodobne schopný korelovať toky dát, ale TOR vo svojom bezpečnostnom modeli sa nesnaží brániť tak silnému útočníkovi.

Náklady na stanie sa globálnym pasívnym útočníkom sú obrovské. Jedna z možností je data retention, ale pokiaľ mi je známe, tak informácie o takýchto streamoch by sa neukladali (tuším len http na štandardnom porte 80 a maily cez SMTP na porte 25 sú sledované).

Oveľa viac možností proti rozličným útočníkom ponúka I2P (o tej bude reč nabudúce), napr. príkazy (optiony) na vkladanie pozdržaní, strict ordering. I2P tiež ešte nemá mnoho z toho zatiaľ implementované, plánuje sa to postupne do nasledujúcich verzií. Inak paradoxne práve používanie špeciálnych príkazov napr. na zvýšenie latencie môže odhaliť identitu ak sa príkazy budú líšiť moc od "bežných optionov".

Ještě by šla zjistit identita poskytovatele dat v TORu, jak jsem popsal výše --- někomu krátkodobě zahltím linku příkazem ping -f (k tomu ani nemusím vlastnit žádný router) a zjišťuji, zda se zpomalil download souboru.

To je ale nepravdepodobny, pokud se nad anonymni siti pouzije jeste torrent. To by potom musel mit utocnik opravdu "z prdele kliku" a mit podezreni na uvodniho seeda uz hodne dlouho pred zahajenim sdileni. Jenze i tak je to v tomhle pripade asi pouzitelny jen stezi a jen pri velkym stesti.

Nemluve o tom, ze spojovat DOS s aktualnim zpomalenim pritoku dat je IMO velmi obtizne, az nemozne, to muze byt cira nahoda.

me jako slabe misto prijdou adresarove servery. momentalne jsou jen 3 a tor spoleha na to, ze jejich admini jsou mirkove dusinove. zkusil bych je zkorumpovat. kdyz by to nevyslo, tak z trucu aspon ty jejich servery zaDDOSovat ;)

Adminov je síce možné podplatiť, ale niekto dobrovoľne spravujúci také servery bude mať asi vysokú cenu ;-) Možno by bolo lacnejšie kompromitovať tie servery, ale bude to mať obmedzenú účinnosť. Druhá vec, adresárové servery sú len pre skryté služby, čiže neovplyvníte funkčnosť TOR ako proxy. To by šlo, keby sa vám ako insiderovi v projekte podarilo vymeniť zoznam TOR routerov (ktoré sú distribuované so software) vymeniť za zoznam s mnohými útočníkovými servermi, ale to by na to časom niekto prišiel.

Ale je pravda, že časom bude treba adresárové servery nahradiť niečím rozumnejším (ako to robí I2P - NetDb na báze Kademlie).

z nalinkovaneho dokumentu ( http://tor.freehaven.net/cvs/doc/design-paper/tor-design.html) jsem to prave pochopil jinak:

Certain more trusted nodes act as directory servers: they provide signed directories describing KNOWS ROUTERS and their current state.

Each such directory server acts as an HTTP server, so clients can fetch current network state and ROUTER LISTS, and so other ORs can upload state information.

distribuovani seznamu routeru s klientem mi prijde dost tezkopadne. pokud by teda ten klient v sobe nemel nejaky updatovaci mechanizmus. ale i tak by potreboval nova data brat z nejakych duverchodnych zdroju (zeby nejakych "adresarovych serveru"?)

a ty adminy jsem chtel korumpovat (ne nutne penezi) prave proto, abych mel kontrolu nad tim seznamem routeru. kompromitaci nekolika adresarovych serveru bych totiz na sebe jen upozornil - servery by nebyly schopne se domluvit na stejnem adresari, zacaly by se hadat a toho by si admini vsimli.

ale kombinace obojiho bude asi lepsi. vy kompromitujete par serveru a admina/y ostatnich zkorumpujem. ;)

distribuovani seznamu routeru s klientem mi prijde dost tezkopadne. pokud by teda ten klient v sobe nemel nejaky updatovaci mechanizmus. ale i tak by potreboval nova data brat z nejakych duverchodnych zdroju (zeby nejakych "adresarovych serveru"?)

Jj, máte pravdu. Som to písal spamäti a nejak mi "nezoplo", že updatovací mechanizmus potrebuje tie servery ;-)

a ty adminy jsem chtel korumpovat (ne nutne penezi) prave proto, abych mel kontrolu nad tim seznamem routeru. kompromitaci nekolika adresarovych serveru bych totiz na sebe jen upozornil - servery by nebyly schopne se domluvit na stejnem adresari, zacaly by se hadat a toho by si admini vsimli.

Directory servery sú asi najzraniteľnejšou časťou, na tom sa asi zhodneme. Momentálne je 5 directory serverov (tá dokumentácia je trocha staršia, pozrite /var/lib/tor/*). IMHO by ste ale museli kompromitovať samotných adminov, predstavme si situáciu: každý admin pravidelne zálohuje zoznam serverov na offline médium a zálohy sú pravidelne oproti sebe kontrolované na "podozrivo veľké zmeny". Update zoznamu routerov by sa robilo zo zálohy alebo by sa záloha skontrolovala oproti aktuálnemu zoznamu. Tým by sa odhalil kompromitovaný server (neviem či to tak robia). Cena kompromitácie je teda rozhodne vysoká (a to nemyslím len peniaze).

Ma práve napadlo, že s tou kompromitáciou directory serverov to bude trocha zložitejšie. Útočník by mohol na server dať rootkit, ktorý žiadosť na súbor so zoznamom routerov bude presmerovávať na nejaké podivné miesto (iný súbor, Host Protected Area na disku, atd.), čím by admin nezistil zmenu, kým by sa nepozrel jak vyzerá posielaný zoznam routerov "zvonka", tj. z iného stroja. Stále zostáva cena útoku dosť vysoká, tj. spravodajské služby by to asi zvládli, ale to by museli mať sakra dôvod.

tak snad se o to jejich admini dobre staraji. treba me by se v techle vedrech vuubec nechtelo ;)

http://torpark.nfshost.com/
Mate nekdo zkusenosti s timto programkem?

To vyzerá ako staticky zlinkovaný TOR klient, takže funkčnosť by mala byť úplne rovnaká ako u bežného klienta.

Inak pozrite na tú správu v linku hore (http://www.eff.org/deeplinks/archives/004741.php). Vláda USA vyhlásila, že ak bude niekoho odpočúvať a nakoniec sa ukáže, že to bolo ilegálne, tak aj tak je to beztrestné, pretože súd nemôže dokázať, že taký odpočúvací program oficiálne existuje, napriek tomu, že sa už o ňom písalo mnohokrát. Tak tomu hovorím šalamúnske riešenie.

Cibulove smerovanie-genialne