ZAVOD ZA ELEKTRONIKU, MIKROELEKTRONIKU, RAČUNALNE I INTELIGENTNE SUSTAVE FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA SVEUČILIŠTE U ZAGREBU DIPLOMSKI RAD br. 1871 SIMULATOR PROTOKOLA TOR Ivan Šipka Zagreb, listopad 2010. Posveta Elizabeti i Marii. Domagoju, jer jest. Zahvala Mami i tati, inače, a i zato jer su platili tri stotine tisuća kuna kako bi ovaj rad mogao ugledati svjetlo dana. Mentorima na podršci i razumijevanju. Najboljoj studentskoj službi. Sažetak U ovom radu dan je kratak pregled anonimnih računalnih mreža, njihove strukture i povijesti. Osim toga, opisan je protokol Tor te ostvarenje skrivenih usluga u protokolu i njihova nepostavljena poboljšanja. U praktičnom dijelu rada opisan je automat stanja protokola te je podskup protokola ostvaren nad INET okvirom OMNeT++ simulacijskog okruženja. Abstract This work gives a short overview of anonymous computer networks, their structure and history. Besides that, Tor protocol is described alongside with its hidden service implementation and their undeployed improvements. The practical part of this work presents Tor protocol as state machine diagrams, and implements the protocol subset upon INET framework of OMNet++ simulation environment. Sadržaj 1. Uvod...................................................................................................................................1 2. Anonimnost na Internetu....................................................................................................2 2.1. Struktura anonimnih mreža...................................................................................................5 2.2. Ograničenja anonimnosti na Internetu..................................................................................9 2.3. Povijest anonimnih mreža...................................................................................................10 2.3.1. Mreže s visokim kašnjenjem....................................................................................................... 10 2.3.2. Mreže s niskim kašnjenjem......................................................................................................... 11 3. Protokol Tor.....................................................................................................................14 3.1. Virtualni kanali i kriptiranje ukupnog informacijskog toka....................................................17 3.2. Poslužitelji registri mreže ...................................................................................................21 3.3. Algoritam za odabir puta.....................................................................................................24 3.4. Upravljanje zakrčenjem i tokom..........................................................................................26 3.5. Skrivene usluge.................................................................................................................. 28 3.5.1. Čvorovi susreta i čvorovi uvoda.................................................................................................. 29 3.5.2. Lociranje skrivenih usluga........................................................................................................... 30 3.5.3. Čvorovi stražari........................................................................................................................... 31 3.5.4. Čvorovi sluge.............................................................................................................................. 32 3.5.5. Povezivanje s korisničkim programima.......................................................................................33 4. Automati stanja simulacijskih elemenata.........................................................................35 4.1. Tor posrednik...................................................................................................................... 36 4.1.1. Upravljačka komponenta............................................................................................................ 36 4.1.2. Virtualni kanal............................................................................................................................. 38 4.1.3. Tok.............................................................................................................................................. 40 4.2. Tor usmjernik ..................................................................................................................... 41 4.2.1. Upravljačka komponenta............................................................................................................ 41 4.2.2. Virtualni kanal............................................................................................................................. 43 4.2.3. Tok.............................................................................................................................................. 45 4.3. Promet dokumentima stanja...............................................................................................45 5. Praktični rad.....................................................................................................................47 5.1. OMNeT++ INET ................................................................................................................. 48 5.2. Ostvarenje protokola Tor ...................................................................................................51 5.2.1. TCP ljuska.................................................................................................................................. 52 5.2.2. TLS sloj....................................................................................................................................... 55 5.2.3. Tor sloj........................................................................................................................................ 56 5.2.4. Korisnička aplikacija.................................................................................................................... 60 5.3. Simulacija........................................................................................................................... 61 6. Zaključak..........................................................................................................................68 7. Popis kratica.....................................................................................................................69 8. Literatura..........................................................................................................................71 Dodatak A: Gramatike dokumenata stanja..........................................................................73 Dodatak B: Protokolne podatkovne jedinice........................................................................75 Dodatak C: Metrike anonimnosti..........................................................................................78 Dodatak D: Analiza anonimnosti virtualnog kanala ............................................................79 Dodatak E: Definicije i opaske.............................................................................................80 1. Uvod Javno dostupna anonimna komunikacijska usluga po definiciji dozvoljava zlouporabu, no s druge strane osnovna motivacija za projektiranje tog sustava grubo je kršenje osnovnih ljudskih prava, odnosno slobode govora. Neki od poznatijih primjera su Veliki kineski vatrozid, Burma gdje se samo spajanje na Internet smatra disidentskim činom, Egipat gdje spajanje na Internet nije moguće bez identifikacijskog broja građana ili velike količine drugih osobnih podataka. U Iranu, Turkmenistanu, Uzbekistanu, Vijetnamu, Kubi, Siriji i Tunisu zatvaraju se korisnici koji posjećuju nepoćudne stranice sa "mogućim težim posljedicama", dok u Sjevernoj Koreji vlada apsolutna cenzura te država koristi internet za propagandu iako mu samo 4% stanovništva ima pristup. Osim ovih ekstremnih slučajeva, gotovo u svim demokratskim zemljama zlouporabljuje se dostupnost dnevnika mrežnog prometa građanstva, od prodaje podataka privatnim tvrtkama za komercijalne svrhe do perfidnijih varijanti poput osvete institucija/organizacija ljudima koji iznose nepoćudne informacije [37]. Poznati su projekti Carnivore i Echelon iz SAD-a, koji pod krinkom nacionalne sigurnosti prisluškuju i obrađuju promet na Internetu. Njemačka također krši slobodu govora zabranjivanjem pristupa određenim stranicama. Europska unija u trenutku pisanja ovog rada želi pokrenuti praćenje svih "ekstremnih" grupa, no to je formulirano tako da sve što odstupa od "normalnog"može biti tumačeno kao "ekstremno". Ovakva definicija ekstremizma vrlo je opasna za slobodu upravo zbog fleksibilnosti, pogotovo kada se doda podatak kako je također predloženo registriranje svih blogera na području Unije. Socijalne mreže omogućile su pristup podacima koje je prije bilo nezamislivo pribaviti u takvom obimu, a trošak nabave ne postoji – obzirom da korisnici sami postavljaju podatke. Jedan benigan primjer jest da je stanovita tvrtka posluživala stranice s lažnim nižim cijenama kada bi se detektiralo da su posjetitelji iz konkurentske tvrtke [19]. Zlouporaba, iako olakšana postojanjem anonimne mreže, ne bi nestala ukidanjem takve usluge, ali bi obični ljudi time izgubili mogućnost sigurnog korištenja Interneta. Najbolji dokaz jest da su Reporteri bez granica i EFF objavili detaljne upute kako koristiti Tor1 odmah po uključivanju skrivenih usluga2 u protokol u proljeće 2004. god. Razlog tome dijelom leži u činjenici da godišnje na zadatku pogine i do nekoliko stotina novinara [47]. Tor je postavljen u radno stanje u listopadu 2003. godine. Projekt je objavljen je pod GPL kompatibilnom MIT licencom, što znači da je izvorni tekst projekta javno dostupan. Tor projekt između ostalog financiraju nevladine udruge i privatni korisnici te američka vlada koja ga koristi za slanje elektroničke pošte. Iako je objavljen dizajn za anonimiziranje telefonskih sustava kao što je ISDN, a donekle i GSM, ovaj rad baviti će se ožičenim anonimnim računalnim mrežama, tj. Tor mrežom. Zahtjevi anonimne komunikacije u suprotnosti su s osnovnim zadatkom mrežnog i prijenosnog sloja OSI modela. Mrežni sloj zadužen je za logičko adresiranje čvorova mreže, dok je prijenosni sloj između ostalog zadužen za što veću brzinu prijenosa podataka, iz čega je jasno kako je konkretno ostvarenje vrlo izazovan zadatak. Predmet ovog rada je simulacijski model Tor mreže. U prvom dijelu rada daje se kratak pregled anonimnih računalnih mreža, potom slijedi opis protokola te simulacijski model i dodatak. 1 Tor je akronim za engl. "The Onion Routing", u prijevodu: slojevito usmjeravanje. Tor protokol ostvaruje anonimnu komunikacijsku uslugu sa niskim kašnjenjem, temeljenu na virtualnim kanalima. Tor mreža je raspodijeljena prekrivajuća partnerska mreža dizajnirana kako bi se omogućilo anonimno korištenje aplikacija koje koriste TCP, poput pretraživanja Interneta, korištenja sigurne ljuske te raznih programa za video, audio i tekstualnu komunikaciju. Koristi TCP odnosno TLS protokol. 2 Skrivene usluge (engl. location hidden services) omogućuju postavljanje mrežne usluge, poput Web stranice, bez da klijenti vide IP adresu usluge. 1 2. Anonimnost na Internetu Anonimnost dolazi od grčke riječi anonymia što u doslovnom prijevodu znači "bezimeno" [5]. U kolokvijalnoj upotrebi označava nemogućnost određivanja identiteta nekog entiteta, npr. kratak poziv s telefonske govornice bez predstavljanja, djelo nepoznatog autora i sl.. Dakle, nemogućnost imenovanja osobe. "Anoniman poziv" u kontekstu ovog rada može značiti nemogućnost lociranja telefonske govornice s koje je obavljen poziv. U nekom drugom scenariju "anoniman poziv" mogao bi značiti nemogućnost prisluškivanja prometa na kanalu. Osnovno je pitanje prema kome se želi biti anoniman, odnosno što je prema čemu anonimno. Pri komunikaciji računalnom mrežom moguće je da je dostupna logička adresa korisnika na mreži, koja može biti povezana s geografskom lokacijom ili pokretom te može biti povezana i sa stvarnim identitetom korisnika [28]. Na slici 2.1 prikazana je globalna računalna mreža Internet kao skup međusobno povezanih autonomnih sustava koji koriste BGP za usmjeravanje. Autonomni sustav je skup međusobno povezanih TCP/IP čvorova sa jasno definiranom politikom usmjeravanja. Obično su to pružatelji mrežnih usluga (ISP), ali mogu biti i privatne organizacije. Slika 2.1: Internet kao skup međusobno povezanih autonomnih sustava. Klijenti se na Internet povezuju preko različitih tipova mreža koristeći različite protokole o čemu izravno ovisi njihova anonimnost. Primjerice, korisnik koji se spaja na Internet preko kućnog računala koristeći priključak javne telefonske mreže nije anoniman u odnosu na lokalni autonomni sustav. Pružatelju mrežne usluge dostupan je dnevnik koji povezuje logičku odnosno IP adresu korisnika s telefonskim priključkom, odnosno adresom i identitetom vlasnika priključka. S druge strane, korisniku koji se s pomoću prijenosnog računala povezuje na javnu gradsku bežičnu mrežu moguće je odrediti samo logičku odnosno MAC adresu. Korisnike bežičnih mreža moguće je locirati uz dodatno uložen trud koji ovisi o konkretnoj mreži preko koje je korisnik povezan. Ukoliko mrežni resurs koji korisnik zatraži nije dostupan unutar lokalnog autonomnog sustava promet se preusmjerava prema definiranoj politici usmjeravanja vanjskim autonomnim sustavima (A i B na slici 2.1). Vanjskom autonomnom sustavu logička IP adresa ne otkriva identitet korisnika, ali je ipak moguće narušiti anonimnost korisnika. Krajnji korisnici nemaju stalne IP adrese pa je puno upotrebljiviji, tj. trajniji, identifikator HTTP kolačić (engl. cookie) koji sadrži razne informacije, a u pravilu služi za autentifikaciju klijenta na poslužitelju. Osim toga, moguće je doći i do stvarnog identiteta ukoliko korisnik primjerice provjerava elektronsku poštu ili koristi socijalne mreže upotrebljavajući pri tom pravo ime. Na taj način 2 2. Anonimnost na Internetu moguće je stvarati dnevnike mrežnog prometa građanstva. Svaki autonomni sustav u potpunosti može promatrati i mijenjati promet koji opslužuje. Neke državne i međudržavne organzacije (vlade, policije, Interpol i sl.) u pravilu mogu doći do dnevnika mrežnog prometa pravnim putem. Očito je da anonimnost krajnjih korisnika Interneta može biti ugrožena bez njihova znanja. Kako bi se moglo sustavno govoriti o anonimnosti potrebno je prvo definirati stupanj njene ugroženosti. Napadač se definira kao entitet koji želi djelomično ili potpuno deanonimizirati sustav. Može to učiniti tako da poveže primatelja i pošiljatelja, identificira primatelja ili pošiljatelja konkretne poruke te onemogući sam sustav. Napadač po snazi napada može biti aktivan odnosno unutarnji ili pasivan odnosno vanjski. Aktivni ili unutarnji napadač može kompromitirati čvorove, tj. upravlja dijelom čvorova sustava, a može mijenjati poruke. Vanjski ili pasivni napadač može kompromitirati veze, tj. nema kontrolu nad nijednim čvorom, ali može prisluškivati promet među njima. Napadač po opsegu može biti lokalan ili globalan. Globalni napadač je sveprisutan i ima pristup cijeloj mreži odnosno svim vezama i čvorovima. Lokalni napadač je ograničeno sveprisutan i ima pristup dijelu mreže odnosno dijelu veza i čvorova. Napadač po prilagodljivosti može biti statički ili dinamički. Dinamčki napadač prikuplja sve raspoložive podatke s kompromitiranih veza i čvorova kako bi otkrio tko je poslao ili primio koju poruku, tj. koristi apriorno i aposteriorono znanje. Statički napadač koristi samo apriorno znanje. Najčešće je napadač dinamički [28]. Metode kvantifikacije anonimnosti su mnogobrojne pa će se ovdje spomenuti samo najjednostavnija i najstarija metoda, kvantifikacija pomoću kardinalnog broja skupa [29]. Vrlo kratak pregled preostalih metrika anonimnosti dan je u dodatku C. Na slici 2.2 prikazani su najveći mogući skupovi anonimnosti pošiljatelja i primatelja u odnosu na globalnog aktivnog napadača [20]. Skup anonimnosti korisnika sustava u odnosu na napadača skup je svih korisnika sustava, kao na slici 2.2. Skup anonimosti primatelja za zadanog pošiljatelja u odnosu na napadača skup je svih pošiljatelja za koje napadač zna da su mogli poslati poruku primatelju kao na slici 2.4. Anonimnost je razmjerna kardinalnom broju skupa anonimnosti. Ovaj koncept široko je usvojen i koristi se za kvantifikaciju svojstava anonimnosti. Slika 2.2: Anonimni komunikacijski sustav, korisnici i napadač. Temeljna svojstva anonimnosti podrazumijevaju nemogućnost identificiranja (engl. unidentifiability) i nepovezivost (engl. unlinkability) [20] [28] [32]. Nemogućnost identificiranja podrazumijeva anonimnost pošiljatelja (engl. sender anonimity), anonimnost primatelja (engl. reciever anonimity), uzajamnu anonimnost (engl. mutual anonimity) te lokacijsku anonimnost (engl. location anonimity) i grupnu anonimnost (engl. group anonimity). Anonimnost primatelja znači da identitet primatelja ostaje skriven pri primanju poruke. Drugim riječima, napadač ne može povezati konkretnu poruku s konkretnim primateljem, već sa skupom 3 2. Anonimnost na Internetu anonimnosti primatelja. Anonimnost pošiljatelja znači da identitet pošiljatelja ostaje skriven pri slanju poruke. Drugim riječima, napadač ne može povezati konkretnu poruku s konkretnim pošiljateljem, već sa skupom anonimnosti pošiljatelja. Uzajamna anonimnost znači da identitet primatelja ostaje skriven od identiteta pošiljatelja i obrnuto. Lokacijska anonimnost znači da napadač ne može povezati nijednu konkretnu poruku s mjestom, gibanjem, rutom ili topološkim informacijama. Grupna anonimnost znači da identitet grupe kojoj je poruka poslana ostaje skriven. Drugim riječima, napadač ne može povezati nijednu konkretnu poruku s grupom ili konkretnom grupom korisnika. Nijedan poznati sustav ne ispunjava grupnu anonimnost. Predmet interesa (engl. item of interest) predstavlja bilo koji entitet koji može biti interesantan u smislu narušavanja anonimnosti: idenitifikator – ime, pseudonim ili digitalni pseudonim; slanje ili primanje poruke, poruka sama, pravna ili stvarna osoba, čvor pošiljatelj ili primatelj, vanjski ili unutarnji čvor, naručitelj ili izvršitelj neke akcije u sustavu [20]. Nepovezivost znači da napadač ne može povezati predmete interesa, tj. da apriorno znanje ostaje jednako aposteriornom znanju – znanju dobivenom nakon napada. Nepovezivost podrazumijeva komunikacijsku anonimnost (engl. communication/relationship anonimitiy) [18] [28] i grupnu komunikacijsku anonimnost (engl. group communication anonimity) [28]. Komunikacijska anonimnost znači da napadač ne može konkretnu poruku povezati s bilo kojim parom pošiljateljprimatelj odnosno da ne može povezati bilo koju poruku s konkretnim parom pošiljatelj-primatelj. Grupna komunikacijska anonimnost analogna je komunikacijskoj anonimnosti samo što se umjesto para pošiljatelj - primatelj uzima par grupa pošiljatelja – grupa primatelja. Pseudonim je identifikator entiteta koji ne sadrži njegov pravi identitet [20]. U doslovnom prijevodu s grčkog znači "lažno nazvan" [5]. Korištenje pseudonima jedan je od kritičnih mehanizama za postizanje anonimnosti. Definicije identiteta i neuočljivosti dane su u dodatku E. Anonimnost je moguće promatrati u ovisnosti o obliku komunikacije koja se odvija između pošiljatelja i primatelja [32]. Većina komunikacije odvija se pomoću TCP-a – koji se temelji na vezama što je analogno komutaciji kanala – ali se dobar dio komunikacije u višim slojevima, primjerice elektronska pošta, temelji na porukama što je analogno komutaciji paketa. Anonimnost sustava temeljenog na porukama jednostavniji je problem od anonimnosti sustava temeljenog na vezama, jer su veze znatno trajniji entiteti od poruka. Slika 2.3: Anonimizirajući OSI model. 4 2. Anonimnost na Internetu Općenito govoreći, komunikacijski protokoli pretpostavljaju identifikaciju čvorova u normalnom radu te je takve identifikatore potrebno odstraniti, odnosno zamijeniti pseudonimima. Globalna računalna mreža čije će čvorove osiguravati dobrovoljci mora biti lako postavljiva u radno stanje. Stoga se anonimiziranje računalnih mreža vrši iznad prijenosnog odnosno prezentacijskog sloja OSI modela, jer bi u suprotnom bile potrebne preinake mrežnog stoga operacijskih sustava čvorova domaćina. Uz takva ograničenja i krajnji korisnik anonimne mreže mora biti svjestan da mora koristiti anonimnu mrežu na anoniman način. Anonimne mreže razvile su se u dvije osnovne kategorije – mreže s visokim i niskim kašnjenjem. Mreže s visokim kašnjenjem nisu prikladne za interaktivne zadaće kao što su: surfanje Internetom, video, audio ili tekstualnu komunikaciju te SSH promet. Međutim, sigurnije su od mreža s niskim kašnjenjem. Uglavnom se koriste za slanje elektronske pošte. Mreže s visokim kašnjenjem temeljene su na porukama, dok su mreže s niskim kašnjenjem temeljene na vezama. 2.1. Struktura anonimnih mreža U ovom potpoglavlju dan je pregled metoda za postizanje anonimnosti. Anonimnost primatelja može se postići kombiniranom upotrebom difuzije i implicitnih adresa. Osnovna ideja prikazana je na slici 2.4. Umjesto da se poruka šalje jednom primatelju, šalje se skupu primatelja. Kako bi primatelj mogao znati da je poruka namijenjena njemu, ista mora sadržavati informaciju po kojoj se može prepoznati da je poruka namijenjena točno tom primatelju i nikome drugome. Ta informacija je implicitna adresa i može biti ostvarena upotrebom asimetričnog kriptosustava. Slika 2.4: Anonimnost primatelja upotrebom difuzije i implicitnih adresa. Na slici 2.4 također je prikazana i slabost ove metode: Ukoliko napadač kontrolira sve primatelje osim pravog u skupu anonimnosti primatelja, pravi primatelj je kompromitiran. Osim što pošiljatelj nije anoniman, ova metoda ne može se dovoljno dobro skalirati da bi bila od praktične vrijednosti. Metoda za postizanje anonimnosti pošiljatelja i primatelja temelji se na poznatom Chaumovom problemu kriptografa na večeri koji je prikazan na slici 2.5. Troje kriptografa nakon večere u restoranu bivaju obaviješteni da je večera plaćena. Mogao ju je platiti bilo tko od njih ili njihov poslodavac (NSA). Ne žele saznati tko je od njih platio večeru, ali žele saznati ako je večeru platio poslodavac. Slika 2.5: problem tri kriptografa Stoga postupaju po sljedećem protokolu: svaki kriptograf baca novčić tako da ishod bacanja vidi samo njegov lijevi susjed. Ako su oba bacanja različita svaki od njih izjavljuje "različito", inače izjavljuje "isto". Međutim, ako je neki kriptograf platio večeru on izjavljuje suporotno od stvarnog 5 2. Anonimnost na Internetu ishoda. Ako je broj odgovora "isto" paran, poslodavac je platio večeru - na slici 2.5 lijevo, inače je netko od kriptografa platio večeru - na slici 2.5 desno. Izjavljujući samo jesu li oba bacanja ista ili različita gubi se dio informacije o ishodima bacanja što jamči anonimnost kriptografu koji je platio večeru. Na ovom načelu temelje se DC mreže. Svi partneri spojeni su tako da tvore potpuno povezani graf te svaki sa svakim dijeli zajednički ključ. Svaki partner računa modulo dva sumu svih ključeva koje posjeduje – što je analogno bacanju novčića – te je šalje svim ostalim partnerima - što je analogno izjavljivanju ishoda. Potom svaki partner računa modulo dva sumu svih primljenih suma. Ako je svaki partner poslao korektnu sumu tada modulo dva suma svih primljenih suma iznosi nula, jer se svaki ključ zbraja sam sa sobom dva puta – svaki par partnera dijeli ključ. To znači da nijedan partner nije poslao poruku, što je analogno tome da je poslodavac platio večeru. Inače, ako partner želi poslati poruku prije slanja komplementira sumu pa je modulo dva suma svih suma jedan – što je analogno tome da je netko od kriptografa platio večeru [33]. Ukoliko više partnera istovremeno šalje poruku dolazi do kolizije. Obzirom da su DC mreže i u teoriji slabo obrađene neće se dalje razmatrati. DC mreže nisu praktično upotrebljive jer prepostavljaju uspostavljanje zatvorenog skupa anonimnosti tj. infrastrukture ključeva prije slanja poruka, imaju veliki višak prometa te je potrebna i logika za detektiranje kolizije [32]. Usmjernik mješač je osnovni gradivni element za anonimne pošiljaoce elektroničke pošte. Prvi mješač, mješač s pragom (engl. threshold mix) uveo je David Chaum u teoretskoj mreži MIX-Net [29]. To je usmjernik koji prima poruke, a prosljeđuje ih tek kada je primio zadani broj (prag) poruka. Mješač s bazenom (engl. pool mix) prima poruke te nakon što prođe zadani interval vremena, slučajnim redoslijedom prosljeđuje neke od njih. Kontinuirani ili stani-kreni mješač (engl. continuous/stop-and-go mix) svaku poruku zadržava određeno vrijeme koje je nasumce zadano po eksponencijalnoj razdiobi. Mješači se mogu slagati u prospojne mreže (engl. cascades) odnosno nizove usmjernika otežavajući tako dodatno analizu prometa. Zato su i sve poruke iste duljine. Poruka se prije slanja kriptira javnim ključem svakog MIX čvora na putu što osigurava tajnost i integritet prometa. Na slici 2.6 poruke su označene velikim slovima, a svaki krug predstavlja sloj enkripcije. Svaki čvor na putu dekriptira poruku i prosljeđuje ju sljedećem. Slika 2.6: MIX-Net: lukovo usmjeravanje kroz prospojnu mrežu mješača s pragom. Slika 2.7: MIX-Net: slojevito usmjeravanje kroz prospojnu mrežu mješača s pragom. 6 2. Anonimnost na Internetu MIX čvorovi odabiru se po uniformnoj razdiobi, a svaki čvor na putu zna samo za svog prethodnika i sljedbenika. Ni prvi čvor na putu ne zna prima li poruke od korisnika ili drugog čvora. Time je osigurana anonimnost pošiljatelja. Kako je MIX-Net namijenjen za jednosmjernu komunikaciju ne postoji anonimnost primatelja. Time je ispunjena i uzajamna anonimnost. Lokacijska anonimnost, koja je definirana kao pojam tek 2009. godine [28], pretpostavlja se kroz uvjet da čvorovi nisu kompromitirani. Nepovezivost se postiže kašnjenjem prometa na putu što je detaljnije objašnjeno u sljedećem potpoglavlju. Dakle, anonimnost je zajamčena. Ova metoda poznata je kao slojevito usmjeravanje prve generacije (engl. onion routing). Ako je potrebna dvosmjerna komunikacija, moguće ju je osigurati upotrebom pseudonima. Svaki enkripcijski sloj uz poruku sadrži i identifikatore prethodnika i sljedbenika. Obzirom da čvorovi na putu posreduju za pošiljatelja, a ni prvi čvor ne zna da je njegov prethodnik upravo pošiljatelj, može se reći kako su identifikatori čvorova na putu pseudonimi pošiljatelja. Kada se radi o interaktivnoj dvosmjernoj komunikaciji nužno je uspostavljanje i održavanje trajnije veze između izvorišta i odredišta, kao i nisko kašnjenje prometa kroz sustav što narušava nepovezivost. Što vrijeme dulje prolazi opasnost od kompromitacije je veća, odnosno anonimnost veza obrnuto je razmjerna njihovu trajanju. Stoga je bitno da se nakon isteka zadanog intervala vremena izgradi nova veza. Slojevito usmjeravanje sa spajanjem poruka (engl. garlic routing) varijanta je slojevitog usmjeravanja kod kojeg različite poruke prolaze po etapama puta proizvoljno spojene kako bi se otežao napad analizom prometa. Slika 2.8: slojevito usmjeravanje sa spajanjem poruka u I2P-u, slanje višestruko kriptirane poruke B kroz jednosmjerni kanal sastavljen od izlaznog tunela izvorišta i ulaznog tunela odredišta Za ostvarenje anonimne mrežne usluge, tj. tzv. skrivene usluge, potrebno je osigurati stalnu dostupnost odredišta upotrebom pseudonima, kao i da izvorište i odredište ne komuniciraju izravno kako bi zahtjev anonimne komunikacije ostao zadovoljen. Izvorište i odredište povezuju se na čvor susreta koji je prethodno definiran pseudonimom usluge te preko njega ostvaruju komunikaciju. Radi postizanja zadovoljavajuće anonimnosti povezivanje se u pravilu vrši preko više posrednika. Koncept skrivenih usluga prvi puta je iznesen u sustavima za ISDN telefoniju. Rješenja koja su se kasnije pojavila koristila su točke susreta kao metodu skrivanja lokacije mobilnih telefona. Prva upotreba u komunikacijskim sustavima na Internetu predložena je u ranim radovima vezanim za slojevito usmjeravanje, ali je prvi upotrebljivi dizajn objavio Ian Goldberg u disertaciji “PIP Pseudonymous Internet”. Anonimne mreže može se podijeliti na ožičene i bežične. Bežične mreže izlaze iz okvira ovog rada, dok se ožičene mogu dalje podijeliti prema topologiji na partnerske mreže te kaskadne sustave i 7 2. Anonimnost na Internetu sustave sa slobodnim odabirom puta. Daljnja podjela moguća je prema strategiji usmjeravanja, s time da kaskadni sustavi i sustavi sa slobodnim odabirom puta koriste isključivo jednoodredišno usmjeravanje, dok partnerske mreže uz spomenutu strategiju koriste difuziju, difuziju u grupi i difuziju u proizvoljnoj grupi (engl. anycast) – od svih poslanih poruka samo jedno odredište dobiva poruku. Posljednji kriterij je isporučena anonimnost. Ova podjela grafički je prikazana na slici 2.8, a zove se kubična taksonomija anonimnih mreža [28]. Slika 2.9: Kubična taksonomija anonimnih mreža. 2.2. Ograničenja anonimnosti na Internetu Anonimne mreže moraju jamčiti potrebnu razinu anonimnosti korisnicima. Mjera za kvalitetu naziva se stupanj anonimnosti i predstavlja otpornost sustava na napadača. Iz perspektive sustava modelira se napadač. Model vanjskog pasivnog napadača neovisan je o ostvarenju sustava, dok je model aktivnog unutarnjeg napadača ovisan o konkretnom ostvarenju. Odabiranje odredišta od strane korisnika dvojake je prirode: u osnovi je slučajno, ali ipak slijedi neke pravilnosti – vjerojatno je da će se korisnici vraćati na neke stranice te je manje vjerojatno da će svi korisnici posjećivati sve stranice. To znači da je promatranjem ulaza i izlaza sustava promet na njima moguće vrednovati metodama stohastičke analize, ponajprije teorije vjerojatnosti. U tom smjeru, shvati li se anonimni korisnik kao onaj o kojem napadač ne zna dovoljno da bi ga mogao identificirati, može se reći kako taj korisnik ima dovoljno visoku informacijsku entropiju. Nasuprot tome, želi li se u potpunosti kompromitirati sustav, osnovni problem postaje sparivanje ulaza i izlaza sustava što je poznat problem iz teorije grafova. Napadač može promatrati i promet na kanalu, tj. brojati ga i bilježiti u vremenu pa se sparivanje može provesti korelacijskim metodama. Želi li se dati globalna ocjena sustava potreban je matrični račun, a i problem savršenih sparivanja ekvivalentan je problemu računanja permanenta matrice. Kada bi korisnici potpuno nasumično odabirali odredišta, tj. kada bi raspodjela korisnika po odredištima bila uniformna za svakog korisnika, jedina metoda razlikovanja informacijskih tokova kroz sustav bila bi korelacija prometa u vremenskoj domeni. Kada bi korisnici bili stalno spojeni na sustav i stalno slali podatke, jedini način koji bi preostao napadaču bio bi da selektivno blokira ulaze sustava te promatra koji su informacijski tokovi na izlazima nestali [18]. Potonje pretpostavlja aktivnog napadača. 8 2. Anonimnost na Internetu Dakle, idealan, odnosno anonimni komunikacijski sustav je onaj čije ulaze i izlaze ne može blokirati napadač dok korisnici ostaju stalno spojeni na sustav povezujući se neprestano na potpuno nasumična odredišta. Očito, ovakav je zahtjev gotovo nemoguće zadovoljiti u okviru postojeće komunikacijske infrastrukture, ali je otvoreno pitanje koliko mu se može približiti. Globalni pasivni napadač koji poznaje ponašanje korisnika, tj. poznaje dovoljno točnu raspodjelu odredišta po korisniku, identificirati će korisnika u prihvatljivom vremenu. U [26] naveden je napad statističkim razotkrivanjem, odnosno osnovno ograničenje anonimnog komunikacijskog sustava na globalnog pasivnog napadača. Pretpostavlja se da je sustav idealno neranjiv na sve osim na globalnog pasivnog vanjskog napadača. Ova analiza može se tumačiti i kao prospojna mreža mješača u kojoj su svi čvorovi, osim jednog, kompromitirani [27]. Oba rada dolaze do istog rezultata, ali je napad iz [26] učinkovitiji, jer se temelji na zakonu velikih brojeva, dok prethodni tumači problem u formi problema zadovoljenja ograničenja (engl. constraint satisfaction problem). Kritična komponenta anonimnosti je kašnjenje prometa kroz sustav – količina prometa potrebnog za deanonimiziranje pošiljatelja raste eksponencijalno s povećanjem vrijednosti praga mješača. Čim se dulje promet zadržava u sustavu, tim je teže zadovoljavajuće korelirati ulaze s izlazima sustava. Povećanje broja primatelja, odnosno kardinalnog broja skupa anonimnosti primatelja za zadanog pošiljatelja također uzrokuje eksponencijalni rast količine potrebnog prometa. S druge strane, količina potrebnog prometa logaritamski opada s povećanjem ukupnog broja korisnika sustava, odnosno s povećanjem kardinalnog broja skupa anonimnosti pošiljatelja i primatelja. Čim je više korisnika na sustavu tim je vjerojatnije da su skupovi anonimnosti primatelja za pojedine pošiljatelje disjunktni. Za mreže s visokim kašnjenjem moguće je povećati kašnjenje povećanjem vrijednosti praga mješača, međutim to znači da mreže s niskim kašnjenjem ostaju ranjive na napad s-kraja-na-kraj tj. analizu prometa i to je osnovno ograničenje mreža s niskim kašnjenjem na Internetu. Može se zaključiti kako anonimnost sustava eksplicitno ovisi o kašnjenju prometa kroz sustav, količini i konfiguraciji aktivnih veza u sustavu te modelu napadača. Količina veza ovisi o broju korisnika sustava, koji implicitno ovisi o društvenoj reputaciji sustava. 2.3. Povijest anonimnih mreža 2.3.1. Mreže s visokim kašnjenjem Prvu anonimnu mrežu MIX-Net dizajnirao je 1981. god. David Chaum. Bila je predviđena za anonimno slanje elektroničke pošte. Poruka se prije slanja kriptira u slojevima koristeći asimetričnu kriptografiju. Poruka prolazi kroz prospojnu mrežu mješača s pragom. Dodatno, svaki mješač na putu dekriptira vanjski sloj, zadržava poruke određeno vrijeme te im mijenja redoslijed [29]. Prvi anonimni pošiljatelj pošte anon.penet.fi postavio je u radno stanje Finac Johan "Julf" Helsingius 1993. godine. Radilo se o jednom poslužitelju koji se od običnog poslužitelja elektronske pošte razlikovao samo po tome što je vezao stvarne adrese elektronske pošte na pseudonime (engl. nym server). Pri slanju pošte, korisnikova poruka bi na odredište stigla s izvorišnom pseudonimnom adresom, a eventualni primljeni odgovor - poslan na pseudonimnu adresu - bi poslužitelj pomoću spomenute tablice prosljedio stvarnom primatelju. To je tip 0 (engl. type 0) anonimnih pošiljaoca elektroničke pošte. Obzirom da između pošiljatelja i primatelja postoji samo jedan posrednik, ovakav je dizajn vrlo nesiguran. Ovaj pošiljatelj značajan je jer je ukazao na pravni model prijetnje te je ujedno pokazao koliko je društvena reputacija sustava bitan parametar anonimnosti. Prvi medijski napad bile su nepotvđene 9 2. Anonimnost na Internetu šture informacije o kompromitaciji poslužitelja na DEFCON konferencijama u ljeto 1994. godine. Prvi pravni napad izvršila je Scijentološka crkva u veljači 1995. godine tvrdeći da je ukradena datoteka s njihovog poslužitelja poslana upravo preko sustava u krađi podataka. Kontaktirali su Interpol, koji je kontaktirao finsku policiju, a Helsingius je uspio postići kompromis tako da oda samo traženog korisnika. Taj korisnik bio je sistem-administrator Scijentološke crkve i njegova je sudbina nepoznata nakon što je kompromitiran. Drugi medijski napad izvršio je Observer objavivši članak koji je zbog što veće čitanosti lažno tvrdio kako 75% do 90% svjetskog prometa dječjom pornografijom prolazi kroz sustav, iako su ostvarene protumjere poput ograničavanja veličine poruke na 16 KB. Finska policija nije pronašla nikakve dokaze da je i jedna takva slika prošla kroz sustav. Scijentološka crkva ugasila je sustav drugim pravnim napadom u kolovozu 1996. godine, tvrdeći da je poslana datoteka kroz sustav čime su narušena njihova autorska prava. Ironija je u tome što je naknadna istraga pokazala da je korisnik koji je zlouporabio sustav koristio drugi anonimni pošiljaoc pošte tipa 0 alpha.c2.org , koji nije mapirao prave i pseudonimne adrese te stoga krivac nikad nije pronađen. Taj poslužitelj ugašen je 27. svibnja 1996. godine zbog "masovne zlouporabe" [34]. Presuda da administrator mora odati dnevnike poslužitelja bila je protivna finskom ustavu, ali svejedno je izvršena i anon.penet.fi morao je stati s radom, obzirom da više nije mogao jamčiti anonimnost korisnicima [38]. Cypherpunk je ostvaren 2000. godine i koristi slojevitu asimetričnu PGP enkripciju, ali ne miješa poruke iako ih šalje kroz slijed čvorova. Unatoč tome može osiguravati dobru anonimnost u smislu nepovezivosti obzirom da ne koristi pseudonime – nema mogućnosti odgovora na poslanu poruku. Ipak, ako su poruke premalene globalni napadač može kompromitrati sustav analizom prometa. To je anonimni pošiljatelj pošte tipa I (engl. type I). Mixmaster je ostvaren 2001. godine. Prednost u odnosu na tip I jest što koristi ispunu poruka i miješanje poruka u čvorovima na putu kako bi otežao napad analizom prometa. Svaka poruka ima vlastiti identifikator i vremenski pečat kako bi se onemogućio napad ponavljanjem. Također ne postoji mogućnost odgovora na poruku. Osim nepovezivosti, jamči i anonimnost pošiljatelja. To je anonimni pošiljaoc pošte tipa II (engl. type II). Mixminion je najmoderni anonimni pošiljaoc pošte, pošiljaoc tipa III (engl. type III). Ostvaren je 2003. godine. Omogućava odgovor na poruku te koristi lažni promet kako bi se onemogućila analiza prometa. Poruke se razdvajaju u pakete koji se ispunjuju do fiksne veličine te kriptiraju javnim ključem svakog poslužitelja na putu. Svaki od njih dekriptira pakete, mijenja im redoslijed te ih prosljeđuje sljedećem čvoru na putu. U samoj poruci šalje se informacija o pošiljatelju koju tek primatelj poruke može ispravno protumačiti. Koristi unaprijednu anonimnost (svaki čvor na putu zna samo svog prethodnika i sljedbenika) i slobodni odabir puta. Također koristi TLS protokol. Po svemu navedenom sličan je drugoj generaciji slojevitog usmjeravanja. Onemogućuje napad ponavljanjem kao što je navedeno za tip II, a obzirom da posrednici na putu ne mogu razlikovati poslane poruke od odgovora, skup anonimnosti pošiljatelja i primatelja u ovom je slučaju njihova unija, što jamči maksimalnu moguću anonimnost u smislu skupa anonimnosti. Osim toga, jamči nepovezivost te anonimnost pošiljatelja i primatelja. 2.3.2. Mreže s niskim kašnjenjem Najjednostavniji predstavnik mreža s niskim kašnjenjem je Anonymizer. Ostvaren je 1997. godine, a više nije u upotrebi. Sav promet ide kroz jedan poslužitelj koji je komponenta od povjerenja. U osnovi, to je netransparentni HTTP posrednik koji uklanja sve identifikacijske podatke iz HTTP zaglavlja, kao i adrese pošiljatelja. Prednosti ovog sustava su što ima izuzetno nisko kašnjenje te je 10 2. Anonimnost na Internetu jednostavan za korištenje. Anonimizira HTTP za pošiljatelja. Postoji samo jedan čvor na putu, ne koristi enkripciju, a i dnevnici se čuvaju pa je anonimnost gotovo zanemariva. Osim toga, ranjiv je na (D)DoS napad te potpuno neotporan na analizu prometa. Onion Routing, odnosno slojevito usmjeravanje prve generacije ostvareno je 1998. godine. Namijenjeno je anonimnom surfanju, interaktivnoj tekstualnoj komunikaciji (IRC) kao i korištenju SSH ljuske. Koristi TCP odnosno TLS protokol, komutaciju kanala i asimetričnu slojevitu enkripciju kako bi osiguralo anonimnost. Koristi i lažni promet kako bi otežalo napad analizom prometa. Anonimni pošiljaoc pošte tipa I u biti je prospojna mreža čvorova s predefiniranim odabirom puta fiksiranim na duljinu od pet čvorova. Pozitivna strana ovog pristupa je što spajanjem nezavisnih aplikacijskih tokova u jedan kriptirani tok uvelike otežava napad analizom prometa, ali je s druge strane ranjiv na napadača koji istovremeno motri dijelove mreže. Jamči anonimnost pošiljatelja i nepovezivost. Dizajn Crowds mreže objavljen je 1998. godine, namijenjen je surfanju i nadogradnja je Anonymizer protokola. Pretpostavlja se da napadač ne može nikako promatrati promet pošiljatelja te stoga ne koristi nikakvu enkripciju, već samo HTTP. Korisnikov promet prolazi kroz slijed nasumce odabranih čvorova (engl. jondo). Dozvoljavaju se ciklusi na putu. Svaki čvor na putu nasumce odabire nasumični broj sljedećih čvorova koji će tvoriti put. Time se jamči se anonimnost pošiljatelja, a dok god pošiljatelj ne pošalje identifikacijske podatke jamči se nepovezivost. Slabost ovog pristupa jest što zadnji čvor na putu zna tko je primatelj pa nema anonimnosti primatelja. Freedom Network sličan je slojevitom usmjervanju, ali koristi mrežni sloj. Ostvarena je 2000. godine, a namijenjena je surfanju, korištenju Telneta, SSH i slanju pošte. Također koristi slobodni odabir puta na način da se odabire kaskada nasumične duljine. Učinkovita je i relativno sigurna od (D)DoS napada. Slabost joj je ovisnost o aplikacijama i ranjivost na analizu prometa. Osigurava anonimnost pošiljatelja. Hordes je nadogradnja Crowdsa i ostvarena je 2002. godine. Čvorovi su UDP posrednici, a koristi se difuzija u grupi čime je postignuta anonimnost pošiljatelja. Dozvoljava cikluse i, kao kod Crowdsa, anonimnost primatelja ne postoji, ali zbog korištenja difuzije u grupi jamči se i nepovezivost. Dizajn za P5 je objavljen 2002. godine. Korisnici su organizirani u grupe i pomoću difuzije šalju poruke po hijerarhijskoj stablastoj strukturi, što jamči anonimnost primatelja, Kako bi se osigurala anonimnost primatelja i nepovezivost čvorovi konstantno šalju uniformno raspodijeljen šum. Iako je skalabilan ima najveći višak zaštitnih bitova u odnosu na korisnu bitove od svih anonimnih mreža. Tarzan je partnerska prekrivajuća mreža koja liježe na mrežni sloj, a dizajn je objavljen 2002. godine te također koristi slojevitu enkripciju i slobodan odabir (duljine) puta. Koristi i lažni promet, a jamči anonimnost pošiljatelja, anonimnost primatelja i nepovezivost. Ponovno uspostavljanje veze je skupo. Dizajn za Herbivore objavljen je 2003. godine. Koristi se za surfanje i razne druge aplikacije. Rješava problem DC mreža na način da umjesto difuzije korisi zvjezdastu topologiju, a prijeko potrebno uspotavljanje zatvorenog skupa anonimnosti (razmjene zajedničke tajne informacije) prije slanja poruka dijeli u tri koraka. Time postiže dobru anonimnost, ali je nedostatak što abnormalni odlazak čvora s mreže jako narušava anonimnost. Java Anon Proxy ili WebMIX dizajniran je prvenstveno za anonimno surfanje i ostvaren je 2004. godine. Osnovna ideja je da se korisniku daje izbor preko koje predefinirane kaskade želi prosljeđivati promet. Svi korisnici dijele istu adresu (ulaze preko istog čvora) stoga se jamči 11 2. Anonimnost na Internetu anonimnost pošiljatelja i nepovezivost. Koristi enkripciju i lažni promet te tako, uz navedeno, otežava analizu prometa. The onion routing ili slojevito usmjeravanje druge generacije ostvareno je 2004. godine. Tor ne koristi lažni promet i stoga je izuzetno ranjiv na analizu prometa globanog napadača. Trenutno je najveća anonimna mreža u radnom stanju od gotovo dvije tisuće čvorova. Obzirom da koristi slobodni odabir puta, može jamčiti anonimnost pošiljatelja, anonimnost primatelja te nepovezivost. Dizajn za WonGoo je objavljen 2004. godine, a nadogradnja je Crowds-a te je skalabilan i otporan na prisluškivanje i analizu prometa. Koristi slojevitu enkripciju i nasumično usmjeravanje što jamči anonimnost pošiljatelja. Dizajn za Cashmere objavljen je 2005. godine i preusmjerava promet kroz kaskade grupa čvorova. Čvor koji primi poruku difuzijom u proizvoljnoj grupi šalje sljedećoj grupi poruku i difuzijom šalje svima u svojoj grupi istu poruku. Jamči anonimnost pošiljatelja kao i nepovezivost a može se nadograditi da jamči i anonimnost primatelja. Upravljanje ključevima nije zadovoljavajuće riješeno. Dizajn za MAM je objavljen 2006. godine. To je samoorganizirajući raspodjeljeni protokol koji koristi jednoodredišno slanje i difuziju u grupi a namijen je video konferencijama, učenju na daljinu i nadogradnjama softvera. Dizajniran je da jamči anonimnost primatelja i pošiljatelja te nepovezivost i neprimjetljivost. Najbolje radi na manjim mrežama. I2P je u potpunosti raspodijeljena anonimna mreža temeljena na porukama, iako pruža osnovnu mogućnost kontrole toka prometa. Ostvarena je 2009. godine. Otpornija je na analizu prometa od Tor-a jer svaki čvor na putu može spojiti više poruka (režnjeva) namijenjenih različitim odredištima, i poslati je dijelom puta kao jednu. Za razliku od Tor mreže koristi UDP, s time da je ostvarena rudimentarna kontrola toka. Phantom je mreža koja još nije postavljena ni ostvarena, međutim vrlo je interesantna jer pokreće pitanje standarda za anonimne sustave. Treba biti potpuno decentralizirana, maksimalno otporna na (D)DoS napad te potpuno izolirana od Interneta. Predviđena je i teoretski sigurna anonimnost, kao i teoretski sigurna enkripcija s-kraja-na-kraj te zaštita od identificiranja protokola. 12 3. Protokol Tor U ovom poglavlju dan je detaljan opis protokola. U samom uvodu ugrubo je opisan rad protokola, a potom se po poglavljima detaljno opisuju komponente sustava. Na slici 3.1 prikazana je Tor mreža. Kako bi mogao koristiti mrežu, korisnik (izvorište) mora na svom računalu instalirati Tor posrednik (engl. onion proxy). Tor posrednik je aplikacija koja se izvršava kao korisnički proces bez posebnih prava. Prije no što može početi koristiti mrežu posrednik mora znati kako doći do Tor usmjernika, stoga se povezuje na poslužitelj registar (engl. directory server) koji posjeduje popis svih usmjernika (engl. onion router), tj. čvorova mreže (1). Popis čvorova mreže naziva se konsenzus stanja mreže (engl. network status consensus) te osim identifikatora usmjernika sadrži i sažetke opisnika usmjernika. Slika 3.1: Načelo rada Tor mreže. Nakon što je dohvatio konsenzus stanja mreže, posrednik nasumce odabire jedan čvor iz konsenzusa i otvara Tor vezu prema njemu (2). Potom prvom usmjerniku naređuje da otvori Tor vezu prema sljedećem usmjerniku (3). Na jednak način drugi usmjernik otvara Tor vezu prema posljednjem usmjerniku (4). Svaki usmjernik na putu zna samo za svog prethodnika i sljedbenika, a nijedan čvor osim posrednika ne poznaje sve čvorove na putu. Također, posrednik ugovara poseban ključ veze sa svakim čvorom na putu i time osigurava da nijedan čvor, izuzev onog kojem je poruka namijenjena ne može prisluškivati promet. Sve TCP veze između posrednika su zaštićene TLS protokolom. Virtualni kanal (engl. virtual circuit) je skup svih čvorova i veza počevši od posrednika do posljednjeg čvora na putu. Tor veza je virtualni kanal jedinične duljine. Kada je kanal kroz Tor mrežu uspostavljen (4), posrednik može tražiti od posljednjeg čvora na putu da se spoji na odredište (5). Ako je posljednji čvor konfiguriran tako da dozvoljava povezivanje na vanjsko odredište sa zadanom IP adresom, onda vrši spajanje. Raspon IP adresa dozvoljenih za spajanje naziva se izlazna politika, a takvi čvorovi nazivaju se izlaznim čvorovima/usmjernicima. Ukoliko spajanje nije dozvoljeno, zahtjev se odbija i posrednik mora narediti srednjem usmjerniku da zatvori vezu prema ovom i otvori vezu prema drugom izlaznom usmjerniku. Ove operacije zovu se rezanje i širenje virtualnih kanala. Tor koristi komutaciju virtualnih kanala kao jedan od kritičnih mehanizama za postizanje anonimnosti. Tor podržava isključivo povezivanje preko TCP-a. Mogu ga koristi sve aplikacije koje koriste sučelje za Socks protokol, dakle mora postojati lokalno instaliran Web posrednik aktivan na nekim pristupnim vratima. Ako korisnička aplikacija ne koristi ovo sučelje, nego primjerice sama vrši DNS razrješavanje time odaje IP adresu računala domaćina. Ovo se naziva DNS curenje. Ako korisnička aplikacija uvijek koristi Web posrednik u radu, tada Tor anonimizira TCP tunele klijentskih aplikacija, ali ne djeluje iznad sjedničkog sloja OSI modela. Efektivno, ukoliko 13 3. Protokol Tor tunelirajući promet kroz virtualni kanal sadrži IP adresu i ona stigne na odredište, izvorište je kompromitirano. Pomoću raznih (vrlo često korištenih!) mrežnih tehnogija može se doći do IP adrese klijenta: JavaScript, Java appleti, Flash i Adobe dodaci za preglednik samo su neki. Kolačići (engl. cookie) su također ozbiljan sigurnosni rizik. Ovaj problem može se riješiti na nekoliko načina. Osim standardnog preglednika, preporuča se instalacija još jednog preglednika za anonimni promet. "Službeni" preglednik je Firefox s Torbutton dodatkom kojim je moguće isključiti sve poznate opcije koje mogu odati IP adresu. Također, postoji još niz drugih preglednika prilagođenih anonimnom prometu Tor mrežom. Postoji i varijanta gdje se preglednik može postaviti na USB medij, koristiti bez instalacije te se svi generirani (privremeni) podaci zapisuju na USB medij. Nadalje postoje i anonimizirane LiveCD distribucije Linux operacijskih sustava (Amnesia, Incognito, Tork, JanusVM) u kojima su svi servisi pročišćeni na način da ne odaju osjetljive informacije. Moguće je i posrednik i preglednik pokretati iz virtualnog računala. Odabir metode ovisi o razini zahtijevane anonimnosti, a najsigurnija (i najskuplja) varijanta svakako je učitavanje anonimiziranog operacijskog sustava u stvarno ili virtualno računalo. Vrlo nedavno izdan je i Silvertunnel preglednik pisan u Java programskom jeziku. Enkapsulira posrednika bez funkcije usmjernika te ne zahtijeva instalaciju Tor posrednika na računalo domaćina. Postoji međutim jedan nedostatak: potrebno je instalirati JRE na računalo domaćina, ali zbog rasprostranjenosti Java virtualnog stroja to ne bi trebalo predstavljati problem. Ukoliko je JRE instaliran, Silvertunnel pokreće se jednim klikom pomoću JNLP tehnologije. Po pokretanju, odmah se povezuje na Tor mrežu. Kroz prizmu korisničkog doživljaja, nesumnjivo je riječ o najuporabljivijem klijentu za Tor mrežu. U Tor protokolu postoje dvije vrste čvorova: • • onion proxy – klijent, Tor posrednik onion router – Tor usmjernik, čvor Svaki usmjernik može obavljati jednu ili više od sljedećih osam fukcija: • • • • • • • • directory authority – usmjernik koji je ujedno i poslužitelj registar, odnosno poslužuje konsenzuse stanja mreže directory cache – predposlužitelj registara mreže, usmjernik koji ujedno rasterećuje poslužitelje registara preuzimajući u potpunosti distribuciju opisnika usmjernika bridge router – usmjernik koji služi isključivo prijenosu Tor prometa te se ne nalazi u konsenzsusu stanja mreže, već u posebnim listama koje se održavaju i preuzimaju ručno. Postoje kako bi se Tor mreži moglo pristupati ukoliko korisnikov ISP blokira Tor promet exit router – usmjernik koji dopušta spajanje na mrežna odredišta izvan Tor mreže hidden service – posrednik ili usmjernik koji je ujedno i poslužitelj skrivene usluge hidden service directory – usmjernik koji je ujedno i poslužitelj registra skrivenih usluga introduction point - usmjernik koji ujedno služi kao čvor uvoda skrivene usluge, odnosno posrednik u procesu povezivanju rendezvous point – usmjernik preko kojeg komuniciraju skrivena usluga i klijent Kako bi posrednik mogao konstruirati put za virtualni kanal mora znati kakva je izlazna politika posljednjeg čvora na putu te mora također znati verziju protokola svakog usmjernika na putu. Ovi podaci navedeni su u opisniku usmjernika. Usmjernici prijavljuju značajniju promjenu stanja svim poslužiteljima registara mreže za koje znaju slanjem opisnika potpisanog svojim tajnim ključem. Poslužitelji registara stanja mreže smatraju se komponentama od povjerenja i stvaraju konsenzus stanja mreže glasanjem. Konsenzusi stanja mreže uvijek se preuzimaju od poslužitelja registara, dok 14 3. Protokol Tor se opisnici usmjernika uvijek preuzimaju od predposlužitelja registara (engl. directory cache), koji ih prethodno preuzimaju od poslužitelja registara. Opisnici usmjernika indeksirani su na predposlužiteljima registarima njihovim sažetkom te ih posrednici i usmjernici preuzimaju putem sažetka. Time je onemogućen napad predposlužitelja na način da se distribucijom lažnih opisnika odvoji usmjernik ili posrednik od ostatka mreže, budući da se integritet opisnika jednostavno provjerava usporedbom poslanog sažetka i izračunatog sažetka upravo preuzetog opisnika. Osim anonimnog spajanja na mrežna odredišta, moguće je postaviti anonimnu mrežnu uslugu preko Tor mreže što znači da je moguće pristupati sadržaju bez poznavanja IP adrese same usluge. Ovaj koncept poznat je kao skrivene usluge (engl. location hidden services) i opisan je u poglavlju 3.5. Integritet i autentičnost informacijskog toka kroz Tor mrežu osigurani su, osim činjenicom da koristi TLS protokol i upotrebom vlastite simetrične i asimetrične kriptografije, Diffie-Hellmanovg protokola te funkcije sažetka: • • • • simetrična kriptografija - 128-bitni AES algoritam u brojačkom načinu (engl. counter mode) asimetrična kriptografija – 1024-bitni RSA algoritam s fiksnim javnim eksponentom za koji je odabran treći Fermatov prost broj F4 = 65537 protokol Diffie-Hellman – koristi se generator 2 i modulo koji je siguran prost broj iz druge Oakleyeve grupe funkcija sažetka – SHA-1 algoritam Čvorovi koriste sljedeće ključeve za enkripciju veze: • • Asimetrični ključ veze usmjernika – služi za (de)kriptiranje TLS kanala. Trajanje: reda veličine dana. (PKTLS , SKTLS ) Simetrični ključ za enkripciju prometa AES algoritmom na virtualnom kanalu dogovoren protokolom Diffie-Hellman (KOP-OR) Također koriste asimetrične ključeve za autentifikaciju veze: • Lukov ključ usmjernika – služi za (de)kriptiranje zahtjeva za otvaranjem virtualnih kanala . Trajanje: reda veličine tjedan dana. (PKON , SKON ) Kako bi se osigurao integritet konsenzusa i opisnika, koriste se sljedeći asimetrični ključevi: • • • Ključ identiteta poslužitelja registara – služi za potpisivanje certifikata koji jamči vjerodostojnost ključa za potpisivanje konsenzusa stanja mreže. Trajanje: od tri do dvanaest mjeseci. (PKDA , SKDA ) Ključ za potpisivanje glasova (trenutnih registara stanja pojedinog poslužitelja) i konsenzusa stanja mreže– Trajanje: nije specificirano,vjerojatno do mjesec dana. (PKsgnDA , SKsgnDA ) Ključ identiteta usmjernika – služi za potpisivanje TLS certifikata i opisnika usmjernika. Trajanje: do mjesec dana. (PKID , SKID ) Radi preglednosti nisu navedeni ključevi za skrivene usluge. Predposlužitelji i poslužitelji registara mreže sudjeluju u radu mreže i kao obični usmjernici te tada koriste obične ključeve, a kada obavljaju funkciju poslužitelja registara mreže koriste se ključevima poslužitelja registara. U svrhu povećanja ukupne anonimnosti sustava svaki posrednik može istovremeno obavljati i funkciju usmjernika. Obrat vrijedi, ali tada se povećava anonimnost čvora u funkciji posrednika, jer se virtualni kanali posrednika skrivaju među ostalim virtualnim kanalima koji prolaze kroz taj čvor u funkciji usmjernika. 15 3. Protokol Tor 3.1. Virtualni kanali i kriptiranje ukupnog informacijskog toka U ovom potpoglavlju detaljno je razmotreno stvaranje virtualnog kanala, prvo s proceduralnog aspekta a potom sa sigurnosnog. Pretpostavlja se scenarij da se preko Tor-a želi učitati neku Web stranicu. Na slici 3.2 prikazan je dijagram slijeda za otvaranje virtualnog kanala od tri usmjernika. Definira se višestruko kriptiranje AES M , Kc ; a=AES AES AES M , Kc , Kb , Ka . Nakon što je odabrao put, posrednik otvara TLS vezu prema prvom usmjerniku koji se naziva čvor stražar (EG). Pri uspostavi TLS veze moguće su tri metode razmjene TLS certifikata. Ovisno o tome koja je metoda ugovorena poznato je koja je verzija spojnog protokola. U svakom slučaju, obje strane u konačnici razmjene lanac od dva certifikata: prvi je certifikat s ključem veze usmjernika, dok je posljednji samopotpisan ključem identiteta usmjernika. O verziji spojnog protokola ovisi prvi par protokolnih podatkovnih jedinica koje se moraju razmijeniti na virtualnom kanalu a to su VERSIONS ili NETINFO ćelije. Nakon te razmjene usmjernici mogu početi s izgradnjom virtualnog kanala. Virtualne kanale moguće je multipleksirati po TLS vezama. Posrednik nasumce odabire identifikator virtualnog kanala (na slici 3.2 "a") te šalje CREATE(_FAST) ćeliju čvoru stražaru, koja je u biti naredba za otvaranje novog Slika 3.2: Slijedni dijagram otvaranja virtualnog kanala pomoću CREATE_FAST ćelije. virtualnog kanala. Čvor stražar zauzima potrebne resurse i odgovara CREATED(_FAST) ćelijom. Po primitku CREATED(_FAST) ćelije otvoren je virtualni kanal te posrednik šalje RELAY_EXTEND ćeliju s identifikatorom sljedećeg usmjernika – prijenosnog čvora- niz kanal prema čvoru stražaru. Po primitku RELAY_EXTEND ćelije čvor stražar ju dekriptira i otvara TLS vezu te odabire novi identifikator virtualnog kanala (na slici 3.2 "b") i šalje CREATE ćeliju prema prijenosnom čvoru. Po primitku CREATED ćelije od prijenosnog čvora, čvor stražar kriptira i šalje RELAY_EXTENDED ćeliju uz kanal prema posredniku s identifikatorom virtualnog kanala "a". Sada je virtualni kanal proširen i posrednik šalje dvostruko kriptiranu RELAY_EXTEND ćeliju s identifikatorom izlaznog čvora niz kanal. Čvor stražar prima ćeliju na virtualnom kanalu "a", dekriptira ju i prosljeđuje na virtualnom kanalu "b" prijenosnom čvoru koji na već opisan način otvara virtualni kanal s identifikatorom "c" prema izlaznom čvoru. 16 3. Protokol Tor Po primitku CREATED ćelije prijenosni čvor kriptira i šalje RELAY_EXTENDED ćeliju uz kanal prema čvoru stražaru. Čvor stražar ju kriptira i prosljeđuje uz kanal posredniku. Posrednik je sada uspješno otvorio virtualni kanal. Ako je TLS veza prema prvom čvoru stražaru već otvorena, posrednik, obzirom da su identiteti obiju strana poznati, može poslati CREATE_FAST ćeliju, koja ne koristi vremenski skupu operaciju RSA enkripcije, već odmah šalje svoj dio ključa. Starije verzije protokola ne podržavaju ovu mogućnost. Na slici 3.2 prikazana je varijanta s CREATE_FAST ćelijom. Ukoliko usmjernik primi CREATE_FAST ćeliju, zna da je prvi čvor u virtualnom kanalu (kanali se mogu širiti isključivo pomoću CREATE ćelije) i trebao bi odbiti zahtjeve za povezivanjem na vanjska mrežna odredišta. Povezivanje s vanjskim odredištem i prijenos podataka obavlja izlazni usmjernik prema uputama posrednika. Bitno je napomenuti da put od izlaznog usmjernika do vanjskog odredišta ne koristi TLS protokol, već TCP, što znači kako je taj dio puta potpuno nezaštićen. Stoga se, ako je moguće, za tunelirajući protokol uvijek preporuča korištenje nekog protokola s enkripcijom kanala i autentifikacijom veze. Na slici 3.4 prikazan je dijagram slijeda za dohvaćanje mrežne stranice kroz virtualni kanal. Nakon uspostave virtualnog kanala posrednik šalje RELAY_BEGIN ćeliju u kojoj je URL vanjskog odredišta prema izlaznom usmjerniku. Ako mu politika doušta, izlazni usmjernik vrši spajanje na zadano odredište te ako je uspio odgovara s RELAY_CONNECTED ćelijom. Time je otvoren virtualni tok (engl. virtual stream) koji predstavlja jednu anonimiziranu korisničku TCP vezu. Po jednom virtualnom kanalu može se multipleksirati više virtualnih tokova. Ukoliko mu izlazna politika ne dopušta spajanje ili ono nije uspjelo, šalje RELAY_END ćeliju uz kanal s postavljenim razlogom neuspjeha. Prijenos podataka vrši se RELAY_DATA ćelijama, koje se na putu od izvorišta do odredišta sustavno dekriptiraju, dok se u suprotnom smjeru sustavno kriptiraju; tj. svaki usmjernik na putu dodaje ili skida svoj sloj zaštite, što je zorna analogija sa slojevitom strukturom glavice luka. Slika 3.3: Slijedni dijagram dohvaćanja mrežne stranice kroz otvoreni virtualni kanal u normalnim uvjetima. Jednom kada je virtualni kanal stvoren, posrednik može uništiti dio kanala i izgraditi ga preko nekih drugih usmjernika. Posrednik odabire usmjernik koji će odrezati kanal i šalje mu RELAY_TRUNCATE ćeliju s postavljenim razlogom REASON_REQUESTED. 17 3. Protokol Tor Slika 3.4: Slijedni dijagram mijenjanja topologije kanala od strane posrednika. Odabrani usmjernik sljedećem usmjerniku u kanalu prosljeđuje ćeliju DESTROY s postavljenim razlogom zatvaranja. Sljedeći usmjernik ponavlja postupak dok se virtualni kanal ne zatvori do posljednjeg čvora. Usmjernik koji primi DESTROY ćeliju oslobađa sve resurse za virtualni kanal na koji je ćelija adresirana. Neovisno o posredniku, između dva susjedna usmjernika u virtualnom kanalu je moguća situacija u kojoj je potrebno prekinuti TLS vezu, ili je veza slučajno prekinuta. U tom slučaju, usmjernik bliži posredniku šalje RELAY_TRUNCATE ćeliju s postavljenim odgovarajućim razlogom, a usmjernik s druge strane oslobađa resurse vezane za taj kanal i prosljeđuje DESTROY ćeliju s odgovarajućim postavljenim razlogom niz kanal. Ova metoda poznata je kao topologija probušene cijevi (engl. leaky pipe topology). Pregled protokolnih podatkovnih jedinica dan je u dodatku B. Pri otvaranju TLS veze partneri razmijene ključeve identiteta. Sažetak dobivenog ključa identiteta i stvarna IP adresa partnera provjeravaju se prema konsenzsu stanja mreže. Ukoliko ne odgovaraju veza se prekida. Razmjena CREATE ćelija u biti je Diffie-Hellmanovo rukovanje za dogovaranje simetričnog ključa za kriptiranje prometa na virtualnom kanalu. Prva polovica ključa kriptira se javnim lukovim ključem partnera i enkapsulira u CREATE ćeliju. Partner na to odgovora s drugom polovicom ključa i sažetkom ugovorenog ključa enkapsuliranim u CREATED ćeliju. Začetnik veze uspoređuje sažetak izračunatog ključa s primljenim sažetkom - ako nisu identični kanal se prekida. Na taj način osigurana je tajnost veze među partnerskim čvorovima. Ako čvorovi i nisu susjedni čovjek-u-sredini ne može kompromitirati kanal. Na slici 3.5 prikazan je virtualni kanal. Kada čvor Slika 3.5: Shema virtualnog kanala, jednosmjerna autentifikacija entiteta i ključeva, slojevito usmjeravanje druge generacije u Tor-u. stražar primi RELAY_EXTEND ćeliju može krivotvoriti CREATE ćeliju kojom će otvoriti virtualni kanal prema prijenosnom čvoru, međutim ne može saznati prvu polovicu ključa i zato će pasti na provjeri sažetaka na strani posrednika. Bitno je primijetiti kako je u ovakvoj komunikaciji ostvarena jednosmjerna autentifikacija entiteta - posrednik zna za svaki usmjernik na svom putu i ne 18 3. Protokol Tor koristi privatni ključ temeljem kojeg bi ga se moglo identificirati, dok usmjerniku nije bitno tko otvara virtualni kanal niti zna išta o putu izuzev neposrednog sljedbenika i prethodnika pa čak ni da li je njegov neposredni prethodnik posrednik ili usmjernik, osim u slučaju da je virtualni kanal s prethodnikom stvoren pomoću CREATE_FAST protokolne podatkovne jedinice. Vanjsko odredište vidi samo izlazni čvor. Raspodjela znanja o putu prikazana je u gornjem dijelu slike 3.5. Također, ostvarena je jednosmjerna autentifikacija ključeva – ključ za komunikaciju između posrednika i nekog usmjernika znaju samo posrednik i taj usmjernik. Posrednik jedini vidi čitav promet, dok svaki drugi čvor na putu vidi samo promet namijenjen njemu. Ako tunelirajući protokol nema enkripciju, tada izlazni čvor može vidjeti i promet namijenjen odredištu. Na taj način osigurana je anonimnost pošiljatelja, a obzirom da anonimnost primatelja nije bitna i uzajamna anonimnost. Zbog niskog kašnjenja nepovezivost nije ispunjena za globalnog vanjskog napadača, a samim time ni lokacijska anonimnost. Analiza anonimnosti virtualnog kanala pod modelom napadača koji kompromitira jedan ili dva čvora, dana je u dodatku D. Slika 3.6: Dijagram stanja virtualnog kanala. Virtualni kanali moraju se rotirati tokom vremena. Ako korisnik stalno upotrebljava isti kanal, puno ga je lakše identificirati analizom prometa, stoga je vrijeme života kanala osjetljiv parametar sustava. Na slici 3.6 prikazan je dijagram stanja virtualnog kanala. Dok se kanal se gradi ne može biti upotrijebljen za korisnički promet. Kada je kanal izgrađen, ali nije iskorišten za promet, čist je. Čim se iskoristi za korisnički promet postaje prljav. Prije isteka vremena života postaje star - u specifikacijama nije navedeno, ali bilo bi logično da se u tom trenutku počinje s izgradnjom novog kanala. Nakon što mu istekne vrijeme života korisnički tokovi prebacuju se na drugi kanal, a ovaj se zatvara. Provjera integriteta podataka vrši se samo na krajevima toka zato jer bilo koji čvor na putu može postati krajnji čvor. Kada posrednik, šireći virtualni kanal dogovara novi ključ s odabranim usmjernikom, oba izračunavaju SHA-1 sažetak izvedenice ugovorenog ključa. Tom sažetku dodaju se sažeci sadržaja svih RELAY ćelija koje stvore oba čvora, uključujući u svaku od njih prva četiri okteta odgovarajućeg sažetka. Također, oba čvora čuvaju posljednji sažetak, kako bi mogli provjeriti integritet podataka. Kako bi uklonio ili izmjenio samo jednu protokolnu podatkovnu jedinicu, napadač mora točno odrediti prva četiri okteta trenutnog sažetka. On ovisi o cjelokupnom prometu između krajnja dva čvora, počevši od izvedenice ugovorenog ključa koji znaju samo ta dva čvora. Napad u kojem protivnik pokušava simulirati ovaj postupak ne može biti uspješan budući da je svaka prijenosna 19 3. Protokol Tor protokolna podatkovna jedinica, u kojoj se nalazi i sažetak, iznova kriptirana sa svakom sljedećom etapom. U RELAY ćeliju se uključuju samo prva četiri okteta sažetka kako bi ostalo više mjesta za teret. Vjerojatnost da će napadač pogoditi ispravnu vrijednost dijela sažetka prihvatljivo je mala, budući da čvor, ukoliko ustanovi kako je neka prijenosna protokolna podatkovna jedinica neovlašteno mijenjana, raskida odgovarajući virtualni kanal. Vrijeme potrebno za izračunavanje sažetaka minimalno je u usporedbi s vremenom koje je utrošeno za kriptiranje AES algoritmom. 3.2. Poslužitelji registri mreže Postoji mali skup poslužitelja registara mreže koji se smatraju komponentama od potpunog povjerenja. Njihova je primarna zadaća izglasavati konsenzus stanja mreže iz vlastitih registara stanja, tj. svih pohranjenih opisnika. Svaki poslužitelj stanja izdaje i certifikate važećih ključeva. Osim toga služe kao arhiva opisnika usmjernika, kao i dokumenata s dodatnim informacijama koji sadrže topološke informacije i povijest prometa usmjernika. U dodatku A priložene su gramatike svih navedenih dokumenata. U trećoj verziji protokola za posluživanje registara stanja svaki poslužitelj održava vlastiti registar stanja te ga na početku novog intervala glasanja potpisuje i HTTP POST zahtjevom objavljuje svim ostalim poslužiteljima. Svaki poslužitelj istim algoritmom računa konsenzus svih registara stanja mreže te pretpostavljajući potpunu povezanost dolazi do istog konsenzusa, stoga se provjera vrši samo slanjem sažetaka konsenzusa svim poslužiteljima. Slika 3.7: Vremenski slijed glasanja. Konsenzus registara stanja mreže ima vrijeme nakon kojeg postaje važeći (VA), vrijeme do kojeg je "svjež" (FU) i vrijeme nakon kojeg prestaje biti važeći (VU). U svakom trenutku trebalo bi biti najmanje tri važeća konsenzusa: u trenutku VA svi poslužitelji imaju višestruko potpisani konsenzus stanja mreže, do FU vremena predposlužitelji preuzimaju konsenzuse stanja, nakon čega do VU trenutka klijenti preuzimanju konsenzuse. Poslužitelji registara stanja moraju osigurati da im satovi ne griješe više od nekoliko sekundi, stoga se preporuča korištenje NTP-a čija točnost može biti puno veća - preko Interneta ~ 10ms. 20 3. Protokol Tor Kada ključ za potpisivanje glasova i konsenzusa istekne poslužitelj mora objaviti novi certifikat potpisan svojim ključem identiteta, koji je najosjetljiviji dio cijelog sustava i čuva se tako da nije spojen na mrežu. Konsenzus stanja mreže sastoji se od dijela za vremensku kontrolu (ispis 3.1.), dijela za kontrolu integriteta i autentičnosti (ispis 3.2.) te popisa usmjernika (ispis 3.3.). Ispis 3.1: Preambula konsenzusa ili registra stanja mreže. network-status-version 3 vote-status consensus consensus-method 9 valid-after 2010-06-01 00:00:00 fresh-until 2010-06-01 01:00:00 valid-until 2010-06-01 03:00:00 voting-delay 300 300 client-versions 0.2.0.35,0.2.1.19,0.2.1.20,0.2.1.21,0.2.1.22,0.2.1.23,0.2.1.24,0.2.1.25,0.2.1.26,0.2.2.1alpha,0.2.2.2-alpha,0.2.2.3-alpha,0.2.2.4-alpha,0.2.2.5-alpha,0.2.2.6-alpha,0.2.2.7-alpha,0.2.2.8alpha,0.2.2.9-alpha,0.2.2.10-alpha,0.2.2.11-alpha,0.2.2.12-alpha,0.2.2.13-alpha server-versions 0.2.0.35,0.2.1.19,0.2.1.20,0.2.1.21,0.2.1.22,0.2.1.25,0.2.1.26,0.2.2.1alpha,0.2.2.2-alpha,0.2.2.3-alpha,0.2.2.4-alpha,0.2.2.5-alpha,0.2.2.6-alpha,0.2.2.7-alpha,0.2.2.8alpha,0.2.2.10-alpha,0.2.2.11-alpha,0.2.2.12-alpha,0.2.2.13-alpha known-flags Authority BadExit Exit Fast Guard HSDir Named Running Stable Unnamed V2Dir Valid params CircuitPriorityHalflife=30000 circwindow=1000 Nakon preambule koja osigurava kontrolu glasanja u vremenskoj domeni, slijedi identitet autora dokumenta stanja mreže te ako je riječ o konsenzusu popis svih glasača odnosno sažetaka njihovih javnih ključeva kao i njihovih digitalnih potpisa konsenzusa. Potom slijedi popis svih prijavljenih i vrednovanih usmjernika te digitalni potpis čitavog dokumenta. Ispis 3.2: Kontrola integriteta i autentičnosti konsenzusa stanja mreže. // informacija o poslužitelju registru dir-source dannenberg 585769C78764D58426B8B52B6651A5A71137189A dannenberg.ccc.de 193.23.244.244 80 443 contact J. Random Hacker <[email protected]> vote-digest 0F71A357B29FBA842646921713F5BA93DB5FE20A // opisnici usmjernika directory-signature 14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 D2C42303C3DC3C65AEA79052779A133528016BB3 // potpis jednog glasača -----BEGIN SIGNATURE----mzgP1m7JvERZM1RB8VLBNQCljIfhi+Mo6bhpnanvCXv9o77LLyv3UgbuMXvCbRsk 8vMnAD/IlqdVJZDBXWj2p341gnGpcyAUEDrcCaLPT/3TwZOqVI4TiDyMfz7zvUo+ euJqTSxZiEmfeCBYcWiUv7+33MS0g/ZwOYQS8uHm+90= -----END SIGNATURE----- U konsenzus su uključeni sažeci opisnika svih usmjernika koji nisu sumnjivi i nisu istekli, a potvrdilo ih je više od polovice glasača. Informacija o usmjerniku u konsenzusu stanja sastoji se od nadimka (alfanumerički tip), sažetka javnog ključa identiteta usmjernika po kojem je i uzlazno sortiran cijeli popis usmjernika, sažetka najsvježijeg opisnika, vremena objave opisnika te pristupnih vratiju za tunelirajući promet i pristupnih vratiju za promet dokumentima stanja mreže. Usmjernik je u konsenzusu stanja mreže definiran svojim nadimkom (alfanumerički identifikator), sažetkom javnog ključa identiteta i opisnika, datumom objave najsvježijeg opisnika, IP adresom te pristupnim vratima za promet dokumentima stanja i Tor promet. Ispis 3.3: Informacija o usmjerniku u konsenzusu stanja mreže. r s v w p mela R3CkyWALMPMeOCu8qZDZv6Nnv84 JQaW0m8zN73/0FEiIyN36LDoJ9Y 2010-05-31 15:52:54 124.217.230.88 9001 0 Fast Guard HSDir Named Running Stable Valid Tor 0.2.2.13-alpha Bandwidth=50 accept 110,1533,1863,5050,5190,5222,6667-6669 Potom slijede značajke ("Flags") usmjernika bitne za odabir puta virtualnog kanala: • • "Authority" – usmjernik je ujedno i poslužitelj registara stanja "BadExit" – iako se oglašava usmjernik je beskoristan kao izlazni čvor, restriktivnog posrednika ili sigurnosne stijene ili iz nekog sličnog razloga 21 jer je iza 3. Protokol Tor • • • • • • • "Exit" – usmjernik je koristan kao izlazni čvor, tj. njegova izlazna politika dopušta povezivanje na mrežna odredišta izvan Tor mreže "Fast" - usmjernik je trenutno dostupan i u prvih 7/8 trenutno dostupnih usmjernika ili ima brzinu od najmanje100 KB/s. Podatak o iznosu širine pojasa ne mora biti točan obzirom da ga poslužitelji registara stanja ne provjeravaju "Guard" – usmjernik se smatra pogodnim za čvora stražara, tj. njegova propusnost veća je od 250 KB/s ili je najmanje medijan svih propusnosti i njegovo je ukupno vrijeme na mreži po danu (pomnoženo težinskom funkcijom tako da više doprinose iznosi po mlađim danima) najmanje medijan svih "poznatih" usmjernika. Usmjernik se smatra "poznatim" ukoliko je aktivan na mreži dulje od 7/8 svih aktivnih usmjernika ili njegovo ukupno vrijeme provedeno na mreži iznosi nekoliko tjedana. "HSDir" - usmjernik se smatra registrom skrivenih usluga "Stable" – usmjernik je pogodan za dugoživuće kanale, odnosno trenutno je dostupan i njegov MTBF je najmanje medijan MTBF vremena svih trenutno dostupnih usmjernika "Running" – usmjernik se smatra trenutno dostupnim, tj. poslužitelj registara stanja uspješno se spojio na ovaj usmjernik u proteklih 30 min. "Valid" – usmjernik je ispravan, tj. ne koristi pokvarene verzije Tora i nije na crnoj listi Usmjernik generira novi opisnik svaki puta kada se ispuni jedan od sljedećih uvjeta: • • • • prošao je period vremena (uobičajeno 18 h) od slanja posljednjeg opisnika promijenila se vrijednost polja u opisniku koja nije vrijednost širine pojasa ("Bandwidth") ili ukupno vrijeme na Tor mreži bez prekida ("Uptime"): podaci o identitetu, izlaznoj politici usmjernika, je li usmjernik u stanju hibernacije vrijednost širine pojasa se povećala za faktor od najmanje 2 resetiranje računala - zastavica "Uptime" postaje 0' Ispis 3.4: Opisnik usmjernika. router Unnamed 188.16.195.214 443 0 0 platform Tor 0.2.1.26 on Windows "Longhorn" Service Pack 1 [workstation] {terminal services, single user} opt protocols Link 1 2 Circuit 1 published 2010-06-07 10:51:21 opt fingerprint FFCF D08C 49D5 1BBE 9CE2 0F3F 0C36 4C42 6374 7F2B uptime 7 bandwidth 5242880 10485760 84200 opt extra-info-digest 535764479AEDA173577D958CAC94E9B7CA7B2E75 onion-key -----BEGIN RSA PUBLIC KEY----MIGJAoGBAKyu2VRHzWIfsPINkr3+EPtTrPiG57da0pRgiKO/A6zpwsuzz9ihzgNFOOEuYlAN8Xdh1gL8LseB+9nvl8gY6aVjXUe+RMV2XDBfGWjT TBKNmJCn49h7X1vd3BDyBcu9gX+L7FwSWwbPPVpsGYq22ukHQXOtlvkcFPjP/DsyEZdtAgMBAAE= -----END RSA PUBLIC KEY----signing-key -----BEGIN RSA PUBLIC KEY----MIGJAoGBANRJ9k/MG9/P0fdcWWwrIMVasovzXsgdd1LEp4blVQ9xwCis52IPpamXlzyJN6POcZe/55dnqjq1WPA3JTaYEHYcuH5DuG/2X5YZm4Dt 6ABM4use1hstguvgPChDsDmGodp80MlQbeeBJwh6iWV3ggSmxtctimaiGm0nMMMlGSOTAgMBAAE= -----END RSA PUBLIC KEY----opt hidden-service-dir reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 188.16.195.214:* reject *:25 reject *:119 reject *:135-139 reject *:445 reject *:563 reject *:1214 reject *:4661-4666 reject *:6346-6429 reject *:6699 reject *:6881-6999 accept *:* router-signature // potpis opisnika U dokumentima s dodatnim informacijama o usmjernicima zabilježena je povijest prometa, odnosno broj pročitanih i zapisanih okteta s Tor mreže. 22 3. Protokol Tor U verziji 2 registarskog protokola ovi su podaci bili u opisniku, a te vrijednosti ne koriste ni usmjernici ni posrednici za normalan rad. Stoga su premješteni u zasebne dokumente te se time uštedilo 60% vremena za promet opisnicima. Također, konsenzus stanja mreže računao je svaki klijent za sebe, što je u određenim situacijama moglo dovesti do particioniranja korisnika od ostatka mreže, odnosno smanjivala se njegova i ukupna anonimnost sustava. Ispis 3.5: Dokument s dodatnim informacijama. extra-info Unnamed 74FF3EB011DAC6B9BAC7FF888784EA7998CF89A3 published 2010-06-06 10:57:23 write-history 2010-06-06 10:57:03 (900 s) 4831232,5374976,6244352,18341888,4025344,5084160,1106944,1612800,7693312,8462336,1783808,3622912,7252992,6411264 ,3883008,3879936,645120,667648,1309696,120832,52224,88064,2861056,0,0,0,0,0,0,247808,730112,696320,384000,376832 0,2441216,0,91136,20480,44032,16384,54272,139264,966656,145408,74752,284672,146432,4401152,708608,1036288,385536 0,1825792,715776,72704,66560,5650432,18294784,13934592,19218432,3089408,8567808,6378496,3734528,7433216,116736,4 02432,7473152,9399296,9335808,4482048,1611776,2974720,4717568,13668352,12758016,7845888,2936832,2464768,3325952, 9674752,5763072,3019776,9356288,3075072,6538240,6801408,3917824,478208,947200,197632,3635200,483328,1067008,9728 00,4681728,3488768 read-history 2010-06-06 10:57:03 (900 s) 4748288,5372928,5962752,18318336,4011008,5019648,865280,1973248,7527424,8179712,1580032,3896320,7111680,6084608, 3684352,4135936,540672,756736,1250304,532480,30720,198656,2742272,0,0,0,0,0,0,307200,706560,556032,267264,404582 4,2255872,0,76800,7168,40960,4096,40960,83968,1123328,83968,514048,407552,115712,4736000,868352,976896,3710976,2 201600,646144,40960,181248,5978112,18085888,13613056,18805760,3385344,8377344,6124544,3540992,7676928,189440,351 232,7325696,9613312,9259008,4408320,1685504,3164160,4460544,13367296,12350464,8035328,2809856,2362368,3302400,98 56000,5686272,2900992,9139200,3354624,6446080,6568960,3695616,735232,859136,370688,3492864,865280,934912,797696, 4586496,3878912 router-signature -----BEGIN SIGNATURE----Kx7TmKhdKWH+NGYuGy+850AEafq1bjEyfbH2iYoHL2HBQ6EsoQ4bVXB1ZVzKoN2r sX9kkad6nFZVxMmY6IcDx/la7gxdTTaITsYLKkHHEKkAV/CdQWgA1Cy0FF1miITc VN/zUgNEKoVPn2c7qInhp7kcAQSYyKprHQsShFL8Pio= -----END SIGNATURE----- Također, nije postojao ključ poslužitelja registara stanja mreže za potpisivanje, već se potpisivanje obavljalo izravno ključem identiteta poslužitelja registara stanja mreže, što znači da je taj izuzetno osjetljiv ključ bio u memoriji u čistom, nekriptiranom obliku. U posljednjoj, opisanoj verziji čuva se lokalno i nije spojen na Tor mrežu. Nadalje, bitno je napomenuti kako poslužitelji registara stanja ne provjeravaju vrijednosti značajki usmjernika u njihovim opisnicima od kojih su najbitnije "Bandwidth" i "Uptime". O ovim zastavicama ovisi dobivanje zastavica "Stable", "Fast" i "Guard" u konsenzusu stanja mreže, što je značajan sigurnosni rizik jer upravo pomoću ovih zastavica usmjernici bivaju birani za virtualne kanale klijenata. Ako svi usmjernici koji tvore virtualni kanal imaju neko svojstvo (zastavicu), tada i virtualni kanal ima to svojstvo. 3.3. Algoritam za odabir puta Posrednik ne gradi kanale dok nema barem ¼ svih važećih opisnika. Potom nasumično odabire čvorove puta uz uvjet da odabire izlazni čvor koji može, ili se pretpostavlja da može, izvršiti spajanje na zadano odredište. Obzirom da se često dobivaju zahtjevi u obliku URL identifikatora ne može se uvijek znati IP adresa odredišta pa time ni dozvoljava li izlazni čvor spajanje na zadano odredište. Svi usmjernici na putu trebali bi biti topološki različiti i nijedan par usmjernika na putu ne bi trebao biti iz mreže s mrežnom maskom /16. Klijenti bi trebali koristiti samo usmjernike navedene u konsenzusu mreže te ne bi trebali koristiti usmjernike koji nemaju postavljene zastavice "Valid" i "Running" ili su na crnoj listi. Za virtualne kanale za koje se očekuje kako će se dugo koristiti trebali bi se koristiti usmjernici sa zastavicom "Stable". Vrijeme trajanja virtualnih kanala predviđa se pomoću liste pristupnih vrata koja se popunjava svim vratima koja je korisnika zatražio u proteklih sat vremena. Obično su to: 21-FTP upravljanje, 22-SSH, 706-SILC, 1863-MSNP, 5050-"Yahoo! messenger", 5190-"ICQ,AOL 23 3. Protokol Tor instant messenger", 5222-XMPP, 5223-SXMPP, 6667-IRC, 6697-SIRC, 8300-aplikacije za tekstualnu komunikaciju. Algoritam odabira puta bitan je za anonimnost sustava, stoga će biti pobliže razmotren. U osnovi, čvorovi se uvijek odabiru slučajno iz podskupa skupa svih usmjernika R po uniformnoj razdiobi, osim ako je riječ o čvorovima sa zastavicom "Fast". Oni se također odabiru slučajno, ali i proporcionalno oglašavanoj propusnosti prema algoritmu na slici 3.8. Promatra se skup svih usmjernika R i njihovih svojstava u kontekstu relacijske algebre, gdje su i operacije selekcije i projekcije, respektivno. skup F = STABLE , RUNNING ,VALID , EXIT R∖ BADEXIT R ; osigurač = true ; radi { ako osigurač osigurač = false ; inače F = F ∖{r }; ako FAST usmjernik r = random F , F B ADV F ; inače r = randomF , uniform ; } dok ! spajanjeDozvoljenor ; Slika 3.8: Odabir izlaznog čvora. Navedena su standardna svojstva za skup prihvatljivih usmjernika za odabir na poziciji izlaznog čvora, međutim ne moraju biti zadovoljena sva navedena ograničenja što ovisi o postavkama u konfiguracijskoj datoteci, ulaznim argumentima procesa Tor posrednika ili potrebama kanala. funkcija B ADV : BANDWIDTH.AVERAGE , BANDWIDTH.OBSERVED R ⊂ ℝ×ℝ ℝ funkcija rez :ℝ ℝ rez propusnost=min propusnost ,10 MB/ s B ADV r = min rez propusnost.prosjek , rez propusnost.primjećeno ; B ADV R:{R}ℝ B ADV R = ∑ B ADV r ; r∈ R Slika 3.9: Priprema podataka o širini pojasa iz opisnika usmjernika za odabir usmjernika za neku poziciju na putu. Ako se ne traži kanal sa svojstvom "Fast", slučajno se odabire usmjernik po uniformnoj razdiobi. Inače se odabire usmjernik po razdiobi propocionalnoj odrezanoj razdiobi minimalne oglašavane širine pojasa po usmjernicima iz F (slika 3.9). Ako izlazna politika odabranog čvora zadovoljava zahtjev, a adresa odredišta zadana je u obliku IP adrese, tada kanal podržava zahtjev ("supports"). Ako je adresa u obliku DNS adrese, a izlazna politika dopušta spajanja na pristupna vrata iz zahtjeva tada kanal možda podržava zahtjev ("might support"). U specifikacijama je navedeno da se odabire čvor čija izlazna politika "zadovoljava najviše tekućih zahtjeva klijenata" iako se ne specificira kako. Osim toga, nije navedeno ni kako se razrješavaju kanali koji možda podržavaju zahtjev. Najlogičniji nastavak algoritma jest da posljednji čvor na putu vrši DNS razrješavanje. 24 3. Protokol Tor F = STABLE , RUNNING R; osigurač = true ; E = EXIT R G = GUARD R funkcija Tbw = ∑ B ADV r Ebw = ∑ B ADV e Gbw = ∑ B ADV g r∈R e∈E g ∈G Tbw Ebw−Tbw ADV ako Ebw B ADV E := B E ; inače F = F ∖ EXIT R; 3 3Ebw Gbw−Tbw Gbw−Tbw ADV ADV ako 0 B G:= B G; inače F = F ∖ GUARD R ; 3Gbw 3Gbw radi { ako osigurač osigurač = false ; inače F = F ∖ {r }; ako FAST r = random F , F B ADV F ; inače r = randomF , uniform ; ako!topološkiRazličiti continue ; inače preostali−−; } dok preostali0; Slika 3.10: Odabir prijenosnih čvorova. Ako sustav nema dovoljno izlaznih čvorova – tada je njihova ukupna širina pojasa manja od trećine ukupne širine pojasa u sustavu- i/ili čvorova čuvara – tada svi čvorovi u sustavu moraju biti stražari – ti se čvorovi ne razmatraju za odabir na poziciji prijenosnog čvora. Inače, širina pojasa odgovarajućih čvorova ponderira se konstantnim faktorom što osigurava jednoliku raspodijeljenost širine pojasa po kanalima duljine od tri čvora. Time se podiže kvaliteta usluge kanala. Ako je korisnički postavljena upotreba čvorova stražara - u tom slučaju prijenosnih čvorova ima za dva manje od ukupne duljine puta - tada se kao prvi čvor u putu odabire čvor čuvar na jednak način kao i izlazni čvor samo što se projekcija umjesto po svojstvu "Exit" vrši po svojstvu "Guard", dok je uvjet kraja petlje topološka različitost svih čvorova na putu. (slika 3.10.) Budući da je algoritam odabira čvorova slučajan, čak i pri odabiru proporcionalnom razdiobi širine pojasa svi čvorovi bivaju birani iz istog podskupa, može se reći da je algoritam odabira puta anoniman u okviru realnih zahtjeva. Algoritam nije maksimalno anoniman jer se oslanja na prijavljenu širinu pojasa od strane usmjernika, što otvara prostor za maliciozno ponašanje - lažnim oglašavanjem visokih vrijednosti širine pojasa povećava se vjerojatnost bivanja odabranim za neku poziciju u kanalu. 3.4. Upravljanje zakrčenjem i tokom Dobrovoljci su pokreću programe kojima mogu ograničiti dodijeljenu propusnost. Stoga Tor poslužitelji koriste algoritam kabla sa znakovima [2], kako bi osigurali konstantan prosječan broj dolazećih okteta u dužem periodu, istovremeno dozvoljavajući kratkotrajna prekoračenja iznad dozvoljene propusnosti. Budući da je broj okteta koji uđu u Tor mrežu otprilike jednak broju okteta koji iz nje izađu, u praksi je dovoljno ograničiti samo broj ulaznih okteta. Kod TCP tokova broj ulaznih i izlaznih okteta nije jednak: moguća je situacija gdje je za prijenos samo jednog okteta potrebna čitava prijenosna protokolna podatkovna jedinica veličine 512 okteta. Pristup poput Nagleovog algoritma ovdje nije moguć, budući da taj oktet može biti namijenjen nekoj interaktivnoj aplikaciji. Stoga se taj slučaj tretira kao da je prijenosna protokolna podatkovna jedinica u potpunosti popunjena. 25 3. Protokol Tor Rubni čvorovi mogu heuristički razlikovati interaktivne tokove od običnih tokova uspoređujući frekvencije prosljeđivanja protokolnih podatkovnih jedinica. Dajući prednost interaktivnim tokovima osigurava im se prihvatljivo kašnjenje, pri čemu obični tokovi i dalje imaju dobru sveukupnu propusnost. Budući da izlazi mreže nisu uniformni, ovakav pristup je ranjiv na napad skraja-na-kraj, međutim napadač koji promatra oba krajnja čvora toka može saznati ovu informaciju analizom prometa. Čak i uz ograničenje vrijednosti širine pojasa zakrčenje, bilo namjerno ili slučajno, je realna opasnost. Ukoliko dovoljan broj korisnika odabere istu granu Tor mreže kao dio svojih virtualnih kanala, ona može postati zasićena. Pretpostavimo sljedeću situaciju: napadač kroz Tor mrežu pošalje veliku datoteku Web poslužitelju koji je pod njegovom kontrolom te potom, na strani Web poslužitelja, odbija čitati pristigle oktete. Bez mehanizma upravljanja zakrčenjem ovakva se uska grla šire natrag kroz čitavu mrežu. Upravljanje zakrčenjem uzima u obzir samo RELAY_DATA ćelije. Slika 3.11: Smještaj Tor protokola u OSI modelu, primjer multipleksiranja kanala i tokova. Kako bi mogao upravljati stvarnom potrošnjom propusnosti virtualnog kanala svaki usmjernik koristi dva prozora. Vrijednost prozora pakiranja govori koliko prijenosnih protokolnih podatkovnih jedinica iz ulaznih TCP tokova odredište/usmjernik smije pakirati, tj. poslati natrag posredniku/izvorištu. Vrijednost prozora isporuke govori koliko prijenosnih protokolnih podatkovnih jedinica, koje dolaze od korisničkog posrednika, usmjernik može isporučiti TCP tokovima na odredišteizvan mreže. Početna vrijednost svakog prozora postavlja se na 1000. Svaka isporuka ili pakiranje smanjuje vrijednost odgovarajućeg prozora za jedan. Kada usmjernik primi dovoljan broj prijenosnih protokolnih podatkovnih jedinica - u trenutnom ostvarenju ovaj parametar iznosi 100 - šalje RELAY_SENDME ćeliju kojoj identifikator toka nije postavljen u smjeru korisničkog posrednika. Po primitku RELAY_SENDME naredbe čvor povećava vrijednost prozora pakiranja za 100. Analogna situacija u suprotnom smjeru povećava vrijednost prozora isporuke. Po svakoj se TLS vezi između dva čvora Tor mreže može multipleksirati više virtualnih kanala (C i), a po svakom se virtualnom kanalu može multipleksirati više podatkovnih tokova ("TCP" tokovi aplikacija, Tici). Ukoliko vrijednost prozora pakiranja dosegne 0, usmjernik prestaje čitati podatke sa svih TCP veza pridruženih tokovima na odgovarajućem virtualnom kanalu te ne šalje ni jednu prijenosnu protokolnu podatkovnu jedinicu dok ne primi RELAY_SENDME ćeliju. 26 3. Protokol Tor Slika 3.12: Slijedni dijagram upravljanja zakrčenjem. Korisnički posrednik ponaša se jednako kao usmjernik, osim što čuva po jedan prozor pakiranja i prozor isporuke za svaki usmjernik u svom virtualnom kanalu. Također, ukoliko vrijednost prozora pakiranja dosegne 0, prestaje čitati podatke s tokova pridruženih odgovarajućem usmjerniku. Upravljanje tokom slično je upravljanju zakrčenjem. Čvorovi koriste RELAY_SENDME ćelije s postavljenim identifikatorom toka kako bi ostvarili kontrolu tijeka podataka za svaki pojedinačni podatkovni tok na virtualnom krugu. Slika 3.13: Slijedni dijagram upravljanja tokom. Za svaki se tok početno postavlja vrijednost prozora pakiranja na 500 te ju, po primitku RELAY_SENDME ćelije, povećava za fiksnu vrijednost - u trenutnom ostvarenju ovaj parametar iznosi 50. Prije no što pošalje RELAY_SENDME ćeliju, mehanizam kontrole toka mora provjeriti je li primio dovoljan broj prijenosnih protokolnih podatkovnih jedinica te da li je broj okteta koji nisu pogurani u odgovarajući TCP tok ispod određene vrijednosti, koja u trenutnom ostvarenju iznosi 10 veličina ćelije. 3.5. Skrivene usluge U ovom potpoglavlju detaljno su opisane skrivene usluge (engl. location hidden services). Korisnik može ponuditi TCP uslugu, npr. Web poslužitelj, bez otkrivanja svoje IP adrese. Osim što ovakva vrsta anonimnosti uvelike oslabljuje mogućnost (D)DoS napada - budući da ne zna IP adresu usluge, napadač je prisiljen napasti čitavu Tor mrežu; bjelodan je pokazatelj svrhe Tor protokola korisnik može objaviti materijal nepoćudan široj zajednici ili napadačima bez bojazni da će biti onemogućen u toj nakani, što mu na nezaštićenoj mreži ne bi uspjelo. Pomoću registara prijavljenih skrivenih usluga moguće je pretraživati njihov sadržaj. Za pretraživanje skrivenih usluga postoji tražilica Torgle koja je također postavljena kao skrivena 27 3. Protokol Tor usluga. Postavljač ne mora oglasiti skrivenu uslugu u registru skrivenih usluga, što znači da korisnici moraju znati javni ključ usluge te koji su čvorovi uvoda, kako bi joj mogli pristupiti. 3.5.1. Čvorovi susreta i čvorovi uvoda Čvorovi susreta omogućavaju pružanje usluga bez potrebe za otkrivanjem mjesta usluge tj. IP adrese u Tor mreži. Klijent odabire čvor susreta, otvara virtualni kanal prema njemu te obavještava čvor uvoda skrivene usluge o tome. Skrivena usluga odlučuje želi li prihvatiti klijentov zahtjev te gradi virtualni kanal prema čvoru susreta čime je efektivno uspostavljen virtualni kanal između skrivene usluge i klijenta bez da znaju jedno za drugo, već samo za čvor susreta. Slika 3.14: povezivanje klijenta na skrivenu uslugu preko čvora susreta Ukoliko se virtualni kanal prekine zbog vanjskog uzroka, pogođena strana gradi ponovo virtualni kanal prema čvoru susreta. Osim što se podaci prenose neizravno, ovakav pristup omogućava pružatelju usluge da odabere svoje klijente.Korisnik koji želi uspostaviti skrivenu uslugu mora odabrati privatni i javni ključ kako bi ju mogao identificirati. Odabire nekoliko čvorova uvoda (1), koje oglašava na razrješavaču potpisane javnim ključem usluge (2). Svaki čvor uvoda posjeduje javni ključ odgovarajuće usluge što onemogućava lažno predstavljanje. Potom uspostavlja virtualne kanale od čvora skrivene usluge do čvorova uvoda i čeka na zahtjeve klijenata. Ako pitani čvorovi odbiju biti čvorovi uvoda, ponavlja postupak. Kako bi klijent mogao pristupiti skrivenoj usluzi mora znati sažetak javnog ključa usluge (3). Ostale podatke potrebne za uspostavu veze dobiva od razrješavača upravo pomoću tog sažetka. Odabire jedan čvor mreže kao čvor susreta (virtualni kanal OP-RP) snabdijevajući ju nasumično odabranim kolačićem susreta kako bi prepoznala davatelja usluge kada se poveže na nju (4). Ako čvor odbije biti čvor susreta, ponavlja upit drugom čvoru. Potom stvara virtualni krug prema jednom od čvorova uvoda i šalje mu poruku kriptiranu javnim ključem usluge koja sadrži: identitet klijenta, lokaciju točke susreta, kolačić susreta te prvu polovicu Diffie-Hellmanovog rukovanja. Čvor uvoda prosljeđuje poruku skrivenoj usluzi (5). 28 3. Protokol Tor Ako pružatelj usluge smatra da klijent smije pristupiti usluzi (6), uspostavlja virtualni kanal prema čvoru susreta (virtualni kanal OPHS-RP) te mu šalje: kolačić susreta, drugu polovicu DiffieHellmanovog rukovanja i sažetak zajedničkog sjedničkog ključa (7). Čvor susreta spaja virtualne krugove OPHS-RP i OP-RP u jedan, a klijent šalje RELAY_BEGIN podatkovnu protokolnu jedinicu čime je uspostavljen anonimni tok te se daljnja komunikacija odvija uobičajeno (8). Kao što je već razjašnjeno, čvor susreta ne zna ništa o sudionicima komunikacije ni o prometu koji teče preko nje. Poruka koju klijent šalje čvoru uvoda može sadržavati i početnu autorizacijsku značku dobivenu od pružatelja usluge, koja može služiti za identifikaciju klijenata, ali i ograničenje pristupa samo odabranim klijentima. U normalnim uvjetima usluga može biti dostupna preko zrcalnih stranica na nezaštićenoj mreži. Ukoliko su zrcalne stranice napadnute i srušene klijenti s autorizacijskom značkom uvijek mogu pristupiti usluzi preko Tor mreže. Ovakvim pristupom, čvorovi uvoda postaju meta (D)DoS napada. Pružatelj usluge može odabranim korisnicima poslati listu trenutnih ili budućih neoglašenih točaka uvoda, što se pokazalo vrlo praktičnim rješenjem u slučaju da postoji stabilna i velika čvorova uvoda. Također može izdavati tajne javne ključeve za upite razrješavaču, ili jednostavno povećati broj točaka uvoda. Ovi pristupi ograničavaju izloženost usluge, čak i ako su neki korisnici s autorizacijskom značkom sudionici napada. 3.5.2. Lociranje skrivenih usluga U konceptu skrivenih usluga postoji inherentna slabost: usmjernik koji je u virtualnom kanalu prvi do skrivene usluge zna njenu IP adresu, međutim ne zna da ona pripada upravo poslužitelju skrivene usluge. Ako usmjernik zna da je prvi susjed skrivene usluge u virtualnom kanalu, skrivena usluga je kompromitirana. Na ovom principu i činjenici da Tor mreža ima konačan i dovoljno malen broj (~2000) čvorova temelji se napad lociranja skrivene usluge pomoću samo jednog zlonamjernog usmjernika. Slika 3.15: unutarnji aktivni napadač u mat poziciji Napadač oglašava svoj usmjernik s visokim vrijednostima poželjnih značajki ("Bandwidth" i "Uptime") te koristeći usmjernik istovremeno kao klijent, neprestano otvara i prekida virtualni kanal prema skrivenoj usluzi primoravajući ju tako na rotaciju čvorova koji čine dio virtualnog kanala OPHS-RP. Obzirom da je odabir čvorova na putu u osnovi slučajan, izgledno je da će nakon doglednog vremena zlonamjerni usmjernik postati prvi susjed skrivene usluge. Sa svakim novostvorenim virtualnim kanalom u kojem se zlonamjerni usmjernik ne nalazi, povećava se vjerojatnost da će nalaziti u sljedećem virtualnom kanalu. Napadač može detektirati da je dio virtualnog kanala OP HS-RP analizom prometa, tj. koreliranjem oblika prometnih tokova u vremenu. Točnije, pretražuje oblike prometnih tokova svih virtualnih kanala u kojima je na poziciji prijenosnog (srednjeg) čvora na uzorak prometa poslanog u virtualni kanal prema skrivenoj usluzi. Preostaje samo odrediti na kojoj je poziciji u virtualnom kanalu OP HS-RP napadačev usmjernik. Ukoliko IP adresa jednog od susjednih čvorova napadačevog usmjernika nije u konsenzusu stanja 29 3. Protokol Tor mreže, a budući da se virtualni kanali grade od usmjernika koji su navedeni u konsenzusu, znači da je skrivena usluga iza posrednika te da je upravo ta IP adresa adresa skrivene usluge. Ovo vrijedi pod uvjetom da nije mijenjana standardna logika odabira puta. Dakako, nije za očekivati da će postavljač skrivene usluge mijenjati logiku odabira puta na način da koristi neoglašene usmjernike, osim ukoliko su pod njegovom kontrolom. I u tom slučaju to predstavlja sigurnosni rizik, obzirom da ga odvaja od ostatka mreže narušavajući time anonimnost skrivene usluge. Ukoliko je skrivena usluga iza usmjernika, situacija je malo kompleksnija te se u tom slučaju pozicija napadačevog usmjernika u virtualnom kanalu OPHS-RP određuje prethodnikovim napadom ili napadom mjerenjem udaljenosti - metrika udaljenosti temelji se na RTT vremenu i pokazala se pouzdanom neovisno o geografskoj lokaciji usmjernika [13]. U scenariju kada je skrivena usluga iza posrednika IP adresa skrivene usluge može se odrediti u vremenu od svega nekoliko minuta do pola sata. U scenariju u kojem je skrivena usluga iza usmjernika potrebno je i do nekoliko sati. Ukoliko napadač kontrolira i čvor susreta (što ne predstavlja problem obzirom da klijent odabire čvor susreta) vrijeme lociranja skrivene usluge i u ovom scenariju pada na svega nekoliko minuta. U [13] obrađen je napad lociranja skrivene usluge s referencama na spomenute napade. Interesantno je napomenuti kako su autori po prvi puta u praksi, bar koliko je poznato, izveli prethodnikov napad koji je varijanta napada presijecanjem te da se do sada, u teoriji i simulacijama, pokazao razarajućim za anonimne komunikacijske sustave općenito. Napad presijecanjem vrijedi općenito za anonimne komunikacijske sustave obzirom da ih tretira kao crnu kutiju. Empirijski rezultati potvrdili su snagu prethodnikovog napada. 3.5.3. Čvorovi stražari Navedena slabost skrivenih usluga počiva na činjenici što napadač može prisiliti skrivenu uslugu da stvaranjem novih virtualnih kanala njegov usmjernik dođe na željenu poziciju. Ovo je ujedno i slaba točka napada. U [13] referencirana je metoda očuvanja anonimnosti kanala pomoću čvorova pomagača. Ideja je da prvi čvor virtualnog kanala uvijek bude isti čvor, čvor pomagač. Kako bi se bolje sakrio primatelj, posljednji čvor u virtualnom kanalu također je čvor pomagač. Ako je čvor pomagač kompromitiran, tada je i cijeli kanal kompromitiran. Međutim, ako je čvor pomagač korektan, tada napadač nikada neće doći na rubnu poziciju u virtualnom kanalu i neće moći locirati sudionike komunikacije. Očito, ovi čvorovi moraju biti komponente visokog povjerenja. Ako napadač kontrolira C od N usmjernika tada vjerojatnost da kontrolira naš ulazni i izlazni čvor C 2 iznosi - pod pretpostavkom da gradimo običan, ne-brzi kanal. Međutim, kako se kanali N rotiraju, ova vjerojatnost teži prema jedan. Primjenimo li spomenutu metodu, vjerojatnost da smo C N −C odabrali kompromitirani ulaz je , a da smo odabrali dobar ulaz , ali ne mijenja se s N N vremenom. Ova metoda koristi se i u Tor mreži s preciznijim nazivom: čvorovi stražari. Korištenje čvorova čuvara moguće je u konfiguracijskoj datoteci odrediti kao preferenciju ili zahtjev pri izgradnji svih virtualnih kanala, dakle i onih koji se ne koriste za skrivene usluge. Odabir čvorova čuvara vrše poslužitelji registara stanja mreže na temelju visokih vrijednosti značajki (zastavica) "Uptime" i "Bandwidth" (iz opisnika) dodjeljujući mu zastavicu "Guard" (u 30 3. Protokol Tor konsenzusu stanja mreže). Još jednom se pokazuje ozbiljan sigurnosni rizik sustava, obzirom da vrijednosti spomenutih zastavica mogu biti lažno prijavljene te ih sustav nikada ne provjerava, iako se ručno vode crne liste usmjernika. Ukoliko je odabir čvorova čuvara nasumičan, uz zahtjeve na mrežne performase usmjernika, tada skup svih čvorova čuvara mora biti dovoljno velik, kako bi vjerojatnost odabira zlonamjernog čvora čuvara bila dovoljno mala. Uz mali skup svih čvorova čuvara, vjerojatnost da je jedan od njih zlonamjeran znatno je manja, međutim, osim što time postaju meta napadača, ujedno se i particioniraju od ostatka mreže smanjujući svoju anonimnost. Naravno, čvorove čuvare moguće je odabrati temeljem povjerenja u dobre namjere administratora usmjernika, međutim to ne znači da taj usmjernik može biti kompromitiran od strane napadača zbog nesposobnosti/nemogućnosti administratora usmjernika. Ovaj problem na Tor mreži rješava se primarnim i pričuvnim listama "pouzdanih" čvorova čuvara. Izvršen je napad na skrivenu uslugu s jednim čvorom čuvarom. Kao i u prethodnim napadima, u roku nekoliko sati identificiran je čvor čuvar na poziciji prvog čvora do skrivene usluge. Sama skrivena usluga ostala je sigurna, iako njen čvor čuvar sada može biti izložen (D)DoS napadu. Upotrebom čvorova čuvara uvelike je smanjena opasnost lociranja skrivenih usluga, iako nije potpuno otklonjena. Za lociranje skrivene usluge sa samo jednim čvorom čuvarom, osim jednog do dva zlonamjerna usmjernika, potrebni su i resursi za onemogućavanje svih čvorova čuvara skrivene usluge. Onemogućeni su napadači s "malim" resursima, a napadačima s dostatnim resursima otežan je napad. Za sljedeće verzije protokola razmatra se mogućnost slojevitog slaganja čvorova čuvara, na način da se na poziciju prvog čvora do skrivene usluge biraju čvorovi iz jednog sloja (skupa), a za svaki čvor tog sloja postoji drugi sloj čvorova čuvara iz kojih se biraju čvorovi za poziciju drugog čvora do skrivene usluge. 3.5.4. Čvorovi sluge Skrivena usluga postavljena iza Tor usmjernika s uslojenom obranom čvorova stražara može dovoljno dobro jamčiti anonimnost. Ako nije moguće locirati skrivenu uslugu, može ju se barem onemogućiti (D)DoS napadom na sve čvorove uvoda. Čvorovi sluge služe kao posrednici kako bi klijenti mogli komunicirati sa čvorovima uvoda bez da znaju identitet čvora uvoda. Slika 3.16: Pristupanje čvoru uvoda skrivene usluge preko čvora sluge. Podcrtani brojevi predstavljaju nepromijenjene dijelove protokola. 31 3. Protokol Tor U osnovi, čvor sluga obavlja istu fukciju za čvor uvoda kao čvor susreta za samu skrivenu uslugu. Svaki čvor sluga ima svoju značku (VT) u kojoj je njegov identifikator (VI) i identifikator čvora uvoda kojeg poslužuje (IDIP). Svako posluživanje, tj. par čvor sluga – čvor uvoda, identificirano je parom ključeva (SKSRV, PKSRV) i identifikatorom (IDSKSRV). Ovaj trojac generira poslužitelj registar, a tajni ključ posluživanja zajedno s identifikatorom posluživanja prosljeđuje skrivena usluga čvoru uvoda u prvom koraku. U prethodnoj varijanti popis čvorova uvoda za neku skrivenu uslugu bio je indeksiran na poslužitelju registru javnim ključem usluge. Umjesto da klijent dohvati popis čvorova uvoda, dohvaća kartice za kontakt koje sadrže popis svih čvorova sluga za tu uslugu. Svaka kartica ima svoj identifikator i trajanje, a informacija o čvoru sluzi njegov identifikator, vrijeme trajanja, značku i javni ključ posluživanja. Klijent odabire jednog čvora slugu iz kartice za kontakt, povezuje se na njega i prosljeđuje mu značku i teret CREATE ćelije kriptirane javnim ključem posluživanja (ETM) (3). Čvor sluga, dekriptira značku svojim tajnim ključem i prosljeđuje (4) identifikator iz značke zajedno s teretom CREATE ćelije čvoru uvoda koji je naveden u znački. Identifikator čvora sluge sastoji se od identifikatora posluživanja, identifikatora čvora sluge i vremena isticanja posluživanja, potpisan tajnim ključem posluživanja te kriptiran javnim ključem čvora uvoda još od strane poslužitelja registra. Čvor uvoda provjerava identitet čvora sluge i pomoću tereta CREATE ćelije otvara virtualni kanal prema klijentu. Protokol se dalje odvija kako je navedeno. Na ovaj način autentificirani su međusobno čvor uvoda i klijent bez da znaju jedno za drugo putem ključa posluživanja. Time je ujedno i onemogućen napad čovjekom-u-sredini od strane čvora sluge. Isto tako svako posluživanje identificirano je od strane skrivene usluge, što joj omogućava da izgradi reputacijski sustav za korisnike i time poboljša svoju autorizacijsku strategiju. Čvorovi sluge trebali bi zadovoljavati uvjete stabilnosti i neke minimalne širine pojasa. Jedini način za onemogućavanje skrivene usluge sada je preuzimanje dovoljno čvorova sluga u mreži kako bi mogli locirati čvorove uvoda. U [14] navedena je, uz mrežu od pet stotina čvorova, sljedeća ocjena: za upotrebu samo jednog kompromitiranog čvora sluge potrebno je nešto manje od četiri stotine kompromitiranih čvorova u mreži da bi vjerojatnost lociranja svih točaka uvoda bila oko pola, dok je uz upotrebu deset kompromitiranih čvorova sluga potrebno nešto više od pedeset kompromitiranih čvorova u mreži za istu vjerojatnost. U istom slučaju za gotovo sigurno prepoznavanje (>0.9) potrebno je nešto manje od stotinu i pedeset kompromitiranih čvorova u mreži. Ovakav poboljšani protokol može jamčiti zadovoljavajuću razinu anonimnosti i dostupnosti pružateljima skrivenih usluga. 3.5.5. Povezivanje s korisničkim programima Pružatelj usluge snabdijeva svoj korisnički posrednik lokalnom IP adresom i pristupnim vratima usluge, strategijom za autorizaciju klijenata te javnim ključem usluge. Korisnički posrednik anonimno objavljuje zapis potpisan privatnim ključem na razrješavaču koji se sastoji od: javnog ključa usluge, vremena isteka zapisa, te liste točaka uvoda. Zapisi na razrješavaču indeksirani su sažetkom javnog ključa. Web poslužitelj pružatelja usluge ostaje nepromijenjen te ne zna ni da je skriven iza Tor mreže niti je li iza posrednika ili usmjernika. Posrednik također ostaje nepromijenjen – klijentsko sučelje i dalje je SOCKS posredničko sučelje. Sve potrebne informacije kodirane su u FQDN imenu koje klijent koristi pri uspostavi veze. Skrivene usluge koriste virtualnu vršnu domenu .onion: alfanumerička imena računala domaćina poprimaju oblik x.y.onion, gdje je x autorizacijski kolačić, a y sažetak javnog ključa usluge. 32 3. Protokol Tor Posrednički program klijenta pregledava upisane adrese, ukoliko su namijenjene skrivenom poslužitelju dekodira ključ i počinje postupak spajanja kao što je opisano. 33 4. Automati stanja simulacijskih elemenata U ovom poglavlju opisani su automati stanja za protokol Tor. Svrha modela je da bude platforma za daljnji razvoj protokola, tj. projektiranje reputacijskog sustava. Stoga se u prvoj iteraciji modelira isključivo funkcionalnost potrebna za ostvarivanje anonimizirane veze. Funkcionalnost skrivenih usluga u potpunosti je zanemarena. Ćelija RELAY_DROP ne koristi se u modelu, kao ni sve ćelije za skrivene usluge. Funkcionalnost poslužitelja registara modelirana je djelomično, tj. promet dokumentima stanja iz perspektive klijenta poštuje se u potpunosti. Svaki Tor usmjernik može ujedno biti i izlazni čvor, odnosno spojiti se na vanjska mrežna odredišta. U modelu postoje četiri simulacijska elementa: Tor posrednik, Tor usmjernik, predposlužitelj registar te poslužitelj registar. Sve sheme podliježu UML 2.2 specifikaciji. Slika 4.1: Dijagram stanja simulacijskog elementa. Simulacijski element sastoji se od upravljačke komponente, komponenti koje modeliraju virtualne kanale te komponenti koje predstavljaju tokove. Za svaki simulacijski element definirana je količina paralelnih TLS kanala te broj virtualnih kanala. Na slici 4.1 prikazana je načelna shema simulacijskog elementa. Upravljačka komponenta ("control") prima ulaze ("input") te ukoliko je potrebno, prosljeđuje ih na obradu komponentama koje upravljaju kanalima ("circuits") ili tokovima ("streams"), a one vrše izlaze te obavještavaju upravljačku komponentu o ishodu zatražene operacije. Model podržava i događaje stohastičke prirode kao što su prekid TLS kanala, prisutnost i odsutnost čvora na mreži te generiranje korisničkog (izvorišnog) i odredišnog prometa. Kriptografske operacije u potpunosti su zanemarene, iako se uzima u obzir vrijeme potrebno za njihovo izvršenje. U opisima stanja, rečenice u kurzivu predstavljaju postupke koje stvarne komponente vrše, ali su u modelu zanemarene. 34 4. Automati stanja simulacijskih elemenata 4.1. Tor posrednik or posrednik prima zahtjeve za vezom klijentskih aplikacija te gradi odgovarajuće virtualne kanale. Obzirom da je promet kroz Tor mrežu osjetno spor, posrednik gradi dodatne kanale kako bi što brže mogao ispuniti zahtjeve klijenata. Dodatno, vodi se statistika zahtjeva klijenata prema kojoj se grade tzv. predustrožni virtualni kanali. 4.1.1. Upravljačka komponenta Na slici 4.2 prikazana je upravljačka komponenta Tor posrednika koja poslužuje zahtjeve klijenata, prosljeđuje pristigli promet natrag klijentima i održava konsenzus stanja mreže. Slika 4.2: Dijagram stanja upravljačke komponente Tor posrednika. START: Tor posrednik je isključen. BOOTSTRAP: Tor posrednik je uključen. Kako bi mogao graditi virtualne kanale mora posjedovati važeći konsenzus stanja mreže te opisnike Tor usmjernika. Svaki posrednik dolazi s lokalnom kopijom popisa poslužitelja registara stanja. Pretpostavlja se da posrednik ne posjeduje nikakve dokumente stanja, izuzev liste poslužitelja registara stanja. Nasumice odabire jedan poslužitelj registara stanja s liste, otvara virtualni kanal prema njemu te otvara tok za promet dokumentima stanja. Dohvaća sve certifikate ključeva za potpisivanje poslužitelja registara stanja HTTP-om. Potom dohvaća konsenzus stanja mreže s adrese provjerava autentičnost. Zatvara kanal prema poslužitelju registara stanja. Ukoliko je konsenzus autentičan slijedi dohvaćanje opisnika Tor usmjernika s predposlužitelja registara stanja. Odabiru se najmanje tri predposlužitelja, osim ako bi to značilo da je potrebno više od jednog zahtjeva za manje od četiri opisnika, inače ih se odabire što manje. Ne dohvaća se više od stotinu dvadeset i osam opisnika po predposlužitelju. Raspodjela zahtjeva za dohvaćanjem po predposlužiteljima je nasumična. Svi dohvaćeni opisnici koji nisu zatraženi odbacuju se, a ostalim se opisnicima provjerava autentičnost. 35 4. Automati stanja simulacijskih elemenata Ukoliko je poslužitelj registara stanja nedostupan, ili konsenzus nije autentičan, postupak se ponavlja za novi poslužitelj stanja. Tor posrednik ne gradi kanale dok nema važeći konsenzus stanja mreže i najmanje jednu četvrtinu svih opisnika za koje vjeruje da rade. LISTEN: Tor posrednik ima dovoljno svježih informacija o stanju mreže i može početi graditi virtualne kanale. Posrednik pokušava imati uvijek otvoren jedan čisti brzi kanal koji dozvoljava spajanje na vanjsko odredište s pristupnim vratima za HTTP te najmanje dva čista unutarnja, brza i stabilna kanala za slučaj da se pojavi (R)DNS zahtjev ili zahtjev prema skrivenoj usluzi. Ukoliko je postavljena skrivena usluga, grade se najmanje tri ovakva kanala. Za svaki dolazni zahtjev provjerava se jesu li tražena pristupna vrata na listi dugoživućih pristupnih vrata. Ukoliko jesu, pokušava se održati dva brza izlazna kanala koji dozvoljavaju takvo spajanje. Ako je prošlo više od sat vremena od posljednjeg zahtjeva, kanali za ta pristupna vrata se zatvaraju. Ako ni jedan postojeći kanal (izgrađen ili u izgradnji) ne zadovoljava dolazni zahtjev gradi se novi kanal, inače se na odgovarajućem kanalu otvara tok za taj zahtjev. Ukoliko se zahtijeva pristup skrivenoj usluzi ili pristup određenom izlaznom čvoru (putem .exit notacije u URL-u odredišta), a postoji čisti kanal, tada se reže na posljednjem čvoru i širi na traženi čvor. Ako se kanal ne uspije dovršiti, postojeći dio kanala se zatvara. Ako se kanal ne uspije izgraditi N puta u X sekundi, ponovna izgradnja počinje tek nakon X sekundi. Tor posrednik nasumce odabire identifikator virtualnog kanala. Ukoliko zahtjev za otvaranjem tok ne uspije s razlogom EXITPOLICY, posrednik tog čvora ne smatra više izlaznim dok ne dohvati novi opisnik za njega. Ako se klijentski zahtjev ne posluži u vremenu SocksTimeout (standardno iznosi 2 min) posrednik dojavljuje grešku klijentu zatvarajući SOCKS vezu. Ukoliko je nekom virtualnom kanalu isteklo vrijeme trajanja, potrebno ga je rotirati, odnosno prebaciti sve tokove na novi virtualni kanal. Specifikacije protokola ne opisuju kako je to izvedeno, ali uzevši u obzir navedeno, logično je za pretpostaviti kako se s izgradnjom novog kanala započinje Y sekundi prije isteka vremena trajanja. Sve dolazne poruke prosljeđuju se odgovarajućem kanalu odnosno toku, a ukoliko poruka nije naslovljena ni na jedan postojeći kanal odbacuje se. DIRECTORY: Svi dokumenti stanja mreže imaju trajanje u kojem su važeći i kada god ono istekne dohvaća se svježi dokument na način kao što je već opisano, osim za opisnike usmjernika. Klijent uvijek pokušava imati najbolji opisnik za neki usmjernik i to provjerava svakih deset sekundi. Opisnik je najbolji ako je objavljen prije najmanje deset minuta, posrednik ga ne posjeduje niti ga pokušava trenutno dohvatiti te smatra da odgovarajući usmjernik ima postavljene zastavice "Running" i "Valid". Također, posrednik ne preuzima opisnik ako bi ga odbacio odmah po dohvaćanju. Ako je potrebno dohvatiti opisnike za najmanje šesnaest poznatih usmjernika, ili je prošao interval od deset minuta klijent dohvaća opisnike. Ako dohvaćanje nije uspjelo, klijent to bilježi i ne dohvaća opisnike dok nije prošao određeni interval vremena – nakon prvog neuspjeha pokušava odmah ponovo, a potom čeka minutu, pet pa deset minuta, četvrti put pokušava nakon cijelog dana. Svakih sat vremena, brojač se poništava tako da se, efektivno, četvrti pokušaj vrši nakon proteklih sat vremena, a ne jednog dana. Klijent zadržava opisnik najviše dva dana ili dok se ne pojavi bolji opisnik. 36 4. Automati stanja simulacijskih elemenata 4.1.2. Virtualni kanal Na slici 4.3 prikazan je dijagram stanja virtualnog kanala iz perspektive Tor posrednika. Slika 4.3: Dijagram stanja virtualnog kanala iz perspektive Tor posrednika. START: Upravljačka komponenta predaje put i zahtijeva izgradnju novog virtualnog kanala. Ukoliko je TLS kanal prema čvoru stražaru već otvoren odmah se prelazi u izgradnju prve etape virtualnog kanala, inače se otvara TLS kanal prema čvoru stražaru. CONNECTING, CONNECTED: Otvoren je TLS kanal prema čvoru stražaru te se šalje NET_INFO ćelija niz kanal. Slijedi primanje NET_INFO ćelije pa je TLS kanal spreman za otvaranje virtualnog kanala te se šalje CREATE ili CREATE_FAST ćelija. OPENING, PENDING: Nakon što je primljena CREATED(_FAST) ćelija otvoren je virtualni kanal prema stražaru. Ukoliko je duljina puta jedan, virtualni kanal je otvoren. Prije izračunavanja simetričnog ključa za enkripciju podatkovnog toka na kanalu, provjerava se nisu li obje polovice Diffie37 4. Automati stanja simulacijskih elemenata Hellmanovog rukovanja degenerirane, tj. da su strogo veće od jedan i strogo manje od modulusa umanjenog za jedan. Ćelijama RELAY_EXTEND proširuje se virtualni kanal kako je zadano putem. Nakon primanja RELAY_EXTENDED ćelije od izlaznog čvora kanal je otvoren. OPENED: Virtualni kanal je otvoren i spreman za korištenje. Ukoliko je stigao (R)DNS zahtjev od strane klijentske aplikacije šalje se RELAY_RESOLVE ćelija niz kanal. Na PADDING ćeliju odgovara se istom te se brojač vremena neaktivnosti TLS kanala postavlja na nulu. Ako je generirano dovoljno prometa (veličine tereta stotinu ćelija) posrednik šalje RELAY_SENDME ćeliju svim usmjernicima koji tvore kanal. Ukoliko je ista ćelija primljena povećava se vrijednost prozora pakiranja za stotinu. RESOLVING: Ako je zahtjev uspješno izvršen iz kanala dolazi ćelija RELAY_RESOLVED, inače stiže ćelija RELAY_END s razlogom neuspjeha i opcionalnim dodatnim podacima. PADDING: Ako brojač vremena neaktivnosti TLS kanala istekne šalje se PADDING ćelija i čeka na odgovor istom od čvora stražara. NORMAL END: Normalni razlozi za gašenje kanala su: zbog nedostupnosti usmjernika (HIBERNATING, RESOURCELIMIT, INTERNAL), zbog isteka trajanja (FINISHED), zbog prekida (OR_CONN_CLOSED) ili nemogućnosti uspostave (CONNECTFAILED, TIMEOUT, DESTROYED) TLS kanala, zbog nepostojanja zatražene skrivene usluge (NOSUCHSERVICE) te NONE (potreban zbog kompatibilnosti unatrag). ABNORMAL END: Abnormalni razlozi za gašenje kanala su: zbog prekršenja protokola (PROTOCOL) te zbog lažnog predstavljanja (OR_IDENTITY). Logika oporavka temeljna na razlozima prekida nije navedena u specifikacijama protokola. Abnormalnim razlozima smatraju se samo oni koji mogu biti benigni isključivo ukoliko je razlog za takvo ponašanje greška u službenom kodu. Naravno, razni uzorci prometa s ostalim ćelijama mogu ukazivati na maliciozne namjere odredišnog Tor usmjernika, ali za detekciju istih potrebna je kompleksnija logika koja izlazi iz okvira bilo kojeg protokola prijenosnog sloja. 38 4. Automati stanja simulacijskih elemenata 4.1.3. Tok Na slici 4.3 prikazan je dijagram stanja virtualnog toka iz perspektive Tor posrednika. Slika 4.4: Dijagram stanja toka iz perspektive Tor posrednika. START: Upravljačka komponenta zahtijeva otvaranje novog toka i predaje URL traženog vanjskog odredišta. Šalje se RELAY_BEGIN ćelija niz kanal. PENDING: Ako je primljena RELAY_CONNECTED ćelija tok je otvoren, inače tok abnormalno završava. Ukoliko je razlog kraja izlazna politika posljednjeg čvora označava se ne-izlaznim do dohvaćanja njegovog svježeg opisnika. STREAMING: Ako klijentska aplikacija pošalje podatke oni se pakiraju u RELAY_DATA ćelije i šalju niz tok. Ukoliko iz toka stignu RELAY_DATA ćelije, provjerava se sažetak te, ako je valjan, prosljeđuje se klijentskoj aplikaciji, inače se tok zatvara. Ako je u spremnik za slanje toka preostalo manje od deset tereta ćelija ili je vrijednost prozora pakiranja manja od četiri stotine i pedeset, posrednik šalje RELAY_SENDME ćeliju niz tok. Ukoliko je ista ćelija primljena povećava se vrijednost prozora isporuke za pedeset. NORMAL END: Uz gorenavedene, normalni razlozi za gašenje kanala su: nemogućnost uspješnog (R)DNS razrješenja (REASON_RESOLVEFAILED), pokušaj otvaranja toka za promet dokumentima stanja prema usmjerniku koji nije (pred)poslužitelj registara stanja (REASON_NOTDIRECTORY), vanjsko odredište odbija spajanje (REASON_CONNECTREFUSED), veza prema vanjskom odredištu neočekivano je prekinuta (REASON_CONNRESET), anonimizirani TCP tok se zatvara (REASON_DONE) te svi ostali ralozi (REASON_MISC). 39 4. Automati stanja simulacijskih elemenata ABNORMAL END: Isti kao gorenavedeni. 4.2. Tor usmjernik Tor usmjernik je gradivni element Tor mreže te prema zahtjevima klijenata gradi virtualne kanale. Ukoliko mu to dozvoljava izlazna politika, može vršiti spajanja na vanjska odredišta te razrješavati (R)DNS upite. Klijenti mogu biti Tor posrednici izravno, ili preko drugih Tor usmjernika. 4.2.1. Upravljačka komponenta Na slici 4.5 prikazana je upravljačka komponenta Tor usmjernika koja poslužuje zahtjeve klijenata i održava konsenzus stanja mreže. Slika 4.5: Dijagram stanja upravljačke komponente Tor usmjernika. START: Tor usmjernik je isključen. BOOTSTRAP: Tor usmjernik je uključen. Kako bi mogao sudjelovati u gradnji virtualnih kanala mora posjedovati važeći konsenzus stanja mreže te opisnike Tor usmjernika. Postupak je identičan gorenavedenom. LISTEN: Tor usmjernik ima dovoljno svježih informacija o stanju mreže i može sudjelovati u gradnji virtualnih kanala. Usmjernik prvo ispituje dohvatljivost svojih pristupnih vratiju za podatkovni promet gradeći brzi virtualni kanal sa sobom kao posljednjim čvorom. Ako je uspješan odlučuje objaviti svoj opisnik. Potom gradi NUM_PARALLEL_TESTING_CIRC (4) virtualna kanala prema sebi te mjeri raspoloživu širinu pojasa. Ukoliko je usmjernik ujedno (pred)poslužitelj stanja ispituje dohvatljivost svojih pristupnih vratiju za promet dokumentima stanja gradeći kanal sa sobom kao posljednjim čvorom i otvarajući tok za promet dokumentima stanja. Sve dolazne poruke prosljeđuju se odgovarajućem kanalu odnosno toku, a ukoliko poruka nije naslovljena ni na jedan postojeći kanal odbacuje se. Ukoliko se promijeni IP adresa, ponovo se ispituje dohvatljivost. 40 4. Automati stanja simulacijskih elemenata Ako je nekom virtualnom kanalu isteklo vrijeme trajanja, potrebno ga je rotirati, odnosno prebaciti sve tokove na novi virtualni kanal. Usmjernik objavljuje novi opisnik svaki puta kada se ispuni jedan od sljedećih uvjeta: prošao je period vremena -koji uobičajeno iznosi 18 h od slanja posljednjeg opisnika, promijenila se vrijednost polja u opisniku koja nije vrijednost širine pojasa ("Bandwidth") ili ukupno vrijeme na Tor mreži bez prekida ("Uptime") te ako su se promijenili podaci o identitetu, izlaznoj politici usmjernika: Usmjernik je prešao u stanje hibernacije, vrijednost širine pojasa se povećala za najmanje dvostruko te se računalo domaćin se resetiralo (zastavica "Uptime" postaje 0). DIRECTORY: Svi dokumenti stanja mreže imaju trajanje u kojem su važeći i kada god ono istekne dohvaća se svježi dokument na način kao što je već opisano. 41 4. Automati stanja simulacijskih elemenata 4.2.2. Virtualni kanal Na slici 4.6. prikazan je dijagram stanja virtualnog kanala iz perspektive Tor usmjernika. Slika 4.6: Dijagram stanja virtualnog kanala iz perspektive Tor usmjernika. START: Upravljačka komponenta uspostavila je TLS kanal s izvorištem ili je predala već postojeći TLS kanal što znači da odmah prelazi u izgradnju prve etape virtualnog kanala. 42 4. Automati stanja simulacijskih elemenata CONNECTED, OPENING: Razmjenjuje se par NET_INFO ćelija, kako bi se spriječio napad čovjekom-u-sredini. Nakon razmjene CREATE(_FAST) ćelija projerava se degeneracija polovica ključa. Ako je primljena CREATE_FAST naredba usmjernik zna da je duljina kanala jedan i TREBAO BI odbiti sve zahtjeve za otvaranjem toka. Identitet drugog partnera provjerava se iz konsenzusa stanja mreže. OPENED: Virtualni kanal s klijentom sada je otvoren i može prihvaćati (R)DNS upite, širiti, rezati ili gasiti kanal te obavljati kućanske poslove u istom smislu kao što je to opisano za posrednika. Ako usmjernik nije posljednji na putu može primiti RELAY_TRUNCATED ćeliju te ju vraća niz kanal prema izvorištu. RESOLVING: Kada stigne (R)DNS zahtjev od klijenta, a njegova izlazna politika to dopušta, usmjernik razrješava upit i vraća rezultat izvorištu u RELAY_RESOLVED ćeliji. U suprotnom, vraća se RELAY_END ćelija s postavljenim REASON_EXITPOLICY razlogom. EXTENDING: Ako je usmjernik posljednji na putu uspostavlja novi virtualni kanal s traženim usmjernikom pomoću tereta RELAY_EXTEND ćelije. Identitet drugog partnera provjerava se iz tereta ćelije. Inače, prosljeđuje zahtjev niz kanal i čeka na odgovor. TRUNCATING: Ako je usmjernik posljednji na novom putu niz kanal šalje DESTROY ćeliju s postavljenim REQUESTED razlogom, inače prosljeđuje zahtjev niz kanal. PADDING: Ako brojač vremena neaktivnosti TLS kanala istekne, šalje se PADDING ćelija i čeka na odgovor istom od klijenta. NORMAL END: Uz gorenavedene moguć je još razlog kada se uništava kanal na zahtjev izvorišta (REQUESTED). ABNORMAL END: Isti kao gorenavedeni. 43 4. Automati stanja simulacijskih elemenata 4.2.3. Tok Na slici 4.7 prikazan je dijagram stanja virtualnog toka iz perspektive Tor usmjernika. Slika 4.7: Dijagram stanja toka iz perspektive Tor usmjernika. START: Prima se RELAY_BEGIN ćelija te se u izlaznom politikom Tor usmjernika vrši spajanje na vanjsko odredište. Ako URL vanjskog odredišta sadrži DNS domenu, razrješavanje vrši usmjernik. PENDING: Ako je spajanje uspjelo tok je otvoren te se šalje RELAY_CONNECTED ćelija posredniku. Inače, tok abnormalno završava, što se dojavljuje RELAY_END ćelijom s postavljenim odgovarajućim razlogom i mogućim dodatnim odgovorom vanjskog odredišta. STREAMING: Ako stignu RELAY_DATA ćelije provjerava im se sažetak te, ako je valjan, njihov se teret prosljeđuje vanjskom odredištu. Ukoliko od vanjskog odredišta stigne promet, pakira se u RELAY_DATA ćelije i šalje niz kanal prema posredniku. Kontrola toka obavlja se kao što je opisano. NORMAL END, ABNORMAL END: Isti kao gorenavedeni. 4.3. Promet dokumentima stanja Ako usmjernik primi RELAY_BEGIN_DIR ćeliju, tretira ju kao da je otvoren običan tok prema njemu, samo na pristupna vrata za promet dokumentima stanja. Dokumenti stanja dohvaćaju se i objavljuju HTTP-om. Slijedi popis URL-ova dokumenata stanja: • certifikati svih poslužitelja registara stanja http://<DA>/tor/keys/all.z 44 4. Automati stanja simulacijskih elemenata • konsenzus stanja mreže http://<DA>/tor/status-vote/current/consensus.z • opisnik Tor usmjernika http://<OR ili DA>/tor/server/<D>.z 45 5. Praktični rad Za ostvarenje modela odabran je OMNeT++ diskretni simulator ostvaren u programskom jeziku C++ [30]. Za neprofitne svrhe objavljen je pod ekvivalentom GPL licence, dok je komercijalnu upotrebu potrebno platiti. Kao praktični dio rada, ostvaren je simulator Tor mreže s osnovnom funkcionalnošću uspostavljanja anonimizirane TCP veze, odnosno: otvaranje i zatvaranje virtualnog kanala i toka te prosljeđivanje korisničkog prometa. Ova funkcionalnost ostvarena je nad INET okvirom, koji služi za simulaciju mrežnog prometa s uobičajenim protokolima. Za simulaciju je potrebno pripremiti sljedeće datoteke: • inicijalizacijska .ini datoteka u kojoj se nalaze svi parametri simulacije. • .ned datoteke (engl. NEtwork Definition) koja definira topologiju simuliranog sustava • .ned datoteka (engl. NEtwork Definition) svih modula koji se koriste. U ovoj datoteci definira se struktura modula (ulazi, izlazi i parametri) • C++ razredi u kojima je definirano ponašanje modula Jednostavni modul definiran je s tri datoteke s istim imenom, ali s različitom ekstenzijom: .ned, .h i .cc. Složeni modul sastoji se od više jednostavnih modula, a definiran je jednom .ned datotekom. Sve datoteke koje definiraju simulaciju prevode se u konačnici gcc prevodiocem u jednu izvršnu datoteku koja se potom izvodi u komandno-linijskom (CMDENV) ili grafičkom (TKENV) sučelju. Slika 5.1: Arhitektura OMNeT++ simulatora. Jezgra simulatora je programska knjižnica. U knjižnici simulacijskih modela nalaze se C++ ostvarenja svih modula. U izvršnom simulacijskom modelu nalaze se instance svih potrebnih modula. U simulacijskom okruženju (koje je također programska knjižnica) nalazi se ulazna točka (main funkcija) te glavna simulacijska petlja u kojoj se određuje sljedeći događaj. Simulacijsko okruženje je središnja komponenta simulatora. Ono određuje koji se moduli s kakvim vrijednostima parametara moraju instancirati, a te informacije prosljeđuje jezgri koja obavlja zadano. Također, zaduženo je za upravljanje pogreškama. U jezgri se izvršavaju trenutni i zakazuju budući događaji. Jezgra i izvršni model povezani su s korisničkim sučeljem pomoću jedinstvenog sučelja (objekt ev) koji pripada simulacijskom okruženju. Modularna arhitektura simulatora omogućava ponovnu iskoristivost pojedinih komponenti kao i visoku prilagodljivost simulatora. Npr. moguće je ostvariti vlastito korisničko sučelje umjesto jednog od dva standardna, kao i iskoristiti jezgru, ili jezgru i okruženje kao poseban modul za neku drugu namjenu. Nad OMNeT++ simulacijskim okruženjem napisano je nekoliko okvira za simuliranje različitih sustava. 46 5. Praktični rad 5.1. OMNeT++ INET INET je okvir u kojem se nalaze razni protokoli Interneta: UDP, TCP, SCTP, IP, IPv6, Ethernet, PPP, 802.11, MPLS, OSPF... U pravilu, čvorovi mreže su složeni moduli sastavljeni od jednostavnih modula. Svaki jednostavni modul ostvaruje funkcionalnost pojedinog protokola. Kao čvor domaćin odabran je nodes.inet.StandardHost složeni modul, uz minimalne preinake. Slika 5.2: Grafički prikaz datoteke StandardHost.ned. Modul notificationBoard, kao što mu i ime kaže, služi za intermodularnu komunikaciju. Modul interfaceTable ostvaruje funkcionalnost sličnu ifconfig naredbi. Modul namTrace služi za komunikaciju s jezgrom simulatora. Slika 5.3: respektivno s lijeva na desno, grafički prikaz složenih modula: NetworkLayer.ned, PPPInterface.ned te EthernetInterface.ned Iz ove definicije odstranjeni su udp i sctp modul, kao i odgovarajući App moduli, obzirom da Tor koristi isključivo TCP. NED jezik podržava parametrizirane tipove modula kao i vektorske ulaze odnosno izlaze. Primjer parametriziranog modula jest tcpApp modul. Parametar tcpAppType tipa string zadaje se u omnetpp.ini datoteci odgovarajuće simulacije, a u biti je ime razreda 47 5. Praktični rad koji ostvaruje TCP aplikaciju kao što su primjerice TCPEchoApp, TCPSessionApp, TCPBasicClientApp. // package <path> // import <path> module <name> { parameters: gates: submodules: TCPSpoofApp, int numTcpApps = default(0); string tcpAppType = default("n/a"); inout pppg[] @labels (PPPFrame-conn); inout ethg[] @labels (EtherFrame-conn); <instance_name>: <module_name> { parameters: } tcpApp[numTcpApps]: <tcpAppType> like ITCPApp { parameters: @display ("p=186,54"); } tcp: <tcpType> like ITCP { parameters: @display ("p=186,141"); } connections allowunconnected: for i=0..numTcpApps-1 { tcpApp[i].tcpOut --> appIn++; tcpApp[i].tcpIn <-- appOut++; } tcp.ipOut --> networkLayer.tcpIn; tcp.ipIn <-- networkLayer.tcpOut; Slika 5.4: Djelomični tekstualni prikaz datoteke StandardHost.ned. Kako bi se koristili parametrizirani moduli potrebno je definirati sučelje modula (like TCPApp). Sučelje definira isključivo ulaze i izlaze modula. Vektorski ulaz, kao što mu i samo ime kaže, omogućava da se više modula spaja na jedan modul. Potrebno je definirati dimenziju vektora u omnetpp.ini datoteci. Razred koji definira ponašanje modula mora naslijeđivati razred cSimpleModule kako bi ga simulator prepoznao kao simulacijski modul. Osim članskih funkcija initialize() i finish() koje služe za učitavanje vrijednosti parametara tj. zapisivanje rezultata simulacije u datoteku s rezultatima bitne su još i send(cMessage *msg,const char* gatename, int gateIndex = -1)funkcija za slanje poruka drugima modulima te scheduleAt(simtime_t t,cMessage *msg) funkcija koja služi za ostvarenje brojila. Naravno, moduli moraju biti povezani (<--, -->, <-->) u NED definiciji modula kako bi mogli komunicirati porukama. Članska funkcija koja definira ponašanje modula može biti prekrivena activity() ili handleMessage(cMessage *msg) funkcija. U dokumentaciji je preporučeno izbjegavanje prve funkcije "gdje god je to moguće". Razlog tome leži u činjenici što se potonja funkcija poziva kada se na ulaznim vratima modula pojavi poruka te završava po obradi primljene. Funkcija activity() se poziva nakon inicijalizacije te se pretpostavlja da završava kada završava i simulacija – ovisno o ostvarenoj logici, što u velikoj većini slučajeva znači da je "stalno živa". Neka funkcija zauzima 32 KB radne memorije na stogu i neka samo jedan jednostavni modul po čvoru ima njome definirano ponašanje. Ako se simulira mreža od 10000 čvorova gruba procjena daje konstantno zauzeće radne memorije od 320 MB samo za tu funkciju [30]. Uz upotrebu vektorskih modula i parametriziranih tipova modula korisniku je, nakon detaljnog upoznavanja s odgovarajućim dijelovima INET-a, omogućena relativno bezbolna promjena ponašanja u simulaciji jednostavnom promjenom parametara u omnetpp.ini datoteci. Prema navedenom prirodno se nameće dizajn modela: napisati modul koji ostvaruje ITCP.ned sučelje, a predstavlja jednu stranu TLS kanala te se vektorskim ulazom spaja na TCP modul. Nad tim modulom bio bi Tor modul s "donjim" vektorskim vratima za TLS module i "gornjim" 48 5. Praktični rad vektorskim vratima za korisničke aplikacije. Gornja vrata Tor modula mogu ostvariti ITCP.ned sučelje kako bi Tor bio transparentan za korisničke aplikacije. S TCP.ned modulom moguće je komunicirati izravno, odnosno slati mu poruke koje predstavljaju TCP protokolne podatkovne jedinice, ili korištenjem razreda Socket, koji enkapsulira logiku TCP-a. Radi jednostavnosti, odabrana je potonja varijanta. Iako Tor čvorovi slušaju na dvama pristupnim vratima, za potrebe simulacije dovoljna su jedna vrata obzirom da se RELAY_BEGIN_DIR ćelija tretira kao da je primljena RELAY_BEGIN ćelija na pristupnim vratima za promet dokumentima stanja [6]. Svaki bi Tor čvor imao jedan TLS modul za poslužiteljske veze - po spajanju se interno otvara nova utičnica kako bi poslužitelj mogao nastaviti slušati na istim vratima - te bi dinamički generirao TLS module za klijentske zahtjeve. Dinamičko generiranje modula vremenski je skupa operacija: nalaženje tipa modula - gdje je tip modula zadan kao string, generiranje modula, podešavanje parametara i povezivanje vratiju modula, poziv funkcije za generiranje podmodula te inicijalizacija modula. [30] Jedina konkretna brojka koja se u ovom trenutku može procijeniti jest broj kanala u sustavu. Realna Tor mreža ima ~250000 korisnika [18] i ~2000 čvorova [31] . Svaki posrednik, osim aktivnih korisničkih veza pokušava u svakom trenutku imati otvorenim barem deset neiskorištenih virtualnih kanala. Ako stotinu anonimizirajućih TCP kanala stane na jedan TLS kanal, odnosno deset virtualnih kanala na jedan TLS kanal i uz tri posredna čvora te za samo jedan anonimizirani TCP 250000 10 × ×4≈10 4 TLS modula. kanal po posredniku to je 100 10 Uz deset puta zahtjevnije korisnike i deset puta revnije posrednike potrebno je generirati milijun TLS modula. Smanji li se broj anonimiziranih TCP kanala po TLS kanalu na deset, a virtualnih kanala po TLS kanalu na tri, procjene rastu za dva reda veličine do 108 za najgori slučaj. Ako TLS modul zauzima 200 okteta - konačno TLS ostvarenje kao i TCP ostvarenje iznose upravo toliko - ukupno zauzeće radne memorije kreće se od 2 MB preko 200 MB do 20 GB samo za TLS module. Ovakav način razmišljanja navodi na štedljiviji pristup pri dizajnu modula. Eliminacijom vektorskih ulaza umjesto n1 modula postoji samo jedan TLS modul po čvoru, što znači da se njegova veličina smanjila za n veličina objekta cSimpleModule (128 okteta) te 4n veličina cGate objekta (24 okteta). Ušteda radne memorije iznosi 224n okteta po čvoru, što za deset veza po čvoru i četvrt milijuna posrednika iznosi 86 MB te za dvije tisuće usmjernika uštedu od 448n KB, odnosno uz deset TLS kanala po usmjerniku ~2.5 MB. Minimalna ukupna ušteda iznosi ~90 MB radne memorije – jer je ovo razmatranje provedeno samo za dva navedena razreda. Sve veličine objekata navedene su za 32-bitnu arhitekturu. Ušteda memorijskog prostora i procesorskog vremena je neupitna, međutim pitanje je koliko je značajna i je li uopće značajna, odnosno je li zanemariva. Drugim riječima, pri kojoj veličini problema ušteda dolazi do izražaja. Za točnu ocjenu trebalo bi napisati oba složena modula (uz dodatak mjerenja vremena izvršavanja koda pri izvođenju) te pokretati simulacije raznih veličina i potom usporediti dobivene rezultate. 49 5. Praktični rad 5.2. Ostvarenje protokola Tor Na slici 5.5 prikazana je definicija Tor posrednika, dok je definicija Tor usmjernika identična samo što ne postoji User modul. Dijagrami razreda prikazani su u nekorektnoj UML 2.2 notaciji - bez međusobnih relacija naslijeđivanja radi ograničenog prostora. Slika 5.5: Grafički prikaz datoteke OPHost.ned. Ponašanje modula tcpShell ostvareno je razredom TCPSrvCliApp, a modula TLS razredom TLSLayer. Ako je riječ o usmjerniku (ORHost.ned) ponašanje modula Tor ostvareno je razredom OR, a ako je riječ o posredniku (OPHost.ned) Tor modul ostvaren je razredom OP. Ponašanje modula User definirano je razredom UserApp. 50 5. Praktični rad 5.2.1. TCP ljuska Radi lakšeg razvijanja i preglednosti koda posrednik ne barata izravno "utičnicama" odnosno vezama, već je ta funkcionalnost izdvojena u nadogradnju TCP modula – TCP ljusku. Osnovna TCP aplikacija predstavljena je razredom TCPSrvCliApp koji se ponaša kao što mu ime kaže: ima jednu poslužiteljsku utičnicu na kojoj može posluživati proizvoljan broj veza te može upravljati proizvoljnim brojem klijentskih veza. Po spajanju klijenta na poslužiteljsku utičnicu, ili po primljenoj naredbi za otvaranje klijentske veze, ovaj razred stvara novu utičnicu, bilježi je u podrazred TCPSocketMap razreda map te stvara novu "dretvu" koja poslužuje tu vezu. Slika 5.6: Dijagram razreda TCPSrvCliApp koji javno naslijeđuje razred cSimpleModule. Razred TCPThread naslijeđuje razred baseThread kako bi putem članske varijable hostmod mogao gornjem sloju proslijediti primljene podatke ili dojaviti nasilan prekid veze. Razred također ostvaruje TCPSocket::CallbackInterface sučelje čije odgovarajuće javne članske funkcije poziva TCP modul po primitku odgovarajućeg događaja. Slika 5.7: Dijagram razreda TCPThread koji naslijeđuje razred baseThread. 51 5. Praktični rad Evidencija aktivnih kanala efektivno je određena objektom TCPSocketMap koji je mapa TCPSocket objekata indeksiranih po identifikatoru utičnice connID tipa int koji je ujedno i privatna članska varijabla razreda TCPSocket. Uvedena je redundantna evidencija iz tri razloga, a svako daljnje spominjanje identifikatora veze ili connID varijable odnositi će se na redundantnu evidenciju (TCPSrvCliApp::appCIDsForSockCID, TCPSrvCliApp::connIDs) osim ako nije drugačije napomenuto. Obzirom da su identifikatori utičnica (najvjerojatnije) slučajno generirani (veliki) brojevi, udobnije je i lakše razvijati aplikaciju na način da se identifikatori veza generiraju kao mali brojevi uvijek istim algoritmom, kako bi se što brže i lakše utvrdila ispravnost izvođenja simulacije. Osim toga, postoji načelna razlika između klijentskih i poslužiteljskih veza: pri otvaranju poslužiteljske veze informacija se propagira od TCP modula prema višim slojevima, dok se naredba za otvaranje klijentske veze šalje iz viših slojeva prema TCP modulu. U svakom slučaju Tor modul mora voditi vlastitu evidenciju aktivnih TCP veza, na način da postoji bijektivno preslikavanje između identifikatora i opisnika veze. Pri otvaranju poslužiteljske veze, prirodno je generirati identifikator veze u prvom sloju iznad TCP modula, kao što je pri otvaranju klijentske veze prirodno generirati identifikator veze u najvišem, odnosno sloju koji je i zatražio otvaranje veze. Obzirom da slojevi međusobno komuniciraju porukama potreban je algoritam koji će osigurati da ne dođe do kolizije identifikatora, ili voditi odvojene evidencije za klijentske i poslužiteljske konekcije. Potonje će se pokušati izbjeći jer narušava čitkost koda. Moguće je poslati poruku u kojoj se zahtijeva otvaranje klijentske veze te opisnik veze privremeno pohraniti u zasebnu strukturu da čeka na odgovor donjeg sloja koji će porukom javiti da je povezivanje uspjelo zajedno s identifikatorom veze. Tek je tada moguće pohraniti opisnik pod pravim identifikatorom. Ova varijanta sigurno nije najjednostavnije rješenje, pogotovo kada se uzme u obzir situacija u kojoj više klijentskih veza čeka spajanje pa je po primitku poruke o spajanju potrebno odrediti kojem je opisniku namijenjena. Određivanje se mora vršiti pomoću dodatnih identifikatora, primjerice, privremenih identifikatora ili utičnice, u smislu IP adrese i pristupnih vrata, za koju je stigla poruka. Ni ova varijanta ne čini kod čitkijim. Međutim, generira li se identifikator veze u sloju u kojem je to prirodno, izbjegava se sav dodatni posao i ne narušava se jednostavnost koda. Potreban je dakle algoritam generiranja identifikatora koji su uvijek jedinstveni bez intermodularne komunikacije. To je moguće učiniti tako da gornji sloj posjeduje inkrementalni statički brojač klijentskih veza te svakoj novoj vezi dodijeli netom odbačenu vrijednost brojača. Donji sloj održava dekrementalni statički brojač (TCPSrvCliApp::srvConnCnt) te se jednako ponaša. Tako klijentske veze imaju identifikatore koji rastu počevši od nule, dok poslužiteljske veze imaju identifikatore koji opadaju počevši od minus jedan. Obzirom da je u svakom sloju iznad TCP-a identifikator veze uvijek isti, svaki sloj može, ukoliko je potrebno, jednostavnim testiranjem vrijednosti identifikatora ustanoviti prirodu veze. TCPSrvCliApp::openSockets je mapa u kojoj su indeksirani statusi utičnica (otvorena / zatvorena) po identifikatoru utičnice. Razlog ovoj redundanciji jest greška u TCP modulu koji netom nakon što pošalje poruku da je utičnica zatvorena šalje poruku da je partner prekinuo vezu. Dakako da je takvo ponašanje nekorektno i prema protokolu i prema dokumentaciji, a rezultiralo je relativno benigno – nezatvaranjem veze. Stoga se prije pozivanja članske funkcije processMessage(cMessage *msg) odgovarajućeg TCPSocket objekta provjerava status 52 5. Praktični rad utičnice prema TCPSrvCliApp::openSockets te ukoliko je detektirana spomenuta situacija, problematična se poruka ignorira. Pri razvijanju aplikacije bilo je potrebno testirati funkcionalnost modula TCPSrvCliApp te je stoga napisan modul TCPConnectionManager. Taj modul vodi evidenciju veza pomoću Slika 5.8: Dijagram razreda TCPShellCommander koji javno naslijeđuje razred Commander i TCPConnectionManager koji javno naslijeđuje razred cSimpleModule. članske varijable TCPConnectionManager::connIDs te se u njemu nalazi i inkrementalni statički brojač TCPConnectionManager::cliConnCtr. TCPConnectionManager prima naredbe od TCPShellCommander razreda koji naslijeđuje razred Commander. Slika 5.9: Dijagram razreda Commander koji je nadklasa klasi TCPShellCommander. TCPConnectionManager modul prima sljedeće naredbe kao vrijednost string parametra cmdSh, a moraju biti zadane točno kako je napisano inače neće biti prepoznate: • povezivanje na zadano odredište "<IP>:<PORT>;" • slanje podatka <payload> po vezi <connID> "SEND <connID> <payload>;" • zatvaranje veze <connID> "CLOSE <connID>;" 53 5. Praktični rad 5.2.2. TLS sloj Modul TLSLayer u osnovi je isti kao i TCPConnectionManager modul, s tom razlikom što ne prima naredbe iz parametra pa tako nema ni TCPShellCommander razreda, već prima naredbe kao poruke (dijete razreda cMessage) s ulaznih vratiju cmdIn, odnosno od Tor modula. Slika 5.10: Dijagram razreda TLSLayer koji javno naslijeđuje razred cSimpleModule. TLS protokol ostvaren je na način da se nakon otvaranja TCP kanala razmjenjuju dvije poruke koje predstavljaju TLS certifikate, a u kojima se nalaze ključevi identiteta usmjernika. Osim toga nema potrebe za vođenjem evidencije kanala obzirom da to čini Tor modul. Slika 5.11: Dijagram razreda TCPLinkDesc. TCPLinkDesc je razred koji ostvaruje opisnik TCP odnosno TLS kanala. Koriste ga TCPConnectionManager te OR i OP moduli. 54 5. Praktični rad 5.2.3. Tor sloj Modul TorNode naslijeđuje cSimpleModule modul, sadržava sve identifikacijske podatke o čvoru, kao i paramtere poput vrijednosti prozora za kontrolu zakrčenja, vrijeme života kanala te vrijeme isteka za slanje PADDING ćelije. Također, tu se nalazi i konsenzus mreže kao statički vektor ORDescriptor razreda koji ostvaruju opisnike usmjernika. Ovaj razred brine se za kontrolu zakrčenja te se sve poruke, koje se šalju nižim slojevima iz modula OP ili OR, šalju funkcijom TorNode::sendCell(...). Sučelje IConsensus služi za dohvaćanje IP adrese, pristupnih vratiju za podatkovni promet te nadimka Tor čvora. Ostvaruju ga oba Tor modula. Slika 5.12: Dijagram modula TorNode javno naslijeđuje cSimpleModule, a nadrazred je modulima OP i OR. Na slici 5.13 nalazi se dijagram razreda modula OP::proccesVirtualCircuitClientSide(...) te OP::proccesVirtualStreamClientSide(...). 55 OP. Najvažnije funkcije su 5. Praktični rad Slika 5.13: Dijagram modula OP koji naslijeđuje cSimpleModule. Na slici 5.14 nalazi se dijagram razreda modula OR. Najvažnije funkcije su OR::proccesVirtualCircuitServerSide(..), OR::proccesVirtualCircuitClientSide(..) te OR::proccesVirtualStreamServerSide(...). OR preuzima ulogu klijenta u slučaju da mora proširiti virtualni kanal odnosno obraditi NET_INFO i CREATED ćeliju. Sučelje IORContext definira sve operacije koje su potrebne strojevima stanja za obradu virtualnih tokova i kanala. Slika 5.14: Dijagram modula OR koji naslijeđuje cSimpleModule. 56 5. Praktični rad Razred CellFactory po uzorku tvornice služi za generiranje svih ćelija potrebnih bilo kojem Tor čvoru. Slika 5.15: Dijagram razreda CellFactory. Na slici 5.16 prikazan je razred OPVirtualCircuitDescriptor koji ostvarujeopisnik virtualnog kanala za Tor posrednik - sastoji se od: puta definiranog slijedom ključeva identiteta usmjernika te identifikatora TLS i virtualnog kanala. Slika 5.16: Dijagram razreda OPVirtualCircuitDescriptor. Na slici 5.17 prikazan je razred ORVirtualCircuitDescriptor koji ostvaruje opisnik virtualnog kanala za Tor usmjernik, a sadrži identifikatore ulaznih i izlaznih TLS i virtualnih kanala. Slika 5.17: Dijagram razreda ORVirtualCircuitDescriptor. 57 5. Praktični rad Na slici 5.18 nalazi se razred OPVirtualStreamDescriptor koji ostvaruje opisnik virtualnog toka za posrednika . Ovaj opisnik sadrži identifikatore TLS i virtualnog kanala, virtualnog toka te identifikator korisničkog zahtjeva. Slika 5.18: Dijagram razreda OPVirtualStreamDescriptor. Na slici 5.19 nalazi se razred ORVirtualStreamDescriptor koji ostvaruje opisnik virtualnog toka . Ovaj opisnik sadrži identifikatore ulaznih i izlaznih TLS i virtualnih kanala te identifikator virtualnog toka. Slika 5.19: Dijagram razreda ORVirtualStreamDescriptor. Na slici 5.20 nalazi se razred ORDescriptor koji ostvaruje opisnik usmjernika. Ovaj opisnik sadrži sve potrebne podatke o usmjerniku. Slika 5.20: Dijagram razreda ORDescriptor. Na slici 5.21 nalazi se razred UserRequestDescriptor koji ostvaruje opisnik korisničkog zahtjeva. Taj opisnik sadrži identifikatore: TLS i virtualnog kanala, virtualnog toka, adresu odredišta odabrani put te identifikator samog zahtjeva. Idenitifikator zahtjeva ima analognu funkciju za OP modul kao idenitifikator veze za TCPSrvCliApp. 58 5. Praktični rad Slika 5.21: Dijagram razreda UserRequestDescriptor. 5.2.4. Korisnička aplikacija Modul UserApp prima naredbe od razreda TorCommander na sličan način kao što TCPSrvCliApp prima naredbe od razreda TCPShellCommander. Naredbe su: • otvaranje anonimiziranog TCP kanala: "<IP>:<port>;" • slanje podataka: "BULKSEND <reqID> <size> <u>;" <u> ∈{B , KB , MB} • zatvaranje virtualnog toka "KILL <reqID>;" Slika 5.22: Dijagram modula UserApp koji nasljeđuje razred cSimpleModule. Po slanju naredbe za otvaranje anonimiziranog TCP kanala, naredbe za slanje podataka blokiraju se do otvaranja anonimizirane veze. Interno se pamti status anonimizirane veze (UserApp::reqStatus) te količina podataka koje je potrebno poslati 59 5. Praktični rad (UserApp::usrTrafficData). Po otvaranju anonimne veze guraju se korisnički podaci OP modulu dok se međuspremik ne popuni. 5.3. Simulacija Simulira se otvaranje virtualnog kanala i otvaranje anonimizirane TCP veze prema odredištu, prijenos podataka te zatvaranje anonimizirane TCP veze i virtualnog kanala na lokalnoj mreži od pet Tor usmjernika, jednog Tor posrednika i jednog vanjskog odredišta. Svi čvorovi povezani su PPP vezom izuzev Tor posrednika i odredišta. Propusnost PPP veze iznosi jedan Mbps s kašnjenjem od desetine mikrosekunde, što je uz topologiju sustava definirano datotekom TorSimple.ned koja je prikazana u grafičkom obliku na slici 5.24. Slika 5.23: Simulirana mreža sa pet Tor usmjernika (grčka božanstva), jednim Tor posrednikom (client) i jednim vanjskim odredištem (destination). U inicijalizacijskoj datoteci omnetpp.ini datoteci definiraju se parametri korištenih modula. Postavlja se mrežna adresa i maska za čvor FlatNetworkConfigurator za automatsko usmjeravanje. Postavlja se veličina međuspremnika za pakete na PPP mrežnim sučeljima. Postavlja se način rada tcp modula da prosljeđuje stvaran promet, a ne samo količinu prometa. Odredištu se postavljaju pristupna vrata za promet. Za svaki Tor čvor (TorNode) definiraju se pristupna vrata za promet, nadimak i ključ identiteta usmjernika. Korisničkom posredniku definira se niz znakova s naredbama ("192.168.1.2:1000;BULKSEND 0 3 KB;KILL 0;") i duljina puta (3). Po pokretanju simulacije svi čvorovi osim posrednika otvaraju poslužiteljske utičnice. ** Event #7 T=0 TorSimple.Posejdon.tcp (TCP, id=79), on `PassiveOPEN' (cMessage, id=26) TCP connection created for (cMessage)PassiveOPEN Connection <unspec>:-1 to <unspec>:-1 on app[0],connId=2 in INIT (ptr=0x0xa9e9288) App command: OPEN_PASSIVE Starting to listen on: 192.168.1.3:443 Transition: INIT --> LISTEN (event was: OPEN_PASSIVE) Slika 5.24: Otvaranje poslužiteljskih utičnica. Tor posrednik odabire put, prelazi u stanje CONNECTING. ** Event #22 T=10 TorSimple.client.User (UserApp, id=10), on selfmsg `{1st command}' (cMessage, id=0) client.User URL = 192.168.1.2:1000 request id = -1 data size B = -1 payload string = payload code = 0 client.User connecting @ 192.168.1.2:1000 client.User: there is no usr traffic pending client.User: there are 0 user data streams pending and 1 requests: client.User: request reqID = 0 status = 1 ** Event #23 T=10 TorSimple.client.Tor (OP, id=11), on `CONNECT' (TorShellMessage, id=138) client.Tor code = 0 reqId =0 request id = client.Tor.control: LISTEN client.Tor: Posejdon 22222 Slika 5.25: Odabir puta na strani Tor posrednika. 60 5. Praktični rad client.Tor: Zeus 3333 client.Tor: Had 4444 client.Tor: Atena 5555 client.Tor: Hera 6666 client.Tor: user connecting @ 192.168.1.2:1000 client.Tor selecting path: Hera 192.168.1.7:443 Had 192.168.1.5:443 Posejdon 192.168.1.3:443 Prvi korak je otvaranje TLS veze prema čvoru stražaru Heri, koja prelazi u stanje CONNECTED. ** Event #81 T=10.0015763 TorSimple.Hera.Tor (OR, id=208), on `{TLS connected}' (TCPShellMsg, id=200) Hera.Tor.control: opening TLS link -1 as server from client(1111) HeraTor.VCFSM: TLS_CONNECTED INIT --> CONNECTED HeraTor.VCFSM: CONNECTING - TLS OPENING -1 waiting NET_INFO there are 1 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPENING Hera.Tor: there are no virtual circuits Hera.Tor: there are no pending virtual circuits Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links Slika 5.26: Otvaranje TLS veze na strani Tor usmjernika. Nakon što je TLS veza uspostavljena, posrednikov automat za virtualni kanal prelazi u stanje CONNECTED i šalje NET_INFO ćeliju, tj. otvara Tor vezu. Korisnički zahtjev 0 trenutno čeka na otvaranje virtualnog kanala koji će ga opsluživati (PENDING_VC). ** Event #105 T=10.0023364 TorSimple.client.Tor (OP, id=11), on `{TLS connected}' (TCPShellMsg, id=214) client.Tor.control: opening TLS link 0 towards Hera(6666) clientTor.VCFSM: TLS_CONNECTED CONNECTING --> CONNECTED clientTorVCFSM: CONNECTING - OPENING TLS 0 sending NET_INFO client.Tor.control: attaching request 0 to TLS 0 towards Hera there are 1 TLS links: TLS connID = 0 peer name = Hera peerID = 6666 state = OPENING client.Tor: there are no virtual circuits client.Tor: there are no virtual streams client.Tor: there are 1 user requests: client.Tor: reqID = 0 adress = 192.168.1.2@1000 state = PENDING_VC connID = 0 circID = 0 streamID = -1 path = Hera Had Posejdon current = 1 Slika 5.27: Otvaranje Tor veze na strani posrednika. Hera odgovara s NET_INFO ćelijom, tj. otvara Tor vezu prelazeći u stanje OPENING. ** Event #131 T=10.0071925 TorSimple.Hera.Tor (OR, id=208), on `NET_INFO' (TCPShellMsg, id=230) Hera.Tor: Tor cell recieved, cmd = 108 connID = -1 circID = 0 from client (26255836) on TLS -1 Hera.Tor.control: processing TLS link -1 as server from client(1111) HeraTor.VCFSM: CONNECTED --> OPENING recieved NET_INFO HeraTor.VCFSM: CONNECTED - TLS OPENED -1 sending NET_INFO there are 1 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPEN Hera.Tor: there are no virtual circuits Hera.Tor: there are no pending virtual circuits Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links Slika 5.28: Otvaranje Tor veze na strani usmjernika. Sada posrednik započinje Diffie-Hellmanovo rukovanje slanjem CREATE ćelije, prelazeći u stanje OPENING. Stvoren je opisnik za virtualni kanal, koji je na strani posrednika u stanju PENDING. Opisniku korisničkog zahtjeva 0 dodijeljen je virtualni kanal 4194450 u izgradnji pa korisnik čeka na otvaranje virtualnog toka (PENDING_VS). ** Event #157 T=10.0120486 TorSimple.client.Tor (OP, id=11), on `NET_INFO' (TCPShellMsg, id=249) client.Tor.control: Tor cell recieved, cmd = 108 circID = 0 from on TLS 0 client.Tor.control: processing TLS link 0 with Hera(6666) clientTor.VCFSM: NET_INFO recieved, CONNECTED NET_INFO clientTorVCFSM: CONNECTED - TLS OPENED 0 sending CREATE clientTorVCFSM: new circID = 4194450 on TLS 0 in STATE = PENDING client.Tor.control: attaching request 0 to VC 4194450 towards Hera there are 1 TLS links: TLS connID = 0 peer name = Hera peerID = 6666 state = OPEN client.Tor: there are 1 virtual circuits: client.Tor: VC circID = 4194450 connID = 0 state = OPENING client.Tor: there are no virtual streams client.Tor: there are 1 user requests: client.Tor: reqID = 0 adress = 192.168.1.2@1000 state = PENDING_VS connID = 0 circID = 4194450 streamID = -1 Slika 5.29: Diffie-Hellmanovo rukovanje na strani posrednika. 61 5. Praktični rad path = Hera Had Posejdon current = 1 Hera prelazi u stanje OPENED i odgovara CREATED ćelijom čime je otvorena Tor veza odnosno virtualni kanal 4194450 između nje i posrednika. ** Event #183 T=10.0169047 TorSimple.Hera.Tor (OR, id=208), on `CREATE' (TCPShellMsg, id=269) Hera.Tor: Tor cell recieved, cmd = 101 connID = -1 circID = 4194450 from client (26255836) on TLS -1 Hera.Tor.control: processing virtual circuit 4194450 on TLS -1 as server from client(1111) HeraTor.VCFSM: recieved CREATE on TLS -1 HeraTor.VCFSM: OPENED opened VC circID = 4194450 on TLS -1 there are 1 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPEN Hera.Tor: there are 1 virtual circuits: Hera.Tor: VC INcircID = 4194450 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = OPENED Hera.Tor: there are no pending virtual circuits Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links Slika 5.30: Diffie-Hellmanovo rukovanje na strani usmjernika. Posrednik prelazi u stanje PENDING, pristupa širenju virtualnog kanala prema Hadu i osvježava opisnike. ** Event #209 T=10.0217608 TorSimple.client.Tor (OP, id=11), on `CREATED' (TCPShellMsg, id=290) client.Tor.control: Tor cell recieved, cmd = 102 circID = 4194450 from on TLS 0 client.Tor.control: processing virtual circuit 4194450 with Hera(6666) clientTor.VCFSM: CREATED recieved, OPENED VC 4194450 client.Tor.control: path not built client.Tor.control: next node is 4444 client.Tor.control: next node position in path is 1 for connID = 0 circID = 4194450 clientTor.VCFSM: PENDING - CREATED recieved, VC 4194450 opened ENTRY GUARD Hera sending RELAY_EXTEND towards Had there are 1 TLS links: TLS connID = 0 peer name = Hera peerID = 6666 state = OPEN client.Tor: there are 1 virtual circuits: client.Tor: VC circID = 4194450 connID = 0 state = PENDING client.Tor: there are no virtual streams client.Tor: there are 1 user requests: client.Tor: reqID = 0 adress = 192.168.1.2@1000 state = PENDING_VS connID = 0 circID = 4194450 streamID = -1 path = Hera Had Posejdon current = 2 Slika 5.31: Širenje virtualnog kanala na strani posrednika. Hera pristupa otvaranju Tor veze prema Hadu i prelazi u stanje EXTENDING. ** Event #235 T=10.0266169 TorSimple.Hera.Tor (OR, id=208), on `R_EXTEND' (TCPShellMsg, id=316) Hera.Tor: Tor cell recieved, cmd = 103 connID = -1 circID = 4194450 streamID = 0 from client (26255836)on TLS -1 HeraTor.VCFSM: EXTENDING to Had Hera.Tor.control: processing virtual circuit 4194450 on TLS -1 as server from client(1111) there are 1 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPEN Hera.Tor: there are 1 virtual circuits: Hera.Tor: VC INcircID = 4194450 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = EXTENDING Hera.Tor: there are 1 pending virtual circuits: Hera.Tor: peerID = 4444 VC INcircID = 4194450 INconnID = -1 OUTcircID = 17 OUTconnID = 1852401184 state = EXTENDING Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links Slika 5.32: Širenje virtualnog kanala prema prijenosnom čvoru Hadu na strani čvora stražara Here.. Nakon opisane razmjene ćelija, virtualni kanal je proširen do Hada, a s Herom dijeli identifikator virtualnog kanala 17. Oba usmjernika su u stanju OPENED. ** Event #400 T=10.0435056 TorSimple.Had.Tor (OR, id=140), on `CREATE' (TCPShellMsg, id=450) Had.Tor: Tor cell recieved, cmd = 101 connID = -1 circID = 17 from client (26255836) on TLS -1 Had.Tor.control: processing virtual circuit 17 on TLS -1 as server from Hera(6666) HadTor.VCFSM: recieved CREATE on TLS -1 HadTor.VCFSM: OPENED opened VC circID = 17 on TLS -1 there are 1 TLS links: TLS connID = -1 peer name = Hera peerID = 6666 state = OPEN Had.Tor: there are 1 virtual circuits: Had.Tor: VC INcircID = 17 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = OPENED Had.Tor: there are no pending virtual circuits Had.Tor: there are no virtual streams Had.Tor: there are no pending virtual streams Had.Tor: there are no exit TCP links ** Event #400 T=10.0435056 TorSimple.Had.Tor (OR, id=140), on `CREATE' (TCPShellMsg, id=450) Had.Tor: Tor cell recieved, cmd = 101 connID = -1 circID = 17 from client (26255836) on TLS -1 Had.Tor.control: processing virtual circuit 17 on TLS -1 as server from Hera(6666) HadTor.VCFSM: recieved CREATE on TLS -1 Slika 5.33: Virtualni kanal je proširen do prijenosnog čvora Hada. 62 5. Praktični rad HadTor.VCFSM: OPENED opened VC circID = 17 on TLS -1 there are 1 TLS links: TLS connID = -1 peer name = Hera peerID = 6666 state = OPEN Had.Tor: there are 1 virtual circuits: Had.Tor: VC INcircID = 17 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = OPENED Had.Tor: there are no pending virtual circuits Had.Tor: there are no virtual streams Had.Tor: there are no pending virtual streams Had.Tor: there are no exit TCP links ** Event #426 T=10.0483617 TorSimple.Hera.Tor (OR, id=208), on `CREATED' (TCPShellMsg, id=470) Hera.Tor: Tor cell recieved, cmd = 102 connID = 0 circID = 17 from client (26255836) on TLS 0 Hera.Tor.control: processing virtual circuit 17 on TLS 0 as client on behalf Had(4444) HeraTor.VCFSM: unforeseen TLS link state 2 HeraTor.VSFSM: CREATED recieved, OPENED VC CREATED HeraTor.VCFSM: EXTENDING - CREATED recieved, VC 17 opened, sending RELAY_EXTENDED backward to Had there are 2 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPEN TLS connID = 0 peer name = Had peerID = 4444 state = OPEN Hera.Tor: there are 2 virtual circuits: Hera.Tor: VC INcircID = 4194450 INconnID = -1 OUTcircID = 17 OUTconnID = 0 state = OPENED Hera.Tor: there are no pending virtual circuits Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links Posrednik ostaje u stanju PENDING i širi virtualni kanal prema izlaznom čvoru Posjedonu tako što prosljeđuje RELAY_EXTEND ćeliju niz kanal. ** Event #452 T=10.0528418 TorSimple.client.Tor (OP, id=11), on `R_EXTENDED' (TCPShellMsg, id=493) client.Tor.control: Tor cell recieved, cmd = 103 circID = 4194450 from on TLS 0 client.Tor.control: processing virtual circuit 4194450 with Hera(6666) client.Tor.control: path not built client.Tor.control: path built to EG client.Tor.control: next node is 22222 client.Tor.control: next node position in path is 2 for connID = 0 circID = 4194450 clientTor.VCFSM: PENDING - RELAY_EXTENDED recieved, VC 4194450 opened to MIDDLE-MAN Had sending RELAY_EXTEND towards Posejdon there are 1 TLS links: TLS connID = 0 peer name = Hera peerID = 6666 state = OPEN client.Tor: there are 1 virtual circuits: client.Tor: VC circID = 4194450 connID = 0 state = PENDING client.Tor: there are no virtual streams client.Tor: there are 1 user requests: client.Tor: reqID = 0 adress = 192.168.1.2@1000 state = PENDING_VS connID = 0 circID = 4194450 streamID = -1 path = Hera Had Posejdon current = 3 Slika 5.34: Širenje virtualnog kanala prema izlaznom čvoru Posejdonu na strani posrednika. Nakon što je virtualni kanal proširen do izlaznog čvora, posrednik prelazi u stanje OPENED i može pristupiti otvaranju virtualnog toka slanjem RELAY_BEGIN ćelije niz kanal. ** Event #747 T=10.092883 TorSimple.client.Tor (OP, id=11), on `R_EXTENDED' (TCPShellMsg, id=735) client.Tor.control: Tor cell recieved, cmd = 103 circID = 4194450 from on TLS 0 client.Tor.control: processing virtual circuit 4194450 with Hera(6666) client.Tor.control: path built clientTor.VCFSM: opened VC 4194450 opened to EXIT NODE Posejdon opening pending streams client.Tor.control: destination 192.168.1.2:1000 for connID = 0 circID = 4194450 clientTor.VCFSM: opening VS 1591784480 on VC 4194450 towards 192.168.1.2:1000 sending RELAY_BEGIN there are 1 TLS links: TLS connID = 0 peer name = Hera peerID = 6666 state = OPEN client.Tor: there are 1 virtual circuits: client.Tor: VC circID = 4194450 connID = 0 state = OPENED client.Tor: there are 1 virtual streams: client.Tor: VS streamID = 1591784480 circID = 4194450 state = PENDING client.Tor: there are 1 user requests: client.Tor: reqID = 0 adress = 192.168.1.2@1000 state = PENDING_VS connID = 0 circID = 4194450 streamID = -1 path = Hera Had Posejdon current = 3 Slika 5.35: Otvaranje virtualnog toka na strani posrednika. Nakon što je izlazni čvor Posejdon primio RELAY_BEGIN ćeliju otvara TCP vezu prema vanjskom odredištu. Po uspostavljanju veze obavještava posrednika slanjem RELAY_CONNECTED ćelije niz kanal. ** Event #825 T=10.1066993 TorSimple.Posejdon.Tor (OR, id=72), on `R_BEGIN' (TCPShellMsg, id=797) Posejdon.Tor: Tor cell recieved, cmd = 103 connID = -1 circID = 17 streamID = 1591784480 on TLS -1 PosejdonTor.VCFSM: recieved R_BEGIN connecting to 192.168.1.2:1000 PosejdonTor.VCFSM: OPENED opening TCP exit connection connID = 0 for VS streamID = 1591784480 on IN TLS = -1 circID = 17 Posejdon.Tor.control: processing virtual circuit 17 on TLS -1 as server from Had(4444) there are 1 TLS links: TLS connID = -1 peer name = Had peerID = 4444 state = OPEN Posejdon.Tor: there are 1 virtual circuits: Posejdon.Tor: VC INcircID = 17 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = OPENED Slika 5.36: Otvaranje virtualnog toka na strani izlaznog čvora. 63 5. Praktični rad Posejdon.Tor: there are no pending virtual circuits Posejdon.Tor: there are no virtual streams Posejdon.Tor: there are 1 pending virtual streams: Posejdon.Tor: VS streamID = 1591784480 INcircID = 123 OUTconnID = 1701344105 state = PENDING Posejdon.Tor: there are 1 exit TCP links: Posejdon.Tor: connID = 0 state = OPENING ** Event #862 T=10.1075155 TorSimple.Posejdon.Tor (OR, id=72), on `established' (TCPShellMsg, id=839) Posejdon.Tor: tor nodes = 5 Posejdon.Tor: TCP shell msg recieved 1 on 0 Posejdon.Tor.control:: LISTEN PosejdonTor.VSFSM: sending RELAY_CONNECTED there are 1 TLS links: TLS connID = -1 peer name = Had peerID = 4444 state = OPEN Posejdon.Tor: there are 1 virtual circuits: Posejdon.Tor: VC INcircID = 17 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = OPENED Posejdon.Tor: there are no pending virtual circuits Posejdon.Tor: there are 1 virtual streams: Posejdon.Tor: VS streamID = 1591784480 INcircID = 123 OUTconnID = 0 state = STREAMING Posejdon.Tor: there are no pending virtual streams Posejdon.Tor: there are 1 exit TCP links: Posejdon.Tor: connID = 0 state = OPEN ** Event #879 T=10.1078916 TorSimple.destination.connMgr (TCPConnectionManager, id=42), on `{peer connected}' (TCPShellMsg, id=857) destination.connMgr:-1 peer connected destination.connMgr: active connections are: 192.168.1.2:1000 <-- 192.168.1.3:1025 -1 => OPEN Kada posrednik primi RELAY_CONNECTED ćeliju počinje posluživati korisnički promet. ** Event #941 T=10.1209558 TorSimple.client.Tor (OP, id=11), on `R_CONNECTED' (TCPShellMsg, id=899) client.Tor.control: Tor cell recieved, cmd = 103 circID = 4194450 from on TLS 0 clientTor.VSFSM: recieved RELAY_CONNECTED for stream streamID = 1591784480 on circuit = 4194450 on TLS 0 client.Tor.control: attaching request 0 to VC 4194450 towards Hera there are 1 TLS links: TLS connID = 0 peer name = Hera peerID = 6666 state = OPEN client.Tor: there are 1 virtual circuits: client.Tor: VC circID = 4194450 connID = 0 state = OPENED client.Tor: there are 1 virtual streams: client.Tor: VS streamID = 1591784480 circID = 4194450 state = STREAMING client.Tor: there are 1 user requests: client.Tor: reqID = 0 adress = 192.168.1.2@1000 state = CONNECTED connID = 0 circID = 4194450 streamID = 1591784480 path = Hera Had Posejdon current = 1 ** Event #946 T=10.1209558 TorSimple.client.Tor (OP, id=11), on `SEND' (TorShellMessage, id=908) client.Tor code = 1 reqId = 0 client.Tor.control: sending RELAY_DATA on VS = 1591784480 VC = 4194450 TLS = 0 onions = 3 Slika 5.37: Virtualni tok je otvoren pa se poslužuje korisnički zahtjev. Prikazano je slanje RELAY_DATA ćelije kroz virtualni kanal. Masnim slovima označeno je simuliranje enkripcije (onions = x). ** Event #1010 T=10.1258119 TorSimple.Hera.Tor (OR, id=208), on `R_DATA' (TCPShellMsg, id=996) Hera.Tor: Tor cell recieved, cmd = 103 connID = -1 circID = 4194450 streamID = 1591784480 from client (26255836) on TLS -1 HeraTor.VCFSM: OPENED sending forward R_DATA circID = 4194450 on TLS -1 onions = 2 Hera.Tor.control: processing virtual circuit 4194450 on TLS -1 as server from client(1111) there are 2 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPEN TLS connID = 0 peer name = Had peerID = 4444 state = OPEN Hera.Tor: there are 2 virtual circuits: Hera.Tor: VC INcircID = 4194450 INconnID = -1 OUTcircID = 17 OUTconnID = 0 state = OPENED Hera.Tor: there are no pending virtual circuits Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links ** Event #1058 T=10.130292 TorSimple.Had.Tor (OR, id=140), on `R_DATA' (TCPShellMsg, id=1035) Had.Tor: Tor cell recieved, cmd = 103 connID = -1 circID = 17 streamID = 1591784480 on TLS -1 HadTor.VCFSM: OPENED sending forward R_DATA circID = 17 on TLS -1 onions = 1 Had.Tor.control: processing virtual circuit 17 on TLS -1 as server from Hera(6666) there are 2 TLS links: TLS connID = -1 peer name = Hera peerID = 6666 state = OPEN TLS connID = 0 peer name = Posejdon peerID = 22222 state = OPEN Had.Tor: there are 1 virtual circuits: Had.Tor: VC INcircID = 17 INconnID = -1 OUTcircID = 123 OUTconnID = 0 state = OPENED Had.Tor: there are no pending virtual circuits Had.Tor: there are no virtual streams Had.Tor: there are no pending virtual streams Had.Tor: there are no exit TCP links ** Event #1132 T=10.1347721 TorSimple.Posejdon.Tor (OR, id=72), on `R_DATA' (TCPShellMsg, id=1093) Posejdon.Tor: Tor cell recieved, cmd = 103 connID = -1 circID = 17 streamID = 1591784480 on TLS -1 PosejdonTor.VSFSM: received RELAY_DATA forwarding DUMMY with size of 509 closing exit connection 0 Posejdon.Tor.control: processing virtual stream 1591784480 on circuit = 17 on TLS -1 as server from Had(4444) there are 1 TLS links: TLS connID = -1 peer name = Had peerID = 4444 state = OPEN Posejdon.Tor: there are 1 virtual circuits: Posejdon.Tor: VC INcircID = 123 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = OPENED Posejdon.Tor: there are no pending virtual circuits Posejdon.Tor: there are 1 virtual streams: Slika 5.38: Slanje korisničkog prometa kroz virtualni kanal. 64 5. Praktični rad Posejdon.Tor: Posejdon.Tor: Posejdon.Tor: Posejdon.Tor: VS streamID = 1591784480 INcircID = 123 OUTconnID = 0 state = STREAMING there are no pending virtual streams there are 1 exit TCP links: connID = 0 state = OPEN U nastavku je prikazano prosljeđivanje tereta RELAY_DATA ćelije vanjskom odredištu kroz niže slojeve. ** Event #1525 T=10.1571721 TorSimple.Posejdon.tcpdump (TCPDump, id=88), on `ACK' (IPDatagram, id=1360) [10.157] 192.168.1.7.1025 < 192.168.1.3.443: A ack 2520161 win 7504 # ** Event #1526 T=10.1571721 TorSimple.Posejdon.TLS (TLSLayer, id=73), on `DUMMY' (TCPShellMsg, id=1364) Posejdon.TLS: cmd send DUMMY on 0 Posejdon.TLS: arrived on :cmdIn sent from Tor: DUMMY ** Event #1527 T=10.1571721 TorSimple.Posejdon.ppp[5].queue (DropTailQueue, id=104), on `ACK' (IPDatagram, id=1360) ** Event #1528 T=10.1571721 TorSimple.Posejdon.tcpApp (TCPSrvCliApp, id=74), on `{TCP shell: sending}' (TCPShellMsg, id=1366) Posejdon.tcpApp: sent DUMMY on 0 ** Event #1529 T=10.1571721 TorSimple.Posejdon.ppp[5].ppp (PPP, id=105), on `ACK' (IPDatagram, id=1360) Received (IPDatagram)ACK for transmission Starting transmission of (PPPFrame)ACK ** Event #1530 T=10.1571721 TorSimple.Posejdon.tcp (TCP, id=79), on `DUMMY' (cPacket, id=1368) Connection 192.168.1.3:1025 to 192.168.1.2:1000 on app[0],connId=57 in ESTABLISHED (ptr=0x0xc6ed170) App command: SEND 966 bytes in queue, plus 510 bytes unacknowledged Nagle is enabled and there's unacked data: only full segments will be sent Will send 456 bytes (effectiveWindow 2170, in buffer 456 bytes) receiveQ: receiveQLength=0 maxRcvBuffer=7504 usedRcvBuffer=0 freeRcvBuffer=7504 Sending: .1025 > .1000: [2529225..2529681) (l=456) ack 2526777 win 7504 Starting rtt measurement on seq=2529225 Staying in state: ESTABLISHED (event was: SEND) ** Event #1531 T=10.1571721 TorSimple.Posejdon.networkLayer.ip (IP, id=89), on `DUMMY(l=456,1msg)' (TCPSegment, id=1370) Routing datagram `DUMMY(l=456,1msg)' with dest=192.168.1.2: output interface is ppp1, next-hop address: <unspec> ** Event #1532 T=10.1571721 TorSimple.Posejdon.networkLayer.arp (ARP, id=90), on `DUMMY(l=456,1msg)' (IPDatagram, id=1372) Packet (IPDatagram)DUMMY(l=456,1msg) arrived from higher layer, output interface ppp1 is not broadcast, skipping ARP ** Event #1533 T=10.1571721 TorSimple.Posejdon.tcpdump (TCPDump, id=88), on `DUMMY(l=456,1msg)' (IPDatagram, id=1372) [10.157] 192.168.1.2.1000 < 192.168.1.3.1025: A 2529225:2529681(456) ack 2526777 win 7504 # ** Event #1534 T=10.1571721 TorSimple.Posejdon.ppp[1].queue (DropTailQueue, id=96), on `DUMMY(l=456,1msg)' (IPDatagram, id=1372) ** Event #1535 T=10.1574283 TorSimple.Posejdon.ppp[1].ppp (PPP, id=97), on selfmsg `pppEndTxEvent' (cMessage, id=29) Transmission finished. ** Event #1536 T=10.1574283 TorSimple.Posejdon.ppp[1].ppp (PPP, id=97), on `DUMMY(l=456,1msg)' (IPDatagram, id=1372) Received (IPDatagram)DUMMY(l=456,1msg) for transmission Starting transmission of (PPPFrame)DUMMY(l=456,1msg) ** Event #1537 T=10.1574284 TorSimple.destination.ppp[0].ppp (PPP, id=63), on `DUMMY(l=510,1msg)' (PPPFrame, id=1346) ** Event #1538 T=10.1574284 TorSimple.destination.tcpdump (TCPDump, id=56), on `DUMMY(l=510,1msg)' (IPDatagram, id=1345) [10.157] 192.168.1.2.1000 < 192.168.1.3.1025: A 2528715:2529225(510) ack 2526777 win 7504 # ** Event #1539 T=10.1574284 TorSimple.destination.networkLayer.ip (IP, id=57), on `DUMMY(l=510,1msg)' (IPDatagram, id=1345) Routing datagram `DUMMY(l=510,1msg)' with dest=192.168.1.2: local delivery ** Event #1540 T=10.1574284 TorSimple.destination.tcp (TCP, id=48), on `DUMMY(l=510,1msg)' (TCPSegment, id=1343) Connection 192.168.1.2:1000 to 192.168.1.3:1025 on app[0],connId=58 in ESTABLISHED (ptr=0x0xab79470) Seg arrived: .1025 > .1000: [2528715..2529225) (l=510) ack 2526777 win 7504 TCB: snd_una=2526777 snd_nxt=2526777 snd_max=2526777 snd_wnd=7504 rcv_nxt=2528715 rcv_wnd=7504 snd_cwnd=1072 rto=3 ssthresh=65535 receiveQ: receiveQLength=0 maxRcvBuffer=7504 usedRcvBuffer=0 freeRcvBuffer=7504 rcv_nxt changed to 2529225, sending ACK now (delayed ACKs are disabled) receiveQ: receiveQLength=0 maxRcvBuffer=7504 usedRcvBuffer=0 freeRcvBuffer=7504 Sending: .1000 > .1025: ack 2529225 win 7504 Staying in state: ESTABLISHED (no FSM event) ** Event #1541 T=10.1574284 TorSimple.destination.tcpApp (TCPSrvCliApp, id=43), on `DUMMY' (cPacket, id=1344) destination.tcpApp: msg full name= DUMMYmsg kind =1 socket regarded as open destination.tcpApp: msg full name=DUMMY, socket 58 open, processing msg in socket destination:DUMMY.thread: recieved destination.tcpApp: socket connection id = 58 socket state = 4 ** Event #1542 T=10.1574284 TorSimple.destination.networkLayer.ip (IP, id=57), on `ACK' (TCPSegment, id=1374) Routing datagram `ACK' with dest=192.168.1.3: output interface is ppp0, next-hop address: <unspec> ** Event #1543 T=10.1574284 TorSimple.destination.connMgr (TCPConnectionManager, id=42), on `DUMMY' (TCPShellMsg, id=1376) destination.connMgr:recieved DUMMY(509 B ) on -1 destination.connMgr: active connections are: 192.168.1.2:1000 <-- 192.168.1.3:1025 -1 => OPEN Slika 5.39: Slanje korisničkog prometa prema vanjskom odredištu. Naposljetku, posrednik zatvara virtualni tok i kanal tako što šalje RELAY_END i DESTROY ćelije 65 5. Praktični rad niz kanal. Svi opisnici se uništavaju, a sve veze se zatvaraju. ** Event #1576 T=110 TorSimple.client.Tor (OP, id=11), on `CLOSE' (TorShellMessage, id=146) client.Tor code = 2 reqId = 0 client.Tor.control: closing stream 1876958201 on circuit = 4194450 on TLS 0 ** Event #1602 T=110.0044801 TorSimple.Had.Tor (OR, id=140), on `R_END' (TCPShellMsg, id=1415) Hera.Tor: Tor cell recieved, cmd = 103 connID = -1 circID = 4194450 streamID = 1591784480 from client (1111) TLS -1 Hera.Tor.VCFSM: OPENED sending forward R_END circID = 4194450 on TLS -1 onions = 2 Hera.Tor.control: processing virtual circuit 4194450 on TLS -1 as server from client(1111) there are 2 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPEN TLS connID = 0 peer name = Hera peerID = 4444 state = OPEN Hera.Tor: there are 2 virtual circuits: Hera.Tor: VC INcircID = 4194450 INconnID = -1 OUTcircID = 17 OUTconnID = 0 state = OPENED Hera.Tor: there are no pending virtual circuits Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links ** Event #1628 T=110.0089601 TorSimple.Had.Tor (OR, id=140), on `DESTROY' (TCPShellMsg, id=1434) Hera.Tor: Tor cell recieved, cmd = 104 connID = -1 circID = 4194450 from client (1111) on TLS -1 Hera.Tor.control: processing virtual circuit 4194450 on TLS -1 as server from client(1111) there are 2 TLS links: TLS connID = -1 peer name = client peerID = 1111 state = OPEN TLS connID = 0 peer name = Had peerID = 4444 state = OPEN Hera.Tor: there are no virtual circuits Hera.Tor: there are no pending virtual circuits Hera.Tor: there are no virtual streams Hera.Tor: there are no pending virtual streams Hera.Tor: there are no exit TCP links on Slika 5.40: Zatvaranje virtualnog toka i virtualnog kanala sa strane posrednika. ** Event #1701 T=110.0134403 TorSimple.Posejdon.Tor (OR, id=72), on `R_END' (TCPShellMsg, id=1487) Posejdon.Tor: Tor cell recieved, cmd = 103 connID = -1 circID = 123 streamID = 1591784480 from client (25534940) on TLS -1 PosejdonTor.VSFSM: received RELAY_END closing exit connection 0 Posejdon.Tor.control: processing virtual stream 1591784480 on circuit = 123 on TLS -1 as server from Hera(6666) there are 1 TLS links: TLS connID = -1 peer name = Hera peerID = 6666 state = OPEN Posejdon.Tor: there are 1 virtual circuits: Posejdon.Tor: VC INcircID = 123 INconnID = -1 OUTcircID = 1701344105 OUTconnID = 1852401184 state = OPENED Posejdon.Tor: there are no pending virtual circuits Posejdon.Tor: there are no virtual streams Posejdon.Tor: there are no pending virtual streams Posejdon.Tor: there are no exit TCP links ** Event #1730 T=110.0138164 TorSimple.destination.connMgr (TCPConnectionManager, id=42), on `{TCPShellMsg peer closed}' (TCPShellMsg, id=1506) destination.connMgr:-1 broke destination.connMgr: active connections are: 192.168.1.2:1000 <-- 192.168.1.3:1025 -1 => OPEN ** Event #1773 T=110.0179203 TorSimple.Posejdon.Tor (OR, id=72), on `DESTROY' (TCPShellMsg, id=1523) Posejdon.Tor: tor nodes = 5 Posejdon.Tor: Tor cell recieved, cmd = 104 connID = -1 circID = 123 from client (25534940) on TLS -1 Posejdon.Tor.control:: LISTEN Posejdon.Tor.control: processing virtual circuit 1527154887 on TLS -1 as server from Hera(6666) there are 1 TLS links: TLS connID = -1 peer name = Hera peerID = 6666 state = OPEN Posejdon.Tor: there are no virtual circuits Posejdon.Tor: there are no pending virtual circuits Posejdon.Tor: there are no virtual streams Posejdon.Tor: there are no pending virtual streams Posejdon.Tor: there are no exit TCP links Slika 5.41: Zatvaranje virtualnog toka i virtualnog kanala sa strane odredišta. 66 6. Zaključak Anonimna komunikacija vrlo je mlado područje čiji se početak računa od 1981. godine [29]. Prva anonimna mreža s visokim kašnjenjem postavljena sredinom devedesetih, dok je prva anonimna mreža s niskim kašnjenjem postavljena početkom 21. stoljeća, stoga još uvijek postoje mnoga otvorena pitanja. Svrha praktičnog dijela rada jest da bude razvojna platforma za projektiranje reputacijskog sustava kojim bi se otežala zlouporaba Tor mreže. Simulacije moraju biti realistične da bi bile upotrebljive u istraživanjima [44], a takav simulator još nije napisan [43]. Da bi se simulator ponašao dovoljno slično kao stvarni sustav potrebno je najprije ostvariti svu (dokumentiranu) funkcionalnost protokola koja utječe na generiranje tj. oblik prometa. Tada će se izvršiti mjerenje kašnjenja simulacijskih elemenata po slojevima na stvarnom sustavu te s tim vrijednostima pokrenuti simulaciju i izmjeriti odstupanja. Proces se iterira sve dok se ne postigne zadovoljavajuća točnost. Projekt se radi u suradnji sa Tor zajednicom [43], a predviđeno vrijeme trajanja je godina dana. U uvodu su navedeni okvirni pokazatelji koji jasno ukazuju na pokušaje kontrole nad Mrežom, što može rezultirati teškim narušavanjem slobode govora (slobode izražavanja, informacijske slobode). U praksi se pokazalo kako je najgori slučaj zlouporabe anonimne mreže distribucija pedofilskih materijala. Isto tako se, međutim, pokazalo da pružatelji mrežnih usluga dobrim dijelom samovoljno cenzuriraju nepoćudna mrežna odredišta lažno se opravdavajući upravo onemogućavanjem distribucije pedofilskih materijala. Još je Inkvizicija pokazala koliko je taktika "lova na vještice" učinkovita, stoga se ovaj argument uporno (i dijelom opravdano) koristi pri diskreditaciji bilo kojeg anonimnog sustava počevši i od prvog anonimnog pošiljaoca pošte [38]. Kategorički službeni stav Tor projekta je kako se u protokol neće ugrađivati nikakve mjere koje ograničavaju informacijsku slobodu. Drugim riječima, Tor ostvaruje informacijsku slobodu. Bitno je primjetiti kako sloboda, kao što znači slobodu zlouporabe, jednako tako znači i slobodu borbe protiv zlouporabe. Najbolji dokaz za to je skrivena usluga torpedo.org koja unatoč imenu nema nikakve veze sa Tor projektom. Usluga je Web aplikacija koja slijedno pretražuje registar skrivenih usluga (engl. crawler) te ih prikazuje korisnicima koji ih klasificiraju kao (ne)pedofilski materijal. Označene slike pregledavaju administratori stranice te ih prijavljuju administratorima mreže koji potom poduzimaju odgovarajuće korake. Ovo rješava samo dio problema distribucije pedofilskih materijala. Opaske o anonimnosti u virtualnom društvenom kontekstu, anonimnosti u (virtualnom) društvenopolitičkom kontekstu te pravnom modelu prijetnje dane su u dodatku E. 67 7. Popis kratica • politika, birokracija i organizacije EFF – engl. Electronic frontier foundation GPL – engl. general public license GSOSRH - Glavni stožer obrambenih snaga Republike Hrvatske IRS – engl. Internal revenue service ISTAR – engl. intelligence, surveillance, target acquisition, and reconnaissance MIT – engl. Massachusetts institute of technology MPAA – engl. Motion picture association of America NSA – engl. National security agency RIAA – engl. Recording industry association of America SAD - Sjedinjene američke države SEI – Središnjica elektroničkog izviđanja • protokoli, aplikacije i algoritmi AES – engl. advanced encryption standard AOL – engl. America Online BGP – engl. border gateway protocol DC – engl. dining cryptographers (D)DoS – engl. (distributed) denial of service DNS – engl. domain name system FTP – engl. file transfer protocol FQDN – engl. fully qualified domain name GSM – engl. global system for mobile communications, fr. groupe spécial mobile HTTP – engl. hyper text transfer protocol ICQ – engl. I seek you IP – engl. Internet protocol ISDN – engl.integrated services digital network ISP – engl. Internet service provider MAC – engl. media access control MAN – engl. metropolitan area network MBTF – engl. mean time before failure MSNP – engl. microsoft notification protocol a.k.a mobile status notification protocol NTP – engl. network time protocol NYM – engl. pseudonym OSI – engl. open systems interconnection RSA – engl. Rivest, Shamir and Adelman RTT – engl. round-trip time SHA – engl. secure hash algorithm SILC – engl. secure Internet live video conferencing (S)IRC – engl. (secure) Internet relay chat 68 7. Popis kratica SSH – engl. secure shell (S)XMPP – engl. (secure) extensible messaging and presence protocol TCP – engl. transmission control protocol TLS – engl. transport layer security Tor – engl. the onion routing UDP – engl. user datagram protocol UML – engl. unified modelling language URL – engl. uniform resource locator WAN – engl. wide area network (W)LAN – engl. (wireless) local area network • Tor protokol CDW – engl. circuit delivery window CPW – engl. circuit packaging window DA – engl. directory authority DS – engl. directory service EG – engl. entry guard EN – engl. exit node HS – engl. hidden service ID – engl. identity IP – engl. introduction point ON – engl. onion OP – engl. onion proxy OR – engl. onion router PK – engl. public key RN – engl. relay node RP – engl. rendezvous point SDW – engl. stream delivery window sgn – engl. signed SK – engl. secret key SPW – engl. stream packaging window VN – engl. valet node 69 8. Literatura 1. W. R. Stevens: UNIX network programming, Prentice Hall, Englewood Cliffs, NJ 07632, 1990. 2. A. S. Tanenbaum: Računarske mreže, Mikro knjiga, prevod 4. izdanja (Smiljanić, D.), Beograd 2005. 3. I. N. Bronštejn i suradnici: Matematički priručnik, Golden marketing – Tehnička knjiga, Zagreb, 2004. 4. M. Kiš: Informatički rječnik, Naklada Ljevak, Zagreb, 2000. 5. B. A. Klaić: Rječnik stranih riječi, Nakladni zavod Matice hrvatske, Zagreb 1982. 6. Tor projekt, Tor protocol specification, http://gitweb.torproject.org/tor.git? a=blob_plain;hb=HEAD;f=doc/spec/tor-spec.txt, 2/5/2010 7. Tor projekt, Tor directory protocol specification, http://gitweb.torproject.org/tor.git? a=blob_plain;hb=HEAD;f=doc/spec/dir-spec.txt, 2/5/2010 8. Tor projekt, Tor Rendezvous Specification, http://gitweb.torproject.org/tor.git? a=blob_plain;hb=HEAD;f=doc/spec/rend-spec.txt, 2/5/2010 9. Tor projekt, Tor Path Specification, http://gitweb.torproject.org/tor.git? a=blob_plain;hb=HEAD;f=doc/spec/path-spec.txt, 2/5/2010 10. Tor projekt, Special Hostnames in Tor, http://gitweb.torproject.org/tor.git? a=blob_plain;hb=HEAD;f=doc/spec/address-spec.txt, 2/5/2010 11. Tor projekt, Tor control protocol specification, http://gitweb.torproject.org/tor.git? a=blob_plain;hb=HEAD;f=doc/spec/control-spec.txt, 2/5/2010 12. Dingledine, R., Mathewson N., Syverson P., Tor: The second generation onion router, In the Proceedings of the 13th USENIX Security Symposium, August 2004. 13. Øverlier, L., Syverson, P., Locating hidden servers, In the Proceedings of the 2006 IEEE Symposium on Security and Privacy, May 2006. 14. Øverlier, L., Syverson, P., Valet Services: improving hidden servers with a personal touch, in the proceedings of the sixth workshop on privacy enhancing technologies (PET 2006), Cambridge, UK, June 2006, pages 223-244. 15. O'Gorman, G., Blott, S., Large scale simulation of Tor: Modelling a global passive adversary, In the Proceedings of the 13th conference on USENIX Security Symposium - Volume 13, San Diego, CA pages: 21 - 23 16. Goldberg, I., On the security of the Tor authentication protocol, In the Proceedings of the Sixth Workshop on Privacy Enhancing Technologies (PET 2006), Cambridge, UK, June 2006, pages 316-331. 17. Ngan, T., Dingledine, R., Wallach, D.,S., Building Incentives into Tor, In the Proceedings of Financial Cryptography (FC '10), January 2010. 18. Feigenbaum, J., Johnson, A., Syverson, P., Probabilistic analisys of onion routing in a black box model, WPES'07: Proceedings of the 2007 ACM Workshop on Privacy in Electronic Society, ACM Press, October 2007, pages: 1-10. 19. Danezis, G., Diaz, C., Syverson, P., Systems for anonymous communications, In CRC Handbook of Financial Cryptography and Security, CRC Cryptography and Network Security Series, B. Rosenberg, and D. Stinson (Eds.), Chapman & Hall, 61 pages, 2010 20. Pfitzmann, A., Hansen, M., A terminology for talking about privacy by data minimization: anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management, http://dud.inf.tu-dresden.de/Anon_Terminology.shtml, 2/4/2010. 21. Edman, M., Sivrikaya, F., Yener, B., A combinatorial approach to measuring anonimity, In Intelligence and Security Informatics, IEEE, May 2007, pages 356-363. 70 8. Literatura 22. Diaz, C., Seys, S., Claessens, J., Preneel, B., Towards measuring anonimity, In the Proceedings of Privacy Enhancing Technologies Workshop (PET 2002), April 2002. 23. Serjantov, A., Danezis, G., Towards an information theoretic metric for anonimity, In the Proceedings of Privacy Enhancing Technologies Workshop (PET 2002), April 2002. 24. Newman, R., E., Moskowitz, I., S., Syveron, P., Serjantov, A., Metrics for traffic analisys prevention, n the Proceedings of Privacy Enhancing Technologies workshop (PET 2003), March 2003, pages 48-65. 25. Borisov, N., Waddle, J., Anonimity in structured peer-to-peer networks, Ph.D. Qualifying Exam Proposal, 2004., gnunet.org/papers/borisov_waddle.pdf, 20/4/2010 26. Danezis, G., Statistical disclosure attacks: traffic confirmation in open environments, In the Proceedings of Security and Privacy in the Age of Uncertainty, (SEC2003), Athens, May 2003, pages 421-426. 27. Kedogan, D., Agrawal, D., Penz, S., Limits of anonymity in open environments, In the Proceedings of Information Hiding Workshop (IH 2002), October 2002. 28. Kelly, D.: A taxonomy for and analysis of anonymous communication networks, dissertation, Air force institute of technology, Wright-Patterson Air Force Base, Ohio, March 2009. 29. Chaum D., L., Untraceable electronic mail, return addresses, and digital pseudonyms, In Communications of the ACM 24(2), February 1981. 30. OMNeT++, korisnički priručnik, http://www.omnetpp.org/doc/omnetpp33/manual/usman.html 31. Status Tor mreže, http://torstatus.blutmagie.de/, http://torstatus.cyberphunk.org/, http://all.de ... 32. Wright, J., Stepney, S., Clark, J.A., Jacob J., Designing Anonymity: A Formal Basis for Identity Hiding, unpublished dissertation, University of York. February, 2005. 33. Chaum D., L., The dining cryptographers problem: Unconditional sender and recipient untraceability, http://www.cs.cornell.edu/People/egs/herbivore/dcnets.html 34. alpha.c2.org, anonimni pošiljaoc pošte tipa 0, http://www.iusmentis.com/technology/remailers/index-alpha.html 35. Analiza prometa, http://en.wikipedia.org/wiki/Traffic_analysis 36. OSRH SEI, http://hr.wikipedia.org/wiki/Središnjica_elektroničkog_izviđanja 37. Cenzura na Internetu, http://en.wikipedia.org/wiki/Internet_censorship 38. anon.penet.fi, anonimni pošiljaoc pošte tipa 0, http://en.wikipedia.org/wiki/Penet_remailer 39. operacija Payback, http://www.bbc.co.uk/news/technology-11371315 40. Hacktivismo, http://en.wikipedia.org/wiki/Hacktivismo 41. Kriptoanarhizam, http://en.wikipedia.org/wiki/Crypto-anarchism 42. Legija anonimnih, http://en.wikipedia.org/wiki/Anonymous_(group) , http://www.youtube.com/watch?v=AmzHXxeNwU4 43. razvoj Tor protokola, http://www.torproject.org/volunteer.html.en 44. prepiska elektronskom poštom, Mathewson N. 45. Tor, http://en.wikipedia.org/wiki/Tor_(anonymity_network) 46. IRS i Scijentološka crkva, http://www.lisamcpherson.org/irs/jeff-irs.htm 47. Reporteri bez granica, http://en.rsf.org/ 71 Dodatak A: Gramatike dokumenata stanja Svaki dokument stanja definiran je gramatikom kao na slici 5.1. Slika 5.1: BNF gramatika dokumenta stanja. NL - ASCII LF (0x0a, 10) Document ::= (Item | NL)+ Item ::= KeywordLine Object* KeywordLine ::= Keyword NL | Keyword WS ArgumentChar+ NL Keyword = KeywordChar+ KeywordChar ::= 'A'...'Z' | 'a'...'z' | '0'...'9' | '-' ArgumentChar ::= bilo koji ASCII znak koji se može ispisati osim NL WS = (SP | TAB)+ Object ::= BeginLine Base-64-kodirani-podaci EndLine BeginLine ::= "-----BEGIN " Keyword "-----" NL EndLine ::= "-----END " Keyword "-----" NL //za BeginLine i EndLine Keyword mora biti isti Konsenzus ili registar stanja mreže definiran je gramatikom na slici 5.2. Slika 5.2: Gramatika konsenzusa ili registra stanja mreže. "network-status-version" SP version NL {1} "vote-status" SP {"vote","consensus"} NL {1} "consensus-methods" SP IntegerList NL {"consensus" – 0, "vote" -1} "consensus-method" SP Integer NL {"vote" -0,"consensus" – 1} "published" SP YYYY-MM-DD SP HH:MM:SS NL {"consensus" – 0, "vote" -1} "valid-after" SP YYYY-MM-DD SP HH:MM:SS NL {1} "fresh-until" SP YYYY-MM-DD SP HH:MM:SS NL {1} "valid-until" SP YYYY-MM-DD SP HH:MM:SS NL {1} "voting-delay" SP VoteSeconds SP DistSeconds NL {1} "client-versions" SP VersionList NL {0,1} "server-versions" SP VersionList NL {0,1} "known-flags" SP FlagList NL {1} "params" SP [Parameters] NL {0,1} //opcionalno, parovi ključ vrijednost "dir-source" SP nickname SP identity SP address SP IP SP dirport SP orport NL {1} "contact" SP string NL {0,1} "legacy-key" SP FINGERPRINT NL {0,1} //otisak netom isteklog ključa //ako je riječ o konsenzusu slijedi popis glasača, a dolje je opis jednog glasa "dir-source" SP nickname SP identity SP address SP IP SP dirport SP orport NL {1} "contact" SP string NL {0,1} "vote-digest" SP digest NL {1} ... // informacije o usmjernicima // potpis čitavog dokumenta "directory-signature" SP identity SP signing-key-digest NL Signature {1} Usmjernik u konsenzusu stanja mreže definiran je gramatikom na slici 5.3 i opisnikom na slici 5.4. Slika 5.3: Informacija o usmjerniku u konsenzusu stanja mreže. "r" SP nickname SP id SP digest SP publication SP IP SP ORPort SP DirPort NL "s" SP Flags NL {0,1} "v" SP version NL {0,1} {1} Slika 5.4: Gramatika opisnika usmjernika "router" nickname address ORPort SOCKSPort DirPort NL {1} "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL {1} "platform" string NL {0,1} "published" YYYY-MM-DD HH:MM:SS NL [{1} "fingerprint" fingerprint NL {0,1} // sažetak javnog ključa identiteta "hibernating" bool NL {0,1} "uptime" number NL {0,1} "onion-key" NL javni ključ u PEM formatu {1} "signing-key" NL javni ključ u PEM formatu {1} "reject" exitpattern NL {0,1} "accept" exitpattern NL {0,1} "router-signature" NL Signature NL {1} "contact" info NL {0,1} "family" names NL {0,1} "read-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL {0,1} "write-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL {0,1} "eventdns" bool NL {0,1} "caches-extra-info" NL {0,1} "extra-info-digest" digest NL {0,1} "hidden-service-dir" *(SP VersionNum) NL {0,1} "protocols" SP "Link" SP LINK-VER-LIST SP "Circuit" SP CIRC-VERSION-LIST NL {0,1} "allow-single-hop-exits" {0,1} Na slici 5.5. prikazana je gramatika koja definira dokument s dodatnim informacijama. 72 Dodatak A: Gramatike dokumenata stanja Slika 5.5.: Dokument s dodatnim informacijama "extra-info" Nickname Fingerprint NL {1} "published" {1} "read-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL "write-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL // ovaj dio bi TREBALI generirati isključivo usmjernici mostovi "geoip-start" YYYY-MM-DD HH:MM:SS NL "geoip-client-origins" CC=N,CC=N,... NL "router-signature" NL Signature NL {1} 73 {0,1} {0,1} Dodatak B: Protokolne podatkovne jedinice Protokolne podatkovne jedinice u Tor-u nazivaju se ćelijama. Veličina ćelija je kod anonimnih sustava fiksna, kako bi se otežala analiza prometa. Veličina ćelije je 512 okteta. Svaka se ćelija sastoji od identifikatora virtualnog kanala, naredbe i tereta. Slika 1: format protokolne podatkovne jedinice, tj. ćelije Sve ćelije protokola su iste veličine, osim VERSIONS ćelije. Slika 2: format VERSIONS ćelije, duljina je cijeli broj u big-endian notaciji Obzirom na oktet koji definira naredbu, ćelije možemo prirodnije podijeliti na upravljačke i prijenosne. Tablica 1: upravljačke ćelije oktet naredba opis teret 0 PADDING Održavanje veze na životu - 1 CREATE Zahtjev za stvaranjem kanala 2 CREATED Potvrda stvorenog kanala DiffieHellmanovo rukovanje za simetrični ključ kriptiranja podatkovnog toka veze 3 RELAY Prijenos podataka Prijenosni teret 4 DESTROY Zatvaranje kanala Oktet koji definira razlog zatvaranja uz opcionalne dodatne podatke 5 CREATE_FAST Zahtjev za brzim stvaranjem kanala 6 CREATED_FAST Potvrda brzo stvorenog kanala Dijelovi simetričnog ključa za kriptiranje podatkovnog toka veze 7 VERSIONS Odabir zajedničke verzije protokola Popis svih podržanih verzija protokola izvorišta 8 NET_INFO Topološke informacije IP adresa izvorišta i primjećene IP adrese odredišta Ćelija PADDING služi za ostvaruje održavanja veze na životu, međutim može se koristiti i za ispunu veze kako bi se otežala analiza prometa globalnom pasivnom napadaču. Međutim, još uvijek ne postoji učinkovita strategija ispune veze. Pomoću topoloških podataka u teretu NET_INFO ćelije onemogućava se varijanta čovjek-u-sredini napada. Upravljačke ćelije služe za stvaranje i zatvaranje duljine jednog čvora te razmjenu metainformacija potrebnih za (siguran) rad. Ćelije PADDING, DESTROY, RELAY, VERSIONS i NET_INFO su dvosmjerne, dok se ćelije CREATE(_FAST) šalju isključivo prema odredištu, a CREATED(_FAST) isključivo prema izvorištu. 74 Dodatak B: Protokolne podatkovne jedinice Virtualni kanal može biti uništen ili srezan na zahtjev Tor posrednika, ili može biti uništen ili srezan zbog događaja na vezama koje ga tvore. Ovaj razlog propagira se u oba smjera ako je to moguće, u teretu ćelije DESTROY i/ili RELAY_TRUNCATED. Tablica 2: razlozi za prekid virtualnog kanala oktet razlog opis 0 NONE Starije verzije protokola nisu koristile razloge 1 PROTOCOL prekršenje protkola 2 INTERNAL Unutarnja greška 3 REQUESTED Klijent zahtijeva rezanje ili zatvaranje kanala 4 HIBERNATING Tor usmjernik je u stanju hibernacije 5 RESOURCELIMIT Premašeni su resursi (memorija,utičnice,identifikatori virtualnih kanala) 6 CONNECTFAILED Nemoguće je dobiti odgovor od poslužitelja 7 OR_IDENTITY Veza je uspješno uspostavljena, međutim identitet Tor usmjernika ne odgovara očekivanom 8 OR_CONN_CLOSED TLS kanal koji je nosio ovaj virtualni kanal je zatvoren 9 FINISHED Virtualni kanal se zatvara jer je star ili preopterećen 10 TIMEOUT Stvaranje virtualnog kanala traje predugo 11 DESTROYED Kanal se reže ili uništava zbog greške na vezi na putu 12 NOSUCHSERVICE Nepostojeća skrivena usluga Upravljačka ćelija RELAY u svom teretu zasebnim oktetom definira nove upravljačke i prijenosne vrste ćelija. Upravljačke ćelije služe za širenje i rezanje virtualnih kanala te upravljanje zakrčenjem. Prijenosne ćelije služe za otvaranje i zatvaranje anonimiziranih veza (u terminologiji Tor mreže tokova), prijenos korisničkih podataka te (R)DNS razrješavanje. Tablica 3: prijenosne ćelije,O-prema odredištu, I-prema izvorištu, U-upravljanje, svaka naredba ima prefiks RELAY_ oktet naredba smjer opis teret 1 BEGIN O Zahtjev za otvaranjem toka, odnosno URL vanjskog odredišta uspostavljanjem anonimiziranog TCP kanala 13 BEGIN_DIR O Zahtjev za otvaranjem toka dokumentima stanja mreže 4 CONNECTED I Tok je uspješno otvoren IP adresa odredišta 3 END OI Tok je zatvoren Razlog zatvaranja 2 DATA OI Prijenos podataka na anonimiziranom TCP Korisnički promet kanalu 11 RESOLVE O Zahtjev za (R)DNS razrješavanjem DNS domena ili 12 RESOLVED I Uspješno (R)DNS razrješavanje IP adresa 6 EXTEND O,U Zahtjev za širenjem virtualnog kanala Identifikator čvora i RSA kriptirana CREATE ćelija 7 EXTENDED I,U Kanal je uspješno proširen Identifikator čvora i RSA kriptirana CREATED ćelija 8 TRUNCATE O,U Zahtjev za rezanjem kanala Identifikator čvora i razlog rezanja 75 za promet URL dokumenta Dodatak B: Protokolne podatkovne jedinice 9 TRUNCATED 5 SENDME 10 DROP Kanal je srezan Identifikator čvora i razlog rezanja OI,U Upravljanje zakrčenjem - OI,U Ispuna veze (nije ostvareno) - I,U 32..40 Koriste se za skrivene usluge koje su obrađene u posebnom poglavlju Ćelija RELAY_BEGIN_DIR tretira se kao da je primljena ćelija RELAY_BEGIN s odredištem koje je IP adresa odredišnog Tor usmjernika i pristupnih vratiju za promet dokumentima stanja. Slika 3: prijenosni teret, odnosno teret upravljačke RELAY ćelije Upravljačke ćelije imaju nultu vrijednost identifikatora toka, jer utječu na cijeli virtualni kanal. Jedina iznimka su RELAY_SENDME ćelije – kada imaju postavljen identifikator toka služe za kontrolu zakrčenja toka, a inače virtualnog kanala. Sažetak služi za očuvanje integriteta podatkovnog toka. Prepoznato se uvijek postavlja na nulu kako bi se moglo prepoznati kada je ćelija dekriptirana. Duljina označava duljinu korisničkog tereta, dok se ostatak nadopunjuje nulama. Ako je moguće, uvijek se prije zatvaranja virtualnih kanala zatvaraju svi tokovi na njemu. Razlog zatvaranja toka šalje se u teretu RELAY_END ćelije uz opcionalne dodatne podatke. Tablica 4: razlozi za prekid toka, svaki razlog ima prefiks REASON_ oktet razlog opis 1 MISC svi nenavedeni razlozi 2 RESOLVEFAILED nije moguće razriješiti adresu ili domenu 3 CONNECTREFUSED vanjsko odredište odbilo se povezati 4 EXITPOLICY izlazna politika Tor usmjernika na poziciji izlaznog čvora ne dopušta spajanje na traženo vanjsko odredište 5 DESTROY Virtualni kanal se zatvara 6 DONE anonimizirana TCP veza je zatvorena 7 TIMEOUT Stvaranje virtualnog kanala traje predugo, ili je veza predugo bez prometa 9 HIBERNATING Tor usmjernik prelazi u stanje hibernacije 10 INTERNAL Unutarnja greška 11 RESOURCELIMIT premašeni su resursi odredišnog Tor usmjernika 12 CONNRESET Veza je neočekivano prekinuta pa uspostavljena 13 TORPROTOCOL prekršenje protkola 14 NOTDIRECTORY Odredišni Tor usmjernika nije (pred)poslužitelja registara Vrijednost osam okteta za definiranje razloga za za zatvaranje toka mora ostati nealocirana dok neke starije verzije (do verzije 0095) ne izađu iz upotrebe. U tablici su označeni razlozi za zatvaranje toka koji su ujedno i razlozi za zatvaranje virtualnog kanala. 76 Dodatak C: Metrike anonimnosti Iako postoje razne formalizacije, a pitanje vrednovanja anonimnosti je otvoren i o domeni jako ovisan problem, osnovna definicija anonimnosti krajnje je intuitivna. Ako se pretpostavi da moramo identificirati neki element skupa od pet članova, jednostavnim slijednim pretraživanjem brzo obavljamo zadatak. S druge strane, ako taj skup broji pet milijuna elemenata, zadatak ćemo puno sporije i teže obaviti. Anonimnost (pojedinog elementa) skupa ovisi o njegovom kardinalnom broju – što je više elemenata u skupu to je lakše sakriti nekog od njih među svim ostalima, odnosno teže je identificirati jednog od njih među svima. Anonimost pojedinog elementa skupa, osim o kardinalnom broju skupa, ovisi i o razlici značajki tog elementa prema značajkama ostalih elemenata skupa, tj. o jednolikosti elemenata skupa, stoga je jasno da gornji pristup ne zadovoljava u potpunosti, kao i da formalne interpretacije anonimnosti mogu biti vrlo šarolike. Naravno, kvantifikacija anonimnosti ovisi i o modelu napadača. Formalizacija anonimnosti podrazumijeva zadani model sustava i napadača te metrike anonimnosti. Na taj način pruža se ocjena kvalitete usluge sustava. Anonimnost se također može tumačiti u širem kontekstu kao skrivanje informacija. Prva ocjena sustava temeljena je na kardinalnoj metrici d ∝ ∣S∣ [19]. Ovo je gruba ocjena i nije dovoljna. Drugi tip metrike anonimnosti temelji se na entropiji d ∝ −∑ p log p . Ovakav s ∈S pristup mjeri anonimnost u odnosu na zadani entitet: ako je p vjerojatnost da je pošiljatelj s poslao poruku, tada je d stupanj anonimnosti primatelja [23] [24]. Treći tip metrike anonimnosti također se temelji na entropiji, ali koristi i matrice prometa kako bi mogla procijeniti otpornost cijelog sustava na napad analizom prometa. Daje osnovnu ocjenu prometne politike u smislu otpornosti na analizu prometa te najbolju prometnu politiku po toj metrici [22]. Četvrti tip metrike anonimnosti temelji se na kombinatorici i također mjeri anonimnost cijelog sustava [21]. Promet kroz sustav predstavlja se bipartitnim grafom, čiji su čvorovi ulazna i izlazna vremena poruka. Graf je predstavljen matricom susjedstva A . Određivanjem bridova, odnosno odnosa između ulaza i izlaza definiran je promet. Ovaj problem u teoriji grafova poznat je kao savršena slaganja, a njihov broj za zadani skup čvorova ekvivalentan je izračunavanju permanenta i=n matrice susjedstva grafa perm A=∑ ∏ Ai , i . Sumacija se vrši po svim permutacijama i=1 log perm A , n1 . Ako logn! postoje samo dva čvora, tj. samo jedno savršeno slaganje sustav nije anoniman ( n=1, d A=0 ) dok je za maksimalnu anonimnost ( d A=1 ) odgovarajući graf sustava potpuni bipartitni graf. Zbog velike računalne snage potrebne za njeno izračunavanje, ovako izražena, ova metrika nije praktična. Upotrebom modificirane Monte Carlo metode, najbolje poznato asimptotsko vrijeme izvođenja je polinomijalno O n7 log 4 n . Za velike sustave to ipak nije dovoljno dobro. parova čvorova. Stupanj anonimnosti definiran je kao: d A= Navedene metrike su stohastičkog karaktera, a između ostalih, postoje i metrike temeljene na modalnoj, epistemičkoj i temporalnoj logici te višeagentskim sustavima, kao i kombinacije logičkog i stohastičkog okvira rasuđivanja [28]. 77 Dodatak D: Analiza anonimnosti virtualnog kanala Kako bi se pobliže ispitala hijerarhija anonimnosti virtualnog kanala, odnosno funkcionalna zavisnost anonimnosti o duljini virtualnog kanala tj. puta, uvode se događaji odabiranja odnosno napada na jedan ili dva čvora: deanonimiziranje kanala kompromitacijom jednog čvora CONN , 1 EDGE polovično deanonimiziranje kanala kompromitacijom jednog čvora 1 , kompromitranje posrednog čvora 1 , deanonimiziranje kanala kompromitacijom dva čvora CONN te 2 EDGE polovično deanonimiziranje kanala kompromitacijom dva čvora 2 . Odabiri jednog i dvaju čvorova tvore zasebne, potpune skupove elementarnih događaja. Napadač je lokalan, jer se promatra se samo kanal, unutarnji odnosno aktivni jer kompromitira čvorove i dinamički, jer koristi dobiveno znanje za deanonimiziranje korisnika. Tablica 1: hijerarhija anonimnosti puta u ovisnosti o količini posrednih čvorova i snazi napada logička duljina puta 2 3 4 5 6 7 8 9 10 11 i+2 snaga napada p(wi) 0 1 2 3 4 5 6 7 8 9 broj posrednika ( i ) na putu 0 0 0 0 CONN x 1 0 0 0 0 0 EDGE x 0 1 2 3 2 4 2 5 2 6 2 7 2 8 2 9 2 , i1 i p 1 x 0 0 1 3 2 4 3 5 4 6 5 7 6 8 7 9 i−2 ,i1 i p CONN 2 x x 1 1 3 1 6 1 10 1 15 1 21 1 28 1 36 i , i2 2 p EDGE 2 x x 0 2 3 4 6 6 10 8 15 10 21 12 28 14 36 2 i−2 i ,i2 2 p 2 x x 0 0 1 6 3 10 6 15 10 21 12 28 14 36 1− p 2 − p 2 i2 p 1 p 1 −1 −1 C E Što je više čvorova u kanalu tim je vjerojatnije da je više čvorova potrebno kompromitirati kako bi se kanal deanonimizirao. Udaljenost prijenosnog čvora od najbližeg krajnjeg čvora vrednuje njegovo neznanje o identitetima krajnjih čvorova. Duljina kanala implicira dodatnu semantiku odnosno kvalitetu isporučene anonimnosti puta, obzirom na raspodjelu znanja o sudionicima komunikacije, a koju izravno uvjetuje upravo duljina puta. Tek od kanala sa sedam posrednih čvorova broj povoljnih i nepovoljnih odabira čvorova postaje približno jednak. U praksi dodavanje čvorova znači dodatno kašnjenje. U Toru, brzi kanali za surfanje standardno imaju tri čvora (dovoljno je da postoji jedan čvor koji ne zna za krajnje čvorove) dok spori kanali za skrivene usluge standardno imaju sedam čvorova. Kod skrivenih /anonimnih mrežnih usluga, kao što im i samo ime kaže, bitna je visoka anonimnost primatelja. 78 Dodatak E: Definicije i opaske U ovom potpoglavlju razmotrit će se pojmovi identiteta, neuočljivosti i anonimnosti te njihove komponente i međusobni odnosi, nakon čega slijede opaske. Osim toga izložit će se i povijesni razvoj definicija anonimnosti, odnosno klasične i kubične definicije [28]. Uvode se kratice za prethodno definirane pojmove: anonimnost – ANON, nepovezivost – UNLN, nemogućnost identificiranja – UNID, anonimnost primatelja – RA, anonimnost pošiljatelja – SA, uzajmna anonimnost – MA, lokacijska anonimnost – LA, grupna anonimnost – GA, komunikacijska anonimnost – CA, grupna komunikacijska anonimnost - GCA. Neuočljivost (engl. UNOBservability) znači da napadač ne može uopće uočiti predmete interesa umjesto odrediti identitete čvorova ili odnose među njima, kao inače. To znači da ili uopće ne može utvditi postoji li predmet interesa ili je anonimnost ostalih čvorova u odnosu na predmet interesa ista – npr. svi čvorovi šalju poruku iste veličine istovremeno. Neuočljivost implicira anonimnost, a obrat vrijedi ako se uz anonimnost osigura i lažan (engl. dummy), odnosno promet koji se ne može razlikovati (engl. indistinguishable) [20]: UNOB ANON ANON ∧DUMMY UNOB Neuočljivost podrazumijeva: neoučljivost primatelja, neoučljivost pošiljatelja i komunikacijsku neuočljivost. Neuočljivost pošiljatelja (engl. sender unobservability) znači da nije moguće razlikovati konkretnu poruku među svim poslanim porukama, ili uočiti ju među svim porukama. Drugim riječima, nije jasno koji pošiljatelj iz skupa neuočljivosti pošiljatelja šalje. Neuočljivost primatelja (engl. reciever unobservability) znači da nije moguće razlikovati konkretnu poruku među svim poslanim porukama, ili uočiti ju među svim porukama. Drugim riječima, nije jasno koji primatelj iz skupa neuočljivosti primatelja prima. Poruka ostaje skrivena. Komunikacijska neuočljivost (engl. communications unobservability) znači da nije moguće otkriti je li i jedan mogući par pošiljatelj-primatelj iz skupa neuočljivosti povezan s konkretnom porukom. Skriva se konkretan par primatelj-pošiljatelj. Komunikacijska anonimnost slabije je svojstvo od anonimnosti primatelja/pošiljatelja, jer dok nije jasno da je konkretan par pošiljatelj-primatelj povezan s konkretnom porukom, može biti očito da je taj par ipak povezan s nekim porukama. Ako takvu povezanost nije moguće ustanoviti ispunjena je komunikacijska neuočljivost. Neuočljivost sustava može naći svoju primjenu u vojnim komunikacijama. Služba prikupljanja informacija (Signals Intelligence prema ISTAR modelu, kod nas GSOSRH – SEI i Vojnoobavještajna bojna) [36] presretanjem signala tj. tzv. elektroničkim izviđanjem dolazi do korisnih informacija. Već jednostavnim potvrđivanjem postojanja komunikacije može se doći do vrijednih operativno-taktičkih informacija [35]: • • • • • • • česta komunikacija može značiti planiranje brza kratka komunikacija može značiti pregovore nedostatak komunikacije može značiti neaktivnost ili završetak planiranja česta komunikacija između centralne stanice i nekih određenih stanica može ukazati na zapovjedni lanac tko priča s kime može otkriti koja je područje odgovorosti osoblja iz stanice, što s dodatnim informacijama može implicirati još neka zaduženja praćenog osoblja tko se kada premješta iz postaje u postaju može značiti strah od prisluškivanja subjekta tko kada priča može povezivati stanice s događajima što, ovisno o kontekstu, može svašta implicirati Ostvarenjem komunikacijske infrastrukture koja jamči neuočljivost izbacila bi se iz stroja, ili uvelike otežala, mogućnost protivničkog elektroničkog izviđanja. 79 Dodatak E: Definicije i opaske Slijedi popis definicija komponenata anonimnosti u klasičnom i kubičnom smislu. Klasična anonimnost dovoljno je dobra definicija za praktične potrebe dok definicija proširene anonimnosti uvodi finiji okvir za vrednovanje kvalitete isporučene anonimnosti. SA∧RA classicUNID classicUNID∧LA∧MA∧GA cubicUNID CA classicUNLN classicUNLN ∧GCA cubicUNLN SA∧RA∧CA≡classicUNID ∧classicUNLN classicANON LA∧ MA∧GA∧GCA expandedANON cubicUNID∧cubicUNLN ≡classicANON ∧expandedANON cubicANON Uloga (engl. social role) je u sociologiji definirana kao očekivano ponašanje u zadanom društvenom kontekstu, odnosno kao skup povezanih akcija koje stvaraju sudionici društvene situacije. Drugim riječima, to su ulančani "kontekstno zavisni atributi identiteta" [20] odnosno predmeti interesa. Kontekstom i ulogom ujedno je definirano i postojanje povezanosti atributa odnosno predmeta interesa. Potpuni identitet pojedinca može se sastojati od više djelomičnih identiteta od kojih svaki predstavlja osobu u konkretnom kontekstu ili ulozi. Djelomični identitet je pravi podskup skupa svih vrijednosti atributa koji čine potpuni identitet, koji je unija svih atributa svih identiteta osobe. Potpuni identitet definiran je u idealnom smislu i služi za lakše shvaćanje pojma djelomičnog identiteta. Na tehničkoj razini, ti atributi su podaci. Atributi ili njihove vrijednosti ne moraju biti postojani tokom vremena te se pretpostavlja da vrijedi domenski integritet atributa. Svaki razuman napadač uzimati će u obzir pretraživanje poruka po kompozitnom ključu koji povezuje vrijeme i lokaciju poruka. Osim toga, kao što identitet povezuje pojedinca i grupu tako i parcijalni identitet može povezivati korisnika s grupom korisnika sustava koja može pripadati i nekoj organizaciji [20]. Grupna (komunikacijska) anonimnost nije osigurana ni jednom postavljenom anonimnom mrežom, a može biti interesantna u smislu vrednovanja anonimnosti obzirom da povezuje korisnika sa skupom odnosno definira kardinalnu metriku. Ako je i ispunjen uvjet anonimne komunikacije u klasičnom smislu, dugotrajnim narušavanjem proširene anonimnosti moguće je doći do dodatnog znanja o ponašanju korisnika/korisniku koje može i ne mora biti kritično u smislu deanonimiziranja. Slojevito usmjeravanje (engl. onion routing) prevedeno je tako stoga što je zorna analogija prometa po protokolu slojevitog usmjeravanja s pokretnom trakom glavica luka kojima se slojevi vraćaju ili skidaju. Slojevito usmjeravanje sa spajanjem poruka (engl. garlic routing) razlikuje se od slojevitog usmjeravanja po tome što poruke proizvoljno spaja po dijelovima puta kako bi otežalo napad analizom prometa. U tom smislu poruke po dijelovima puta analogne su glavicama češnjaka dok su pojedine poruke analogne režnjevima. U oba slučaja vrijedi analogija između (slojeva) povrća na pokretnoj traci i postignute anonimnosti kao rezultata protokola. Usmjernik mješač (engl. mix router) također je općeprihvaćen kao pojam i preveden doslovno, jer je upravo kašnjenje prometa, odnosno miješanje prometnih tokova poruka u vremenskoj domeni kritičan mehanizam za postizanje anonimnosti kroz nepovezivost. 80 Dodatak E: Definicije i opaske Predposlužitelj (engl. cache server) rasterećuje poslužitelja preuzimanjem (dijela) njegovog sadržaja. Priručna memorija (engl. cache memory) služi kako bi preuzela dio podataka namijenjen obradi unutar centralne upravljačke jedinice kako bi se ubrzala obrada podataka. Prevodi se i kao predmemorija [4]. U oba slučaja prefix cache označava preuzimanje sadržaja za obradu, a prvi prijevod zauzima manje mjesta brojem znakova i tvori samo jednu riječ. Jamstvo anonimnosti, odnosno odsutstvo identiteta, oslobađa pojedinca odgovornosti za svoje postupke te tako, u virtualnoj komunikaciji, inače skrivena ljudska priroda izlazi na vidjelo. Ovo je moguće provjeriti na Core onion anonimnom forumu [45], na kojem, za početak, nema moderatora; ili na 4chan.org Web stranici. Osim toga, anonimna komunikacija je sama po sebi vrlo zanimljiva jer je uobičajeno da su sudionici komunikacije identificirani. Internet je oduvijek bio (i biti će) mjesto na kojem su informacije slobodne. Za to će se pobrinuti pokreti kao što su kriptoanarhizam [41], haktivizam [40] i Legija anonimnih [42]. Filozofija kriptoanarhizma je individualna sloboda i zaštita privatnosti, a filozofija haktivizma je ostvarenje slobode govora na Internetu. Ovi pokreti nastali su kao odgovor na represiju sustava, a najpoznatija je svakako Legija anonimnih koja je jedini entitet koji se uspješno suprotstavio Scijentološkoj crkvi. Pri tom je bitno napomenuti, kako je Scijentološka crkva jedina organizacija ikad koja je prisilila čak i američku poreznu upravu (IRS) na kompromis tako što je podigla nekoliko tisuća mahom besmislenih tužbi [46]. Metoda Legije anonimnih zanimljiva je jer prije svega još jednom upotrebljava Mrežu kao alat borbe protiv represije, a potom i zato jer je nova primjena načela gerilske borbe uz vrlo učinkovitu organiziranost. Legija anonimnih je "kolektiv pojedinaca koji zajedno djeluju u postizanju zajedničkog cilja. Nemaju vođa ni sljedbenika, a pojedinac nikad ne predstavlja Legiju". Međusobno anonimno komuniciraju, uglavnom putem 4chan.org Web stranice te dogovaraju djelovanje i djeluju, a javnost obavještavaju anonimno putem Interneta i to su jedine "službene" poruke Legije. Poznat je problem zaštite autorskih prava na Internetu, koji je uostalom i razlog nastajanja partnerskih mreža, a opet kao odgovor virtualne zajednice na represiju sustava. Nedavno su MPAA i RIAA unajmile indijsku tvrtku Aiplex da izvrše DDoS napad na PirateBay.org (najotporniji indekser BitTorrent datoteka na planetu), obzirom da pravnim putem nisu mogle ishoditi gašenje stranice. Na stranici 4chan.org najavljeni su, a nedugo potom i izvršeni, osvetnički DDoS napadi na Web stranice svih tvrtki povezanih s ovim incidentom od strane "aktivista za piratstvo". Dakako da je drugi napad bio puno učinkovitiji od prvog [39]. Ovaj uzorak, osim što je već nazvan cyber-prosvjedovanjem, ukazuje na rješenje pravnog modela prijetnje. Anonimna organizacija onemogućuje pravni napad na načelnoj razini – pravni mehanizmi pretpostavljaju identifikaciju i fizičko privođenje subjekta da bi se uopće mogli početi ostvarivati. Ovakav je pristup sasvim zadovoljavajuć za cyber-aktivizam, međutim za anonimne računalne mreže gubi smisao jer takav sustav mora djelovati unutar legalnog okvira. Svaki anonimni protokol napisan je tako da administrator čvora ne može utjecati na rad protokola van uskih tehničkih parametara. Efektivno, administrator čvora nije odgovoran za promet svog čvora već aplikacija koja izvršava protokol. Na taj se način opet onemogućuju pravni mehanizmi na načelnoj razini obzirom da ni računala ni aplikacije po definiciji nisu entiteti koji mogu biti odgovorni za neko djelo. 81
© Copyright 2024 Paperzz
