Anonim web böngészés Onion Routing technológiával


Tóth Csaba <s8217tot@hszk.bme.hu>

BME-VIK, Híradástechnika Tanszék


1. Bevezetés

Az onion routing [1][2][3][15] úgy működik, hogy dinamikusan anonim kapcsolatokat épít fel valós idejű Chaum mixek [4][5][6] hálózatán keresztül. A mix egy tárol-és-továbbít elven működő eszköz, ami különféle forrásokból azonos hosszúságú üzeneteket fogad, kriptográfiai transzformációt hajt végre rajtuk, és véletlen sorrendben továbbítja őket a következő helyre. A gerinc onion routerek (mixek) által alkotott onion router hálózat elosztott, hibatűrő, több adminisztratív tartomány irányítása alatt áll, így egy onion router kompromittálódása nem veszélyezteti a felhasználó névtelenségét.

Az onion routing az anonim levél-továbbítókhoz (anonym remailer) hasonlóan működik, de két fontos szempontban eltér tőlük: a kommunikáció valós-idejű és kétirányú, és a létrejött anonim kapcsolatok alkalmazás-függetlenek. Például az onion routing használható anonim web böngészésre, vagy fájl átvitelre, nemcsak levélküldésre.

2. Áttekintés

Az onion routingban a kezdeményező nem közvetlenül a célgéppel épít fel socket-kapcsolatot, hanem gépek láncolatán (az onion routereken) keresztül. Az onion routing hálózat gondoskodik a kezdeményező és a célgép közötti kapcsolat anonimitásáról.

A forgalomanalízist akkor tudjuk a legjobban megnehezíteni, ha a proxy gép is aktívan részt vesz az onion routing hálózatban anonim kapcsolatok építőköveként, mert így a belső hálózat által generált forgalom belekeveredik a többi itt átfolyó anonim kapcsolat által generált cellák közé. Ha az onion router hálózat szolgáltatását egy nem tűzfal által védett gép kívánja igénybe venni, akkor maximális anonimitás érdekében helyileg célszerű egy onion routert futtatnia.

Az onion routerek egymással hosszú távú (permanens) socket kapcsolatokkal vannak összekötve. Az onion router hálózatban kialakuló anonim kapcsolatok a hosszú távú socketeken keresztül multiplexálva továbbítódnak. Minden anonim kapcsolat útvonala a felépítéskor szigorúan meg van határozva. Az onion és az adatok az útvonal minden csomópontjánál más formában jelennek meg, így az adatfolyam nem követhető az útvonal mentén, és kompromittált onion routerek sem tudnak összedolgozni. Az egyes onion routerek egy adott anonim kapcsolat útvonala esetében csak a szomszédos onion routereket ismerik.

Először a kezdeményező alkalmazás egy socket kapcsolaton keresztül kapcsolódik az initiator proxyhoz (alkalmazás proxy). Ez a proxy átalakítja a kapcsolódási információt egy általános formára (standard struktúra és végleges cím), ami átküldhető az onion routing hálózaton keresztül. Az initiator proxy ezután hozzákapcsolódik a megfelelő onion proxyhoz, ami definiálja az onion routing hálózaton keresztüli útvonalat, és elkészíti az ennek megfelelő onion nevű réteges struktúrát.

Az oniont odaadja az útvonal első onion routerének. Az onion minden rétege definiál egy következő csomópontot. Az onion router, amikor megkapja az oniont, lehámozza legkülső réteget (kriptográfiai transzformációval), azonosítja a következő csomópontot, és továbbküldi erre a beágyazott oniont. Ha az utolsó onion router is megkapta az oniont, akkor vár a standard struktúrára és az utána érkező végső cél címre. Ezt megkapva felveszi a kapcsolatot a végső célnál található responder proxyval, ami közvetlen megteremti a kapcsolatot a kívánt távoli alkalmazással.

Az onion nyilvános kulcsú kriptográfiával van védve. Minden onion réteg a következő csomópont információja mellett tartalmaz egy kulcs alapanyagot is, aminek segítségével az adott anonim kapcsolat számára legenerálhatók a szükséges oda-vissza-irányú szimmetrikus kulcsok.

Ha egyszer kiépítődött az anonim kapcsolat, már adatot is szállíthat. Mielőtt az onion proxy elküldené az adatot, az útvonalon található összes onion router számára egy-egy rétegnyi rejtjelezést ad hozzá. Ahogy az adat mozog az anonim kapcsolaton keresztül, minden onion router leválaszt egy réteget az adatról, míg a címzetthez végül sima szövegként érkezik meg. A visszafele áramló adatokra a rétegződés pont fordítva történik: ahogy halad visszafelé az adat, minden router hozzáad egy rejtjelezési réteget. Így a kezdeményező oldali proxynak a megérkező adatot rekurzíven utó-rejtjeleznie kell (le kell vennie a rétegeket).

Ilyen módszerrel rétegezve a kriptográfiai műveleteket, egy előnyhöz jutunk a link rejtjelezéshez képest. Az adat a mozgása közben különböző formában jelenik meg minden onion router számára. Ezért egy anonim kapcsolat olyan erős, mint a legerősebb láncszem, és mindössze egy hűséges csomópont is elegendő az útvonal privát voltának megőrzéséhez. Az onion router a lejárati ideig megőrzi az onion-öket. Az ismételt vagy lejárt onion-öket nem továbbítja, ezek tehát nem használhatók az útvonal felfedésére.

Habár ezt a rendszert onion routingnak nevezzük, a routing itt a protokoll verem alkalmazási rétege alatt történik, és nem az IP rétegben. Pontosabban a hosszú távú kapcsolatokon keresztüli adat továbbításnál az IP réteg routolására támaszkodunk. Egy anonim kapcsolat számos hosszú távú kapcsolatra multiplexált socket kapcsolatból tevődik össze. Az onion routerek csak logikailag szomszédosak, valójában a hosszú távú kapcsolatok több csomóponton keresztül juthatnak el a szomszédig. S habár az anonim kapcsolatban résztvevő onion routerek a kapcsolat élete alatt rögzítettek, az útvonal, amin az adatok az egyes onion routerek között utaznak, az IP szint által van meghatározva.


3. Támadási modell

Az onion routing technológia elég konzervatív, mert a nyilvános hálózatot nagyon támadhatónak tartja. Konkrétan feltételezzük, hogy:

Ez a négy motiváció közvetlen befolyásolt bizonyos döntéseket az onion routing tervezésénél. Mivel a forgalom látható, az egész forgalom fejlécét és rakományát szükségszerűen link rejtjelezni kell az onion routerek között, így az adat különböző formában jelenik meg a routerek közötti utazása során. Mivel a forgalom módosítható is, a rejtjelezéshez folyam (stream) rejtjelezést használunk (ez jelenleg DES OFB, IV=0 mellett). Adat hozzáadása, törlése, vagy módosítása megzavarja a folyamot, és folyamatos véletlen bitsorozatot eredményez (DoS támadás), de az adat útja továbbra nem követhető a rendszeren keresztül. Mivel az onion routerek kompromittáltak is lehetnek, az anonim kapcsolatoknak számos onion routeren keresztül kell araszolniuk. A kompromittált onion routerek együttműködhetnek, ezért az adat rétegelt módon rejtjelezett, így minden onion router számára más formában jelenik meg.

Általánosságban azt mondhatjuk, hogy egy támadás a magán információk kompromittálódása helyett DoS (Denial of Service) támadást eredményez. Például feltételezzük, hogy az adatok a socketekre sorrendben és módosítatlanul érkeznek. Egy kompromittált onion router könnyen megszegheti ezt a feltételezést, azonban ez megjósolhatatlan és olvashatatlan szöveget okoz az adatok közvetlen feltárulása helyett. Mivel egy onion megismétlése (replay) ugyanolyan beágyazott onion megjelenését vonja maga után folyásirányban, azt gondolhatnánk, hogy így fel lehet fedni a kapcsolódási információt. De maguk az onion-ök nem ismételhetők meg egy hűséges onion routeren keresztül. Az onion routerek egy hash tároló struktúra segítségével emlékeznek az általuk korábban továbbított onion-ökre. Ha egy másolatot észlelnek, akkor azt egyszerűen eldobják. Hogy a tárolási igények szabályozottak legyenek, az onion-ök lejárati idővel vannak ellátva. Ha az órák a szükséges szinkronizációtól túl távol vannak az egyik irányban, akkor ennek egyetlen lehetséges következménye, hogy a még friss onion-ök lejártnak néznek ki, és eldobódnak. Ha a másik irányban térnek el túlságosan, akkor ez azt eredményezi, hogy az onion a lejáratánál kicsit tovább tárolódik. Mindezekkel kapcsolatban egy a lényeg: noha DoS támadás véghezvihető, az anonim kapcsolat útvonala semmiképpen sem tárul fel a támadó számára.

A kezdeményező proxy-ja és az első onion router az onion routing infrastruktúra legbizalmasabb eleme. A kezdeményező proxy készíti el az anonim kapcsolat onion-jét, ami az útvonalat definiálja. Ha a kezdeményező proxyt a kezdeményező gépére tesszük, akkor ezzel a bizalmas információkat az ő irányítása alá vonjuk. Ennek elve (a bizalom átmozgatása, shifting trust) alapvető fontosságú a védelem tekintetében. Az első onion router a kapcsolódási pont a hálózathoz, ez tudja a kapcsolat forráshelyét, a cél helyet viszont már nem.

Az onion routing nem sérthetetlen a forgalom analízises támadások ellen. Elegendő adat birtokában mindig lehetőség van a használati minták vizsgálatára, és ez alapján az útvonalakra vonatkozó jól megalapozott kérdések feltevésére. Habár a kapcsolatok szimultán megnyitásának figyelése egy lehetséges támadás, de a külső szemlélőtől elképesztő mennyiségű adat gyűjtését igényli. Meg kell jegyezni, hogy bármilyen forgalom analízisnek ellenálló támadás nem tudja egy üzenet lehetséges címzettjeinek terét nagyobbra növelni, mint a hálózatban lehetséges címzettek tere. Tehát felesleges elvárnunk, hogy a forgalmi analízis nehézsége egy kriptográfiai algoritmus kimerítő keresésének költségével (pl. 256) legyen egyenlő. Mindazonáltal a forgalom analízises keresés drágább lehet, mivel egy hálózatot monitoroznunk kell.


4. Implementáció

Proxyk

Az anonim kapcsolat megteremtéséhez olyan eszközre van szükségünk, melyet a meglévő alkalmazások módosítás nélkül használni tudnak. Ehhez megfelelő választás a proxyk alkalmazása. Egyre több alkalmazást készítenek natív proxy-támogatással, melyekhez csak megfelelő interfészt kell készítenünk.

Az alkalmazásunk és az onion router hálózat közötti közvetítéshez olyan proxyra van szükség, mely mindkét oldal protokollját ismeri. Ez a megközelítés nagyon speciális megoldáshoz vezetne, így érdemes kettéválasztani a feladatot, és két proxyval helyettesíteni az eredeti egyet. Az initiator proxy feladata, hogy tartsa a kapcsolatot az alkalmazással, az adatfolyamból kinyerje a kapcsolat tényleges címzettjét (vagy hosztnév/port vagy IP/port formában), és ezt az információt egy standard adatstruktúrában az onion proxyhoz továbbítsa. Ezután megvárja a kapcsolat másik végéről a hibakódot, amit az alkalmazás felé valamilyen értelmezhető formában közvetít. Az onion proxy feladata, hogy az igazi cím ismeretében definiáljon egy útvonalat az onion router hálózatban, és felépítse az anonim kapcsolatot. Az onion proxy állítja elő az oniont, mely kriptográfiailag rétegzett formában tartalmazza az útvonal állomásainak címeit. Minden onion router az útvonal mentén lebont egy héjat az onion-ről (innen származik a struktúra elnevezése: onion=”hagyma”), s így hozzájut a következő router címéhez. Az utolsó router továbbítja az adatfolyamot a hozzá csatlakozó responder proxyhoz, mely felépíti a socket kapcsolatot a valódi címzettel és visszaküld egy byte státuszinformációt az onion router hálózathoz.

Az onion routing rendszer

Az onion routing rendszer négy fő részből áll: initiator proxy, onion proxy, onion routerek, responder proxy

Egy anonim kapcsolat felépítéséhez szükséges lépések:

Initiator proxy

Az alkalmazás és az initiator proxy közötti interfész alkalmazásonként változik. Az initiator proxy és az onion proxy közötti interfész stabilan definiálható. Minden új kérésről eldönti a proxy, hogy kiszolgálja-e. Visszautasítás esetén az alkalmazásnak megfelelő hibaüzenetet generál, majd bezárja a socketet. Elfogadás esetén megnyit egy socketet az onion proxy jól ismert portjára, majd elküld egy ún. standard struktúrát:

A standard struktúra minden eleme 1 byte hosszúságú. Először a standard struktúra kerül átküldésre. Ekkor az initiator proxy vár egy hibakódot az onion proxytól, és csak ezután küldi át a megadott formátumban az igazi célgép címét. Innentől kezdve a proxy csupán közvetít az alkalmazás és az onion proxy között.

Onion proxy

A standard struktúra megérkezése után az onion proxy eldöntheti a protokoll, a célcím ill. az initiator proxy azonossága alapján, hogy fogadja-e a kérelmet. Visszautasítás esetén elküld egy hibakódot az initiator proxynak, lezárja a socketet, majd várja az újabb kérést. Elfogadás esetén felépíti az oniont, létrehozza az anonim kapcsolatot a célgéppel és elküldi a standard struktúrát az útvonal utolsó gépének. Innentől kezdve már csak közvetítő szerepet játszik az initiator proxy és az onion router között.

Az onion

Az anonim kapcsolat felépítéséhez az onion proxy létrehoz egy oniont. Ez egy többrétegű adatszerkezet, mely magában foglalja az anonim kapcsolat útvonalát. Egy réteg szerkezete az alábbi módon épül fel:



1

7

4

4

16

0

Verzió

Back F

Forw F

Cél port

Célcím

Lejárat ideje

Kulcs mag


Az első bitnek kötelezően nullértékűnek kell lennie az RSA nyilvános kulcsú rejtjelezés miatt. A verziószám az onion routing rendszerre vonatkozik, jelenleg konstans 1 az értéke. A Back F mező határozza meg azt a kriptográfiai függvényt, melyet az útvonal mentén visszafele haladó adatfolyamon kell alkalmazni a 2-es kulccsal (lásd. lejjebb). A Forw F mező határozza meg az útvonal mentén előrehaladó adatfolyamon végrehajtandó kriptográfiai függvényt (a 3-as kulccsal).

A (Célcím, Célport) páros az útvonalon a következő onion routert jelöli ki. Az útvonal utolsó elemét (0,0) célcím és port jelzi. A kulcsmag 128 bit hosszú, és ebből nyerjük három hash-eléssel (SHA) a szimmetrikus kriptográfiai függvényekben használt kulcsokat (1-es, 2-es, 3-as). RSA nyilvános kulcsú titkosítást alkalmazunk 1024 bites modulussal és 1024 bites blokkméretű nyílt szöveggel. Az onion-ök előállítása iteratív módon történik, a legbelső réteggel kezdve. Minden iterációban az onion első 128 bájtja annak a routernek a nyilvános kulcsával van kódolva, akinek azt később dekódolnia kell. Az onion maradékát DES OFB-vel titkosítjuk (IV=0, az 1-es kulcsot használva).

Onion routerek kapcsolódása

Az onion hálózat felépítésekor (nem összetévesztendő az anonim kapcsolat felépítésével) hosszú távú kapcsolatok jönnek létre a szomszédos onion routerek között. A hálózati topológia fix, és minden router ismeri a szomszédait. A protokollnak két fázisa van: kapcsolat-felépítés és kulcskiosztás. A kezdeményező onion router megnyit egy socketet a szomszédos onion router jól ismert portjára, és elküldi az IP címét és a jól ismert portszámát, hogy azonosítsa magát. A kulcskiosztás következik, melyben Diffie-Helman kulcscsere protokoll (az NRL projektben STS protokoll) használatával két 56 bites DES kulcs keletkezik. A hosszú távú kapcsolatok link rejtjelezése DES OFB-vel történik ezt a két kulcsot felhasználva mindkét irányban, IV=0.

A kulcskiosztás után az onion routerek közötti kommunikáció fix méretű cellákra bomlik, mely lehetővé teszi mind az anonim kapcsolatok mind a vezérlési információk multiplexálását a hosszú távú kapcsolatokon.

Az onion routing rendszer 1-es verziójában négyféle cella van: PADDING(0), CREATE(1), DATA(2), DESTROY(3)

A cellák szerkezete:


16

8

8

ACI

Parancs

Hossz

Hasznos teher
(192 bájt)


Minden anonim kapcsolathoz minden onion routernél egy ACI-t rendelünk, mely az anonim kapcsolat azonosítására szolgál a multiplexálás során. Az ACI-knek egyedinek kell lennie egy adott hosszú távú kapcsolaton, de nem kell globálisan egyedinek lennie.

Az onion rendszerben tett útja során az onion router lehámoz róla egy réteget a következő csomópont azonosítása érdekében. Ellenőrzi az onion frissességét (lejárt onion vagy visszajátszás), előállítja a szükséges kriptográfiai kulcsokat, inicializálja az előre és hátra haladó forgalmat kódoló kriptográfiai motorokat, kiválaszt egy új ACI-t az új kapcsolathoz. Ezután létrehoz egy olyan adatszerkezetet, mely tartalmazza az adott anonim kapcsolathoz tartozó bejövő és kimenő ACI-k közötti megfeleltetést, és az előre illetve hátra haladó forgalmat kódoló kriptográfiai motorokat. Miután egy onion router lefejtett egy réteget az onion-ről, a maradékot kiegészíti random bájtokkal az eredeti hosszára, és CREATE cellákban továbbküldi a megfelelő szomszédnak. Az utolsó cella hasznos teher részét random bitekkel töltjük fel, ha szükséges, hogy elkerüljük a nyomkövetés lehetőségét.

Az anonim kapcsolaton az adatok DATA cellákban szállítódnak. Ha egy kapcsolat megszakad, akkor DESTROY cella hatására törlődnek az állapotinformációk. A PADDING cellákkal adatot juttathatunk a hosszú távú kapcsolatokra, ezzel megnehezítve a forgalom analízist. A PADDING cellákat figyelmen kívül kell hagynia a routereknek.

Minden onion router összekeveri a rajta átmenő cellák sorrendjét. Egy adott idő alatt az összes kapcsolatokon érkező cellákat ál-véletlen módon keveri meg az onion router, de egy kapcsolaton belül a cellák sorrendje változatlan marad.

Ha az onion router azt érzékeli, hogy a következő csomópont IP címe és portszáma 0, akkor tudja, hogy ez a végállomása az anonim kapcsolatnak az infrastruktúrán belül, és fölveszi a kapcsolatot a megfelelő responder proxyval. A responder proxy elolvassa a standard struktúrát és az igazi cél címet, amik először jönnek át az anonim kapcsolaton. A proxy ezek alapján felveszi a kapcsolatot a célalkalmazással, és visszaküldi az anonim kapcsolaton a hibakódot. Ezek után vakon továbbítja az anonim kapcsolaton keresztül az igazi cél felé áramló, illetve az onnan érkező adatokat.


Eltéréseink az NRL Onion Projekttől


A mi implementációnk több részletben is eltér az eredeti NRL projekt verziójától. Egyszerűség kedvéért a kulcscsere protokoll tekintetében STS helyett a cryptlib [14] által biztosított, módosított Diffie-Hellman kulcscserét használjuk.

Kis mértékben átértelmeztük az anonim kapcsolat elején és legvégén található csomópontok szerepét. A kezdeményező alkalmazás a helyi initiator proxyhoz kapcsolódik. Az onion proxy a konfigurációtól függően helyi, vagy védett helyen található onion routerel veszi fel a kapcsolatot. Az anonim kapcsolat végén az utolsó onion router az ott található responder proxyval kerül kapcsolatba (így a célnál nem szükséges semmilyen onion komponens futtatása), végül ez pedig közvetlenül a célalkalmazással kommunikál. Egyelőre egy HTTP/1.0 proxyt implementáltunk [9].


5. Implementációs problémák

Az NRL projekt levélarchívumának átolvasása után kiderült, hogy ugyanolyan, vagy nagyon hasonló problémák és viták merültek fel ott is, mint nálunk a kutatás folyamán. A cypherpunk remailer hívek elsősorban az onion routing remailerekhez képest gyenge mixelési tulajdonságait kritizálták. Ugyanis a közel valós-idejű kommunikációs csatorna ára, hogy az onion routerek csak igen limitált módon késleltethetik a cellákat. Ez nem olyan nagy probléma, ha a hálózat ideálisan terhelt.

Kis forgalom esetén viszont megkönnyíti a forgalom analízist. A felmerülő megoldási javaslatok egyike sem ideális. A padding cellák beiktatásával a forgalomhiány kompenzálható. Azonban a padding cellák egyrészt eléggé sávszélesség pazarlók, másrészt az álterhelés mértékére a best-effort tulajdonságú hálózat nem ad semmiféle információt vagy támpontot. A pipe-net terv [7][8], ahol a csomópontok között tökéletesen konstans sebességű információ áramlik, elég utópisztikus a jelenlegi Internet felett. Vajon mennyi legyen az a bizonyos konstans sebesség? Ha lerögzítjük, akkor könnyen bedugulhatnak a csövek az érzékeny csomópontokon. Másrészt rendkívüli mértékben pazaroljuk az erőforrásokat. A mostani koncepciónk az, hogy az álforgalom (padding) generálását nem végzi el beépítetten az onion router hálózat, de támogatja. Ugyanis az onion router csomópontok ismerik a PADDING cellákat, és automatikusan eldobják azokat. Azaz szükséges esetben ez a probléma “más szinten” is megoldható. Az NRL projekt tapasztalatai azt mutatták, hogy tökéletesen elegendő (meglepően nagy) forgalom generálódott az onion router-ükön keresztül, pedig a kísérleti szoftverüket csak az USA-ban, korlátozott körben osztották. Az anonim remailerek is leterheltek, így hát joggal lehet arra alapozni, hogy a terhelés megfelelő lesz.

Az eredeti projektben (és egyelőre nálunk is) az infrastruktúra routing része nagyon sovány. Fontos lesz eldönteni, hogy milyen routing algoritmust válasszunk, és lényeges kérdés a támadhatóság szempontjából, hogy a topológiai információt milyen módon terjesszük. Például egy újabb cella típus bevezetésével (a CREATE, DATA, PADDING és DESTROY mellett). A routing algoritmus és routing információ terjesztése nagymértékben meghatározza az infrastruktúra hibaállóságát is, ami szintén lényeges támadási kérdés.

A routing információ terjesztése mellett fontos kérdés a routerek nyilvános kulcsainak kezelése, tárolása. Akárcsak az infrastruktúra topológiája, ez is tárolható központi vagy elosztott módon. Problémát vethet fel a kis sávszélességgel és/vagy processzor kapacitással rendelkező felhasználók csatlakozása (pl. DUN user). Ezt adott esetben figyelembe kell vennünk a routing algoritmusnál, lehet, hogy kapacitásos gráf modellt kell alkalmazni. Ennek időbeli változása és frissítése komoly sávszélesség problémát vet fel. Sávszélesség probléma merül fel a nyilvános kulcs tárnál is.

A kísérleti re-implementációnk statikusnak tételezi fel a hálózati topológiát, és nem tartalmaz mechanizmusokat a kulcsok automatikus elosztására, illetve frissítésére. Noha ezek a részletek nagyon fontosak, csak későbbi implementációba építjük be.


6. Összehasonlítás hasonló rendszerekkel

Chaum [4][5][6] egy rétegezett objektumot definiált, ami segítségével ún. mixeken keresztül továbbíthatunk adatokat. Ezek a közbülső pontok (mixek) késleltethetik az adatot, megváltoztathatják a sorrendjüket, és véletlen adatot adhatnak a forgalomhoz, megnehezítve a forgalom analízist. Az alkalmazások a mixeket előre rögzített és fix sorrendben használhatják. Az onion routerek legalább két dologban különböznek a mixektől. Először is az onion routerek a közel valós idejű szolgáltatás miatt korlátozottabbak az adat késleltetésében. Másodsorban az onion routerek közötti forgalom egyetlen csatornára multiplexált, és folyam (stream) kódoló segítségével link rejtjelezett. Ez nehézzé teszi a rendszer átlátását külső támadó szempontjából. A tipikus onion routing konfigurációban a routerek egyben belépési pontok is a hálózatba. Mivel a hálózatba belépő és kilépő forgalom nem elkülöníthető, ez megnehezíti a csomagok követését, mert a hálózat bármely pontján kiléphetnek, és bármely ponton bejöhetnek cellák.

Az onion routerekhez hasonlóak az anonim remailerek [6][10][11][12][13], melyek tárol-és-továbbít elvű architektúrák. Fejlettségi szintűktől függően több generációjukat különböztetjük meg. A Penet-hez hasonló anonim remailerek leszedik az érkező levélről a fejléceket, és továbbítják a címzetthez. A küldő címét egy álnévre (alias) is cserélhetik, ezáltal lehetővé válik a válasz is. Hogy megakadályozzák a visszajátszás típusú támadásokat, az Anonymous remailerek naplózzák a küldött leveleket. A HTTP alkalmazásokhoz ilyen elvű rendszerek nem használhatók, mert a HTTP kétirányú, másrészt hatalmas naplót generálna. Ezek a fajta remailerek kényes információkat tárolnak: az álnév és a valós cím közötti megfeleltetést.

A Mix alapú remailerek mixeket használnak az e-mail szolgáltatásaik biztosításához. Természetszerűleg a levél üzenete a rétegelt struktúrában legbelül található. Egy másikfajta réteges struktúrát a visszatérési címhez használnak, és az üzenet mellé rakják. Így a levél a visszatérési útját maga tartalmazza, a remailer szükségszerűen állapotmentes működésű.

Látjuk, hogy az anonim remailerek válaszolási lehetőséget biztosítanak a névtelen levelekre. Az onion routingban lehetőség van a küldőnek reply onion (válasz hagyma) készítésére, ami a céltól a küldő fele definiál egy kapcsolatot. Ezeket a reply onion-öket elküldhetjük a levélben. Ha választ küldenek egy onion routeren lévő megfelelő onion proxynak, akkor először feldolgozzák a reply oniont, hogy a küldő felé felépüljön az anonim kapcsolat. A válasz elküldődik az anonim kapcsolaton keresztül. Vegyük észre, hogy a reply onion egy olyan álnévvel egyenértékű, amit nem tárolnak az onion routerben. Tehát az onion routerek állapot nélküli remailerként viselkednek.

A pipe-net [7][8] egy onion routinghoz nagyon hasonló terv, amit eddig még nem implementáltak. A pipe-net támadási modellje sokkal szigorúbb: globális megfigyelők általi aktív támadásoknak is ellenáll. A pipe-net csomópontjai között konstans forgalom áramlik.

Az Anonimyzer egy web proxy, ami kiszűri a HTTP adatfolyamból a felhasználót azonosító információktól (e-mail cím, számítógép típus, előzetesen meglátogatott oldalak). Ez a web böngészést priváttá teszi, ha nincs hallgatózás vagy forgalmi analízis. Az Anonymizer kétféle módon támadható. Először is meg kell bíznunk benne. Másodszor, a böngésző és az anonymizer közötti forgalom tisztán áramlik, ez a forgalom még azonosítja a kérelem valódi célját, azokat az azonosító információkat is tartalmazza, amiket az Anonymizer kiszűrne.


Irodalomjegyzék


  1. Michael G. Reed, Paul F. Syverson, és David M. Goldschlag. Proxies for Anonymous Routing, Proceedings of the 12th Annual Computer Security Applications Conference (San Diego, CA, 1996. december 9.-13.), IEEE CS Press, 1996. december, pages 95-104.

  2. Paul F. Syverson, David M. Goldschlag, és Michael G. Reed. Anonymous Connections and Onion Routing, Proceedings of the Symposium on Security and Privacy, Oakland, CA, 1997. május, pages. 44-54.

  3. Paul F. Syverson, David M. Goldschlag, és Michael G. Reed. Anonymous Connections and Onion Routing, Proceedings of the Symposium on Security and Privacy, Oakland, CA, 1997. május, pages. 44-54.

  4. D. Chaum. Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, Communications of the ACM, vol. 24 no. 2, 1981. február, pages 84-88.

  5. D. Chaum, The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability, Journal of Cryptology, 1/1, 1988, pages 65-75.

  6. L. Cottrell. Mixmaster and Remailer Attacks, http://obscura.com/_loki/remailer/remailer-essay.html

  7. Wei Dai. Pipe-net (1.0), 1995. február, egy levél a cypherpunks levelezési listára, http://www.eskimo.com/~weidai/pipenet.htm

  8. Wei Dai. Pipe-net (1.1), http://www.eskimo.com/~weidai/pipenet.txt

  9. T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer Protocol - HTTP/1.0, RFC1945

  10. Székely Iván. A jó, a rossz, meg az anonim remailer. Magyar Távközlés, vol. IX, no. 5, Budapest 1998.

  11. Rákóczi Bálint. Névvel, név nélkül, álnéven. Anonim kommunikáció az Interneten. Magyar Távközlés, vol. IX, no. 5, Budapest 1998.

  12. Michael Froomkin. Anonymity and Its Enmities (article 4), the Journal of Online Law, 1995. Bővebb változat:

  13. Michael Froomkin. Flood Control on the Information Ocean: Living With Anonymity, Digital Cash, and Distributed Databases, 1996. november 25., [újraellenőrizve 1998. március 16.] http://www.law.miami.edu/~froomkin/articles/ocean.htm

  14. Peter Gutmann. Cryptlib Security Toolkit (Version 3.0 beta 2) Manual, 2000. augusztus

  15. Müller Zsolt, Tóth Csaba: Privát Web böngészés Onion Routing technikával, 2000. Évi BME TDK dolgozat