Digitális hitelesség, biztonságos levelezés

Posted by tacsko as biztonság, hálózat, privacy, tech

Mióta ember az ember, és az információnak ára van, szükség van biztonságos adatátvitelre. Ez egy nagy témakör, jelen iromány csak a biztonságos levelezésre összpontosít, és nem kriptográfusok valamint kriptoanalitikusok számára készült. Elsőként szögezzük le, hogy ebben a leszűkített témakörben pontosan mit jelent a biztonság és a hitelesség fogalma.

Biztonság: Egy titkosított üzenet elolvasása csak az arra hivatott személy számára lehetséges.

Hitelesség: Egy hozzám érkező üzenetről minden esetben el tudom dönteni, hogy annak ki a feladója, valamint azt is, hogy az üzenet az átvitel során szenvedett-e módosítást, vagy sem.

Remélem sokaknak nem mondok új dolgot, amikor azt állítom, hogy az általunk használt elektronikus levelezés, egyik kritériumnak sem tesz eleget. (Idő hiányában nem írom le a levélhamisítás pontos menetét, elég hozzá egy smtp szerver és egy telnet. Ha valaki nem hinne nekem: e-mail spoofing) Természetesen általános esetben nincs szükségünk titkosításra, de a legtöbb esetben jó tudni, hogy kitől is kapunk levelet.

Bár külön választottam a biztonság és a hitelesség fogalmát, valójában mindkét kritérium elérésére titkosítási algoritmusokat használunk, következzen hát egy nagyon rövid áttekintő a titkosításról, mely az algoritmusokat nem érinti. Tételezzük fel, hogy egy titkosított üzenet csak a megfelelő kulcs birtokában fejthető vissza.

Innentől a két fél üzenetváltás során: Alice (A), Bob (B)

Megbízható harmadik fél: T

Támadó: Malory (M).

Szimmetrikus kulcsú titkosítás:

Alice és Bob is ugyanazon K kulcsot birtokolják, mely segítségével a szöveg be, majd kititkosítható. Az ilyen titkosítási algoritmusok egyben a hitelességet is biztosítják, hiszen a használt kulcs csak a két fél számára ismert, ha egy üzenetet nem A titkosított, mégis ezzel a kulcsal van titkosítva, akkor az minden bizonnyal B-től származik. Hátránya, hogy egy kulcsot csak két személy között használhatunk, hiszen egyébként bárki aki a kulcs birtokába jut, A és B nevében írhat levelet, és a titkosítást is megfejtheti. A kulcsok cseréje sem triviális folyamat, hiszen véletlenül se juthat illetéktelen kezekbe. (key exchange algorithm)

Aszimmetrikus kulcsú titkosítás:

Az aszimmetrikus kulcsú titkosítás kicsit több magyarázatot igényel. Ebben az esetben, minden résztvevő két kulcsal rendelkezik. Egy publikus, valamint egy privát kulcsal. Nem véletlenül kapták ezt a nevet: a publikus kulcs mindenki számára hozzáférhető, bárki megkaphatja, és használhatja; a privát kulcs azonban minden esetben őrizendő, soha nem juthat megbízhatatlan harmadik fél birtokába. (innentől “A” publikus kulcsa: pubA; “A” privát kulcsa: privA)

Ezen két kulcs önmagában nem tud többet, mint a szimmetrikus kulcsok. Egy publikus kulcsal titkosított szöveget csak és kizárólag a hozzá tartozó privát kulcsal fejthetünk vissza, és egy privát kulcsal titkosított szöveg csak és kizárólag a hozzá tartozó publikus kulcsal fejthető vissza. Nézzük hát, hogy az általunk tárgyalt levelezés során hogy alkalmazhatjuk ezeket a kulcsokat titkosításra, és hitelesség elérésére.

Titkosítás aszimmetrikus kulcsal:

Tegyük fel, hogy B kíván titkos üzenetet küldeni A-nak. “A” rendelkezésére áll: pubA, privA, pubB; valamint B rendelkezésére áll: pubB, privB, pubA. Ez az általános eset, a privát kulcsokkal csak saját tulajdonosuk rendelkezik, míg a publikus kulcsok mindenki által ismertek.

Nézzük B hogy járhat el:

1. Az üzenetet pubB-vel titkosítja. Ezt az üzenetet csak privB segítségével fejthetjük vissza, ami csak B számára ismert, tehát A soha nem fogja elolvasni azt.
2. Az üzenetet privB-vel titkosítjuk, ekkor pubB segítségével ugyan visszafejthetjük, azonban pubB mások számára is rendelkezésre áll, így mások is elolvashatják az üzenetet.
3. Az üzenetet pubA-val titkosítjuk. Ezt csak privA kulcs segítségével fejthetjük vissza, ami A birtokában van, és más nem rendelkezik vele. Tehát ez a helyes eljárás.

Titkosítás során mindig a címzett publikus kulcsával titkosítunk.

Hitelesítés aszimmetrikus kulcsal:

Ahogy azt megszokhattuk, dokumentumok hitelesítésére aláírásunk szolgál. Az elektronikus világban is aláírással hitelesítjük leveleinket. Nézzük milyen módon tehetjük ezt aszimmetrikus kulcsok segítségével.

Tegyük fel, hogy B kíván hiteles levelet küldeni A-nak. Első lépésként B a levél tartalmából hash függvénnyel egy lenyomatot készít. Erre azért van szükség, hogy a kódolás kényelmesebb legyen, hiszen az egyes hash függvények általában fix hosszúságú, jóval rövidebb lenyomatot készítenek, mint az eredeti üzenet. Ez a lenyomat szinte egyértelműen összerendelhető (matematikusok most ne kövezzetek meg) az elküldendő levéllel, nagyon nehéz még egy olyan üzenetet találni, melynek ugyanaz a lenyomata. Ezt a lenyomatot titkosítja B privát kulcsával, majd a levélhez csatolva küldi el A-nak. “A” a levélből ugyanazon hash függvény segítségével legenerálja a lenyomatot, és pubB segítségével visszafejti a B által generált lenyomatot. Ha a két érték megegyezik, a levél érintetlen állapotban érkezett meg, és A abban is biztos lehet, hogy B-től származik, hiszen a lenyomat privB-vel került titkosításra, mellyel csak B rendelkezik. Természetesen ezen módszer nem csak A, de mindenki számára biztosítja a levél hitelességét, hiszen pubB-vel mindenki rendelkezik.

A két módszer ötvözésével hiteles, titkos levelet küldhetünk két fél között.

Tegyük fel, hogy B szeretne hiteles, és egyben titkos üzenetet küldeni A-nak:

1. B legenerálja a levél lenyomatát
2. B titkosítja a lenyomatot privB segítségével
3. a levél szövege mögé illeszti a privB-vel titkosított lenyomatot, majd az egész üzenetet titkosítja pubA-val
4. az így elkészített üzenetet elküldi A-nak
5. A privA segítségével kititkosítja az üzenetet
6. A pubB segítségével kititkosítja a korábban privB-vel kódolt lenyomatot
7. A a levél szövegéből maga is legenerálja a lenyomatot és összehasonlítja azt az előző lépésben visszafejtett lenyomattal

A két legelterjedtebb aszimmetrikus kulcsú titkosításra és hitelesítésre szolgáló rendszer az S/MIME (Secure / Multipurpose Internet Mail Extensions), valamint az OpenPGP (Open Pretty Good Privacy).

Öntsünk tiszta vizet, a nyílt lapok közé

Mielőtt aszimmetrikus kulcsú rendszereket használhatnánk, szükségünk van minden partnerünk publikus kulcsára. A publikus kulcsokat mindenki maga terjesztheti (S/MIME esetén az aláírás maga tartalmazza a publikus kulcsot), vagy központi szerverekről tölthetőek le (PGP). A publikus kulcsok megszerzése után használhatjuk a rendszert, de még mindig nem lehet teljes örömünk.

Egy publikus kulcs önmagában nem szolgálhat egy személy azonosítására. A publikus kulcs csak a hozzá tartozó privát kulcs birtokosát azonosíthatja.

Ezen probléma megoldására a ma használatos rendszerek a publikus kulcsokban tartalmaznak egy identity certificate részt. Az identity certificate a publikus kulcshoz tartozó privát kulcs tulajdonosának személyes adatait tartalmazza, például e-mail címet, nevet, etc., így hozzárendelve azt egy valóságos személyhez. Ne nyugodjunk meg, egyre közelebb kerülünk a megoldáshoz, de még egy dolog hátra van.

Kulcs generálásakor ezen adatokat mi adjuk meg a generáló programnak. Semmi se akadályozza meg a rosszindulatú támadót, hogy nevünkben maga generáljon kulcspárt, és feltöltse a publikus kulcsot egy központi szerverre, így Malory bármikor kiadhatja magát Alicenek, ha Bob korábban nem mentette el Alice valódi publikus kulcsát. Ezen probléma megoldására sajnos elengedhetetlen egy harmadik, megbízható fél bevonása. Ezt a harmadik felet hívjuk CA-nak (Certificate Authority). A CA-k vagy saját maguk generálnak kulcspárt nekünk, vagy meglévő publikus kulcsunk által tartalmazott identity certificate részt hitelesítik saját kulcsukkal, természetesen oly módon, hogy előtte megbizonyosodnak valódi kilétünkben. Ez történhet személyes találkozóval, vagy valamilyen hivatalos szerv közbenjárásával (ezen utóbbi módszer pontos lefolyását nem ismerem). Kérdezhetné valaki, aki eddig nem kavarodott össze, hogy levelező kliensem honnan tudja, hogy egy CA megbízható, vagy sem. Ki az, aki biztosítja, hogy egy CA által kibocsátott certificate valóban hiteles. Legjobb tudásom szerint ezen szervezeteknek komoly előírásoknak kell megfelelniük, és természetesen saját érdekük, hogy az általuk kiadott certificate hiteles legyen, hiszen ebből élnek. Minden levelező kliens gyártó maga dönti el, hogy mely CA-k certificate-jében bízik meg szoftverük a felhasználók tudta nélkül. Természetesen leellenőrizhetjük minden kliensben, mozilla/thunderbird-ben így: edit/advanced/encryption/view certificates/authorities.

Itt több linket találhatunk CA-k honlapjára, ezek nagy része pénz ellenében hitelesít minket, de létezik néhány ingyenes szolgáltatást nyújtó szervezet is.

Magunk is állíthatunk fel CA-t, például az openssl program segítségével, és hitelesíthetjük kulcspárjainkat, ezután már csak meg kell győzni néhány ismerősünket, hogy importálja saját CA-nk certificate-jét, esetleg az outlook fejlesztőivel felvenni a kapcsolatot. (a lincselés elkerülésének érdekében: utóbbit annyira se gondoltam komolyan, mint az előbbit)

Szeretnék gratulálni mindazoknak, akik végigolvasták az amúgy több bejegyzést igénylő szösszenetet, remélem elnézőek lesznek velem, a végére én is elfáradtam.

Titkosított fájlrendszer 1. ( pendrive )

Posted by tacsko as GNU/Linux, biztonság, privacy, tech, ubuntu

Korábban már volt szó a biztonságos adatmegsemmisítésről, hát most vessünk pár pillantást a biztonságos adattárolás témakörére. Bemelegítésként a kis méretű usb-re csatlakoztatható eszközökkel foglalkozok, mivel ezek elvesztése a legvalószínűbb, ennek ellenére rákényszerülünk, hogy érzékeny információt hordozzunk rajtuk.

Több megoldás is született az évek során, választásom a LUKS-ra esett. Titkosított fájlrendszer használata során a 2.6-os kerneltől támogatott dm-crypt-et használjuk. A dm-crypt (device-mapper crypto target) egy virtuális eszközt hoz létre a /dev/mapper könyvtárba, melyet minden nehézség nélkül úgy használhatunk, mint bármely más eszközünket. Ha a virtuális eszközre írunk, az valójában titkosítva kerül tárolásra a valódi eszközön, míg ha olvasunk, akkor kititkosítva kapjuk meg az adatot.

Nézzük hogyan titkosítsunk Gutsy Gibbon alatt.

Szükséges csomagok, kernel modulok:

Szükségünk lesz a cryptsetup programra, mely támogatja a LUKS funkciókat, valamint a dm-crypt és a titkosító algoritmus modulokra.

sudo apt-get install cryptsetup

sudo modprobe dm-mod

sudo modprobe dm-crypt

sudo modprobe aes

A cryptsetup installálását követő újraindításokkor a szükséges modulok autómatikusan betöltésre kerülnek, ha ez mégsem történne meg, adjuk azokat hozzá az /etc/modules fájlhoz.

Beállítás:

Ahogy azt már korábban megtanultuk, először minden adatot biztonságosan eltávolítunk az eszközről a shred program segítségével. Az én esetemben a pendrive a /dev/sdb eszköz.

sudo shred /dev/sdb -v

Következhet a tároló formatálása, LUKS partíció létrehozása.

cryptsetup –verify-passphrase –verbose –hash=sha256 –cipher=aes-cbc-essiv:sha256 –key-size=256 luksFormat /dev/sdb

WARNING!
========
This will overwrite data on /dev/sdb irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Az így elkészített partíciót megnyitjuk a dm-crypt segítségével, hogy az használható legyen a rendszer számára.

cryptsetup -v luksOpen /dev/sdb crypted-drive
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

Ha sikeres volt a megnyitás, a virtuális eszközt láthatjuk a /dev/mapper könyvtárban. A kititkosított partíción létrehozhatjuk a későbbiekben használni kívánt partíciónkat. Az én esetemben ez vfat lesz, így windows alól is elérhetőek lesznek adataim.

mkfs.vfat /dev/mapper/crypted-drive -v
mkfs.vfat 2.11 (12 Mar 2005)
/dev/mapper/crypted-drive has 0 heads and 0 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 495896 sectors;
file system has 2 16-bit FATs and 8 sectors per cluster.
FAT size is 242 sectors, and provides 61922 clusters.
Root directory contains 512 slots.
Volume ID is 474c1e1b, no volume label.

Távolítsuk el virtuális eszközünket.

cryptsetup luksClose crypted-drive

Mostantól minden adat titkosítva lesz tárolva eszközünkön. Gnome környezetben a rendszer autómatikusan felismeri az eszközt, csatolása nem jelenthet problémát. Más rendszereken csatoláshoz és leválasztáshoz a következő parancsokat használhatjuk.

csatolás:
cryptsetup luksOpen /dev/sdb crypted-drive
mount /dev/mapper/crypted-drive /mnt -tvfat
leválasztás:
umount /mnt
cryptsetup luksClose /dev/mapper/crypted-drive

A meghajtót windows alatt a FreeOTFE program segítségével használhatjuk. A legjobb megoldás, ha az eszközön két partíciót hozunk létre, az egyik egy nem titkosított vfat partíció, melyre a FreeOTFE-t másoljuk, a másik pedig a titkosított partíció. Ily módon windows környezetben is használhatjuk adathordozónkat.

Jó titkosítást!

Biztonságos adatmegsemmisítés, shred

Posted by tacsko as GNU/Linux, biztonság, privacy, tech

Milyen adatokat tárolsz a merevlemezeden? A kérdésre a válasz talán még kétségbe ejtőbb, mint az eddig feszegetett hálózati forgalom témakör esetén. Sokszor annyi adatot tárolunk gépünkön, hogy meg is feledkezünk néhány nagyon érzékeny darabkájáról, nem is beszélve az egyéb programok által tudtunkon kívül elmentett információról, mint például internetes kapcsolataink, levelezésünk, az általunk látogatott honlapok listája, vagy kritikus esetben jelszavaink. Belegondolni is rossz, mivel nézhetünk szembe, ha rossz kezekbe kerül ilyen mennyiségű személyes információ.

Ha el szeretnénk adni merevlemezünket, formatáljuk azt, ha tönkremegy, meggontolatlanul kidobjuk. Mindkét esetben óriási hibát követünk el.

Amikor formatáljuk háttértárolónkat, vagy fájlokat törlünk róla, az adatok valójában érintetlenül megmaradnak, és azok visszaállítása nem jelent problémát különleges felszerelés nélkül sem. Sokan felülírják a kritikus területet nullákkal, vagy más adatokkal, de ez sem tökéletes megoldás. Mindannyian hallottunk már a Kürt Zrt. mágikus erőkkel bíró adatvisszaállítóiról. Ezen problémára nyújt megoldást a shred nevű program, mely a megsemmisíteni kívánt fájlt többször felülírja véletlen és előre definiált adatokkal felváltva. A shred-et használhatjuk egész partíciókra is a /dev/hdax fájlok segítségével.

Kapcsolók nélküli futtatás esetén 25-ször írja felül az adott filet, és nem törli le a végén.

tacsko@titok:~/egyeb/temp/shred$ shred textfile -v
shred: textfile2: pass 1/25 (random)…
shred: textfile2: pass 2/25 (bbbbbb)…
shred: textfile2: pass 3/25 (6db6db)…
shred: textfile2: pass 4/25 (db6db6)…
shred: textfile2: pass 5/25 (dddddd)…
shred: textfile2: pass 6/25 (777777)…
shred: textfile2: pass 7/25 (666666)…
shred: textfile2: pass 8/25 (ffffff)…
shred: textfile2: pass 9/25 (888888)…
shred: textfile2: pass 10/25 (222222)…
shred: textfile2: pass 11/25 (333333)…
shred: textfile2: pass 12/25 (b6db6d)…
shred: textfile2: pass 13/25 (random)…
shred: textfile2: pass 14/25 (249249)…
shred: textfile2: pass 15/25 (555555)…
shred: textfile2: pass 16/25 (999999)…
shred: textfile2: pass 17/25 (924924)…
shred: textfile2: pass 18/25 (aaaaaa)…
shred: textfile2: pass 19/25 (111111)…
shred: textfile2: pass 20/25 (cccccc)…
shred: textfile2: pass 21/25 (eeeeee)…
shred: textfile2: pass 22/25 (000000)…
shred: textfile2: pass 23/25 (444444)…
shred: textfile2: pass 24/25 (492492)…
shred: textfile2: pass 25/25 (random)…

Amennyiben törlésre is szükségünk van a –purge kapcsolóval utasíthatjuk a programot, erre nincs lehetőségünk, ha egész partíciót akarunk megsemmisíteni. Ha nagyobb adatmennyiséget szeretnénk megsemmisíteni fontos lehet a felülírások számának felülbírálása a -n kapcsolóval, hogy csökkentsük a futási időt. A -z kapcsoló használata esetén az utolsó felülírást csupa nullával végzi a program.

Figyelem: Bizonyos fájlrendszerek (pl.: naplózó fájlrendszerek) esetén csak fájlokra alkalmazni a shred-et felelőtlenség, hiszen ilyenkor a fájlrendszer máshol is tárol információt a fájlokról, így lehetővé téve azok helyreállítását. Ilyen esetben mindig az egész partíció megsemmisítésére van szükség. További információ: man shred

Ha paranoid természetünk miatt ezután sem nyugszunk meg, a következő kisfilm által demonstrált módszert alkalmazzuk:shred it

Otr, az igazán privát csevegéshez

Posted by tacsko as biztonság, privacy

Te mit beszélsz meg barátaiddal, munkatársaiddal IM (instant messaging) programok segítségével?

Ha csak az elmúlt hét csevegéseit veszem sorba, és arra gondolok, hogy harmadik személy elolvashatja őket, kiráz a hideg. Pedig nagyon közel járunk az igazsághoz, ha így gondoljuk. Hogy bizonyítsam állításom, az általam leggyakrabban használt három IM által generált forgalmat néztem meg. A felvételeket a wireshark (régebben ethereal) nevű programmal készítettem.

Az elcsípett beszélgetések megtekintéséhez klikk a képekre.

A felvételek elkészítése három kattintásomba került, azt hiszem ez nem nagy energiabefektetés. Az icq és az msn magáért beszél, egyedül a jabber igényel egy kis magyarázatot. Első ránézésre azt mondhatjuk, hogy a jabber felvételen nem látunk semmit. Ez így is van, ennek egyetlen oka, hogy egy olyan jabber szerveren keresztül csevegtem, mely csak SSL titkosított csatornán hajlandó kommunikálni. Sajnos rengeteg olyan szerver van, ahol ez nem alapértelmezett, és ha egy picit figyelmetlenek vagyunk ugyanolyan jól olvasható forgalmat tárunk a közönség elé, mint a másik két protokoll esetében.

Sajnos van egy közös hátránya mind három protokollnak. Minden esetben kénytelenek vagyunk megbízni a szolgáltatást nyújtó szerverben. Még jabber és SSL kapcsolat esetén sem gátolja meg senki a szerver üzemeltetőjét, hogy beleolvasson beszélgetésünkbe.

Megoldás: OTR - Off The Record Messaging

Milyen szolgáltatásokat nyújt számunkra az Otr?

1. Titkosítás: Harmadik személy nem képes elolvasni üzeneteinket.
2. Autentikáció: Biztosak lehetünk benne, hogy a beszélgető partner valóban az, akinek hisszük.
3. Letagadhatóság: Az általunk elküldött üzenetek nem tartalmaznak digitális aláírást amit később leellenőrizhetnek. A beszélgetés lezajlása után bárki készíthet üzeneteket, melyek úgy tűnnek, mintha magunk küldtük volna azokat, de egy beszélgetés során mindig biztosak lehetünk beszélgető partnerünk kilétében, valamint abban, hogy üzeneteink titkosítva vannak, és módosítás nélkül érik el céljukat.
4. PFS (Perfect Forward Secrecy): Privát kulcsunk elvesztése esetén is titkosak maradnak korábbi beszélgetéseink.

Beállítás Gutsy Gibbon alatt

Az Otr beállítása nagyon egyszerű, minden általam ismert im protokoll felett működik, nincs szükség új kliens telepítésére.

Kopete esetén mindössze egy csomag telepítésére van szükség.

apt-get install kopete-otr

Majd a Kopete/Settings/Configure Plugins menüben válasszuk ki az otr plugint.

Minden hozzáférésünkhöz külön generálhatunk kulcsot.

Otr-t nem csak kopete pluginként használhatunk. Hasonlóan egyszerű beállítása Pidgin (régebben Gaim) esetén. MacOSX felhasználók Adium kliense is képes OTR használatára, windows esetén pedig Trillian, Miranda és ugyancsak Pidgin áll rendelkezésünkre.

Anonim internet, tor ( Internet jövőkép 1. )

Posted by tacsko as hálózat, privacy, tech

Ez a bejegyzés, egy hosszabb sorozat első része, melyben az internet jelenlegi problémáit, azok megoldásait és lehetséges jövőjét ecsetelem.

Miért fontos az anonimitás?

A kritikus adatforgalmat mindenki titkosított csatornán bonyolítja. Azonban arról megfeledkezünk, hogy bár a titkosított adatból nem, vagy nagyon nehezen lehet információt kinyerni, magából a kapcsolat létéből következtetni lehet számos, nem feltétlenül publikus adatra (traffic analysis). Bár a csomagok tartalmát nem tudja elolvasni egy támadó, annak forrását és célját proléma nélkül meghatározhatja.

Kiknek fontos az anonimitás?

Félreértés ne essék, én nem támadóknak szeretnék bemutatni egy újabb módszert kilétük elrejtésére. Bárki használhatja, aki nem szeretné, hogy az általa látogatott oldalak tudomást szerezzenek kilétükről. Bizonyos esetekben fontos, hogy a látogatott chatszobákból ne lehessen következtetéseket levonni személyes információkra (különböző betegségekben szenvedők). Nem véletlenül alakultak az anonim klubok, mint például az anonim alkoholisták mozgalma.

Hogy oldható meg?

Képzeljünk el egy elosztott hálózatot az interneten. Rengeteg önkéntes felállít átjárókat a nemes ügy érdekében, melyek egymástól tökéletesen függetlenül helyezkednek el. Amint egy felhasználó kapcsolatot szeretne kezdeményezni valaki felé, azt nem közvetlenül teszi meg, hanem az átjárókból álló hálózathoz fordul, ahol egy véletlenszerű útvonal alakul ki a gépek között úgy, hogy mindenki csak a szomszédját ismeri. Végül a célgép azt látja, hogy a hálózat utolsó átjárója kapcsolódott hozzá, így elfedve kilétünket.

Az útvonal bizonyos időközönként, és új kapcsolat kialakításakor változik. Ez még mindig nem biztosít teljes védelmet számunkra, hiszen a végpontokból kiindulva visszanyomozható az eredeti kezdeményező. Ennek kiküszöbölésére az átjárókat úgy alakították ki, hogy azok ne tároljanak információt az útvonalakról, rendszeresen törlik naplójukat.

Tor

Szerencsére ezt a nagyon jó elképzelést meg is valósították a tor project keretein belül. A program elérhető Linux, Mac OS X, windows platformokra. Én Ubuntu linux alatt firefox böngészővel teszteltem.

Telepítés Ubuntu Gutsy Gibbon-ra

apt-get install tor privoxy

A privoxy egy gyors kisméretű web proxy, melyet könnyű összekapcsolni tor kliensünkel.

A firefoxnak szüksége van továbbá egy pluginra, mellyel könnyen menedzselhető tor kliensünk használata.torbutton

Privoxy beállítása:

vi /etc/privoxy/conf

Kommenteljük ki a következő sorokat:

logfile logfile

jarfile jarfile

Majd adjuk a fájlhoz a következő sort:

forward-socks4a / 127.0.0.1:9050 .

(A sor végén található pontot ne hagyjuk le.)

Indítsuk újra a privoxy-t:

/etc/init.d/privoxy restart

Ha a torbutton installálása után újraindítottuk böngészőnket, a jobb alsó sarokban a Tor Disabled feliratot látjuk. Kattintsunk a feliratra, és már böngészhetünk is.

Lehetőségek

Természetesen a tor-t nem csak böngészéskor használhatjuk. Bármely szoftverhez illeszthető, mely SOCKS proxyt képes használni. Sajátos kialakításának köszönhetően nem csak kilétünket képes elrejteni. Segítségével olyan oldalakat látogathatunk, melyeket helyi internetszolgáltatónk blokkol. Szervereket állíthatunk fel anélkül, hogy azok pontos helyét kideríthessék. Hidden Services for Tor

Végül…

Az anonimitás kulcsfontosságú tényezője szabdságunknak, gondoljunk a legtriviálisabb példára, a választásokra. Az interneten sincs ez másképp, a teljes szabadsághoz elengedhetetlen.

Ha valakit meghatottam, és égető vágyat érez, hogy segítse a tor projectet, megteheti átjáró szerverek felállításával.