Beveiligingsonderzoeker vindt Tor exit node die malware in binaries stopt

Een beveiligingsonderzoeker heeft ontdekt dat een exit node in het Tor-netwerk actief binaries onderschept en deze modificeert. Op deze manier kan een gebruiker bij het downloaden van bestanden van veilige servers alsnog besmet worden met malware.

Er zijn 1110 Tor exit nodes onderzocht door beveiligingsonderzoeker Josh Pitts van Leviathan Security Group. Eentje daarvan, gestationeerd in Rusland, bleek uit het internetverkeer actief binaries te onderscheppen om deze vervolgens te modificeren met eigen code. Volgens Pitts is de bewuste exit node in staat om malware aan een bestand toe te voegen zonder dat de gebruiker dit merkt.

Het onderzoek van Pitts toont aan dat gebruikers van Tor vatbaar zijn voor man-in-the-middle-aanvallen. Omdat de gebruiker denkt een bestand te downloaden van een veilige en betrouwbare server valt de malware-infectie niet op. Om de man-in-the-middle-aanvallen te voorkomen zouden gebruikers bij het downloaden van bestanden via een https-verbinding moeten werken.

Pitts stelt dat het Tor-project op de hoogte is gesteld van de malwareverspreidende exit node; deze is inmiddels aangemerkt als onbetrouwbaar, waardoor er geen verkeer meer door geleid wordt. Het is nog onduidelijk of Tor checks in gaat bouwen om modificaties van binaries onmogelijk te maken, al wordt er wel over nagedacht.

Reacties (51)

[Verwijderd]

Deze aanval werkt dus *niet* bij Windows updates of andere downloads waar enige vorm van authenticatie plaatsvindt of als er HTTPS gebruikt wordt. Dit is niet Tor specifiek, maar deze aanval werkt ook prima op publieke WLAN-netwerken bijvoorbeeld.

[Tantalus22]

Nieuwsgierig naar hoe een soortgelijke aanval werkt?
In 2012 demonstreerden twee Spaanse beveiligingsonderzoekers tijdens Defcon 20 hoe een proxy server kan worden ingericht om MITM attacks uit te voeren door twee regels JavaScript te injecteren in de browser. Hier een link naar deze vermakelijke presentatie.

[preske]

Wat het artikel hier niet vermeld is dat de getroffen binaries overigens window updates en allerhande antivirus updates/definities zijn.

Het nut van een windows of virus update via tor downloaden ontgaat mij eerlijk gezegd.

[Ramon]

Nee dat is niet waar. Dit is hoe de onderzoeker getest heeft. En als je het bron artikel een beetje leest, zie je dat het NIET werkt met Windows Update.

I tested BDFProxy against a number of binaries and update processes, including Microsoft Windows Automatic updates. The good news is that if an entity is actively patching Windows PE files for Windows Update, the update verification process detects it, and you will receive error code 0×80200053.

[hhoekstra]

Gebeurd automatisch lijkt mij ? Zodra jij de proxy van IE gaat aanpassen zal het verkeer van Windows update en de virusscanners hier ook overheen gaan.

Verder meen ik me te herinneren dat je geen plugins / javascript / andere meuk moet draaien om je "echte" ip adres te onthullen.

[freaky]

Het zit em niet zo in het nut van het downloaden van je update via TOR, het zit em in het standaard al het verkeer via TOR.

En MS ondertekend z'n updates met certificaten. Ramon geeft al aan dat het niet werkt, had heel vreemd staan kijken als het wel zo was geweest .

[papa_san]

Alle beveiliging binnen HTTPS/SSL is gericht op 'end to end' verbindingen, en bij tor zitter er verschillende hosts tussen. De afzonderlijke verbindingen zijn voor de buitenwacht geëncrypteerd, maar er is geen end to end verbinding tussen jouw en de server op het internet.
Dat waarborgt je anonimiteit maar geeft idd ruimte voor ongewenste manipulatie.

De enige oplossing die ik zie is om na een reconnect op het tor netwerk, en dus via een andere exit node, een checksum te downloaden.

Dat is natuurlijk niet gebruikersvriendelijk, maar waarschijnlijk de enige mogelijkheid.

[Reactie gewijzigd door papa_san op 26 juli 2024 00:13]

[bert_m]

Via TOR maak je reguliere TCP-verbindingen, die (versleuteld) worden getunneld over een aantal willekeurig gekozen nodes (meer specifiek: een guard node, een relay node en een exit node).
In die zin is het niet veel anders dan wat er normaal gesproken op het internet gebeurt: jouw verzoek gaat via de systemen van je ISP naar een exchange, naar de ISP van de ontvanger en dan naar de ontvanger. Bij TOR gebeurt hetzelfde, maar dan met een paar stappen meer

Op het internet kan elke tussenliggende router het verkeer manipuleren. In de praktijk gebeurt dat weinig (totalitaire regimes daargelaten), maar het is verre van onmogelijk. HTTP is in die zin altijd onveilig, omdat je niet zomaar kunt detecteren of er met het verkeer is gerommeld. Het grote verschil met TOR is dat nodes worden gedraaid door vrijwilligers in plaats van "betrouwbare" organisaties, en tussen deze vrijwilligers makkelijk een rotte appel kan zitten.

Echter, omdat TOR ook maar gewoon TCP-met-trucjes is, kan je gerust een SSL / TLS verbinding opzetten over TOR. Dat is ook wat er gebeurt als je via TOR een HTTPS-beveiligde website benadert. Dat biedt de veiligheid (zowel authenticiteit en integriteit!) die je van HTTPS gewend bent, met de anonimiteit van TOR (mits correct gebruikt). Natuurlijk, een tussenliggende node (bij TOR alleen de exit node) of tussenliggende router kan nog steeds het verkeer manipuleren, maar de browser zal dit nu detecteren en de gemanipuleerde gegevens weigeren.

Kortom: HTTPS is de oplossing.

[unglaublich]

Ze zouden toch gewoon vanaf de Tor entry over een tweede (willekeurig) kanaal een checksum/hash kunnen sturen? Dan is de kans vrijwel nul dat iemand in staat is die twee connecties te onderscheppen en on-the-fly nieuwe hashes toe te voegen.

Wel jammer dat hier blijkbaar helemaal niet over nagedacht is. Iemand gebruikt Tor- voor gevoelige zaken maar moet wel aannemen dat alle exit-nodes die gerund worden door onbekenden veilig zijn.

[Verwijderd]

Of gewoon HTTPS/TLS gebruiken.

[Alfa1970]

En iedereen met een geldig certificate kan je voor de gek houden.
Die groene balk in je browser is ook een wasse neus.
Die gaat op groen als het certificate is ondertekend door een van de grote ssl huizen zoals thawte/verisign et al.
En voor een paar honderd euro kan iedere ziel op de wereld dat regelen.
Dus elke crimineel kan dat ook, volledig legit.

[.oisyn]

Volgens mij snap je niet helemaal hoe certificaten werken. Klopt, iedereen kan certificaten aanvragen. Maar aan zo'n certificaat hangt een naam, en die naam moet overeenkomen met het domein dat het certificaat serveert. Jij kunt verkeer van tweakers.net niet ondertekenen met het certificaat van alfa1970.nl, want je browser slikt dat niet - de naam op het certificaat komt immers niet overeen met de host waar het verkeer (ogenschijnlijk) vandaan komt. En verisign gaat jou geen certificaat geven waar tweakers.net op staat, want jij komt niet door de validatiestap heen waarbij gecontroleerd wordt of jij dat domein wel daadwerkelijk in beheer hebt (en die validatie bestaat dan bijvoorbeeld uit het moeten zetten van een TXT record met een specifieke code erin op de name server van je domein, of het sturen van een mailtje naar de administrator die vermeld staat in de WHOIS records van het domein).

Zolang de web of trust niet gecompromitteerd is (ie., dat vertrouwde CA's niet zomaar willekeurige certificaten ondertekenen), de private keys niet gelekt zijn en er geen fouten zitten in de gebruikte cypher, is het praktisch onmogelijk on een man in the middle attack uit te voeren op SSL/TLS verkeer.

[Reactie gewijzigd door .oisyn op 26 juli 2024 00:13]

[Alfa1970]

Ik hoef geen certificate voor Tweakers aan te vragen om man in the middle te spelen met m'n proxy. Dat is het mooie ervan.
Een intermediate CA certificate van een willekeurig 10 euro domeintje is voldoende. Je kan voor niks een demo bij een registrar krijgen..

Zo lang je er maar voor zorgt dat aan het einde van de certificate chain de registrar staat.
Kan je dan voor elk willekeurig domein een certificate signen met dat intermediate, waar het ip adres van je proxy in staat met de domeinnaam van de ssl site die je wilt compromitteren.
Om dat de chain uitkomt bij een registrar die door elke willekeurige browser wordt getrust zal geen enkele browser alarm slaan daarover.

Het overgrote deel van bedrijven gebruiken dit principe in proxies van verschillende makelij om bijvoorbeeld anti-virus te doen in het SSL verkeer.

[Reactie gewijzigd door Alfa1970 op 26 juli 2024 00:13]

[.oisyn]

Een intermediate CA certificate van een willekeurig 10 euro domeintje is voldoende. Je kan voor niks een demo bij een registrar krijgen..

Daar kun je niets mee zonder de private key van die intermediate certificate. En die krijg je niet. En om een intermediate certificate te bemachtigen hoef je echt niet eerst een domein te registreren - die certificates kun je gewoon downloaden. Dat is ook het hele idee van certificates, die dingen zijn publiek zodat iedereen ze kan verifieren.

Het overgrote deel van bedrijven gebruiken dit principe in proxies van verschillende makelij om bijvoorbeeld anti-virus te doen in het SSL verkeer.

Klopt, en die gebruiken dus een self-signed certificate of CA die is uitgerold naar alle clients binnen dat bedrijf.
Een fatsoenlijke proxy gebruikt geen standaard certificate voor elke installatie, want dat zou uiteraard betekenen dat iedereen die die proxy gebruikt automatisch compromized is (want jij kunt die proxy ook installeren en dus achter de private key komen om zelf je certificates te ondertekenen, die worden vertrouwd door de clients binnen het netwerk). In plaats daarvan wordt er voor elke installatie een nieuwe key-pair en bijbehorend certificate gegenereerd. Dat certificate (waar alleen de public key in staat) wordt aan de trusted root CA's toegevoegd.

Een MITM attack is op die manier alleen mogelijk als je de private key van die specifieke proxy hebt bemachtigd.

[Reactie gewijzigd door .oisyn op 26 juli 2024 00:13]

[Alfa1970]

En om een intermediate certificate te bemachtigen hoef je echt niet eerst een domein te registreren - die certificates kun je gewoon downloaden. Dat is ook het hele idee van certificates, die dingen zijn publiek zodat iedereen ze kan verifieren.

Dat zijn de root CA certificates en geen intermediate CA certificates van een eigen domein.
Jij kan echt nergens een intermediate CA certificate van een registrar krijgen.

Je hebt wel degelijk een eigen domein nodig om een CA certificate te kunnen aanmaken bij een registrar. want aan een self signed heb je niets omdat die alarmbellen zal doen afgaan.

Klopt, en die gebruiken dus een self-signed certificate
of CA die is uitgerold naar alle clients binnen dat bedrijf.

Juist niet, want een self signed certificate is altijd zichtbaar als zodanig.
Zelfs als je die uitrolt naar de webbrowsers.

Tenzij je met self signed bedoeld een Certificate dat je met je eigen CA ondertekend en dat die CA een certificate heeft voor jouw eigen domein dat is ondertekend door de registrar.
In dat geval hoef je nl. je eigen certificate niet uit te rollen naar de clients, zolang de registrar maar het eindpunt in de certificate chain is.
En daar heb ik geen enkele key van de registrar voor nodig, alleen een beetje cash waarna zij mijn zelf gefabriceerde CSR gaan ondertekenen met hun eigen private key, zonder dat ik die nodig heb.

De MITM attack voer je uiteraard uit met je eigen transparante proxy.

[freaky]

Nee hoor hij gaat alleen op groen als het een EV certificaat betreft en niet bij DV of OV. CA's die EV uit mogen geven zit hard-coded in de browsers. Je kunt geen eigen CA installeren en daarmee EV's uitgeven waarbij de adres balk groen wordt, ook niet als dee CA geinstalleerd is op de computer/browser zelf.

En voor die paar honderd euro, want EV's zijn idd niet goedkoop, wordt de KvK, het bedrijfs telefoonnummer, adres gegevens e.d. geverifieerd en de enige aan wie ze EV's uitreiken zijn personen die op de KvK staan. Veel succes daarmee dus.

Weet niet waar jij je informatie vandaan haalt, maar ik zou iets beter zoeken...

[Monochrome]

Hier is wel degelijk over nagedacht, maar het zou zeer inefficient zijn om jouw oplossing te implementeren. Je vraagt het tor-netwerk namelijk om twee keer hetzelfde bestand te downloaden, wat zorgt voor extra bandwidth requirements bij de exit nodes. Tor zegt expliciet, wees voorzichtig met 'clearnet' connections en zorg dat hier niets vertrouwelijks over heen gaat. HTTPS is overigens nog steeds een oplossing hiervoor, aangezien er dan een beveiligde verbinding tussen gebruiker en website wordt opgezet, waarbij de hele tor-infrastructuur transparant is.

[Blokker_1999]

En waarom zou https veiliger zijn? Als ik uw vraag afvang en zelf weer doorstuur naar de server maar opnieuw aan u serveer vanop een https enabled webserver moet je al verdomd goed opletten wil je geen malware binnenhalen.

De enige oplossing zijn binaries/installers die digitaal ondertekend zijn. Spijtig genoeg zijn de benodigde certificaten niet gratis te verkrijgen.

[Croga]

En waarom zou https veiliger zijn? Als ik uw vraag afvang en zelf weer doorstuur naar de server maar opnieuw aan u serveer vanop een https enabled webserver moet je al verdomd goed opletten wil je geen malware binnenhalen.

De webserver die jij gebruikt kan mij niet het certificaat leveren van de webserver die ik aanspreek. Daarmee krijg ik dus in de moderne browser meteen een hele berg rode vlaggen.

Ja, het is mogelijk. En ja, de gemiddelde gebruiker heb je alsnog te pakken. Maar die gemiddelde gebruiker zit niet op TOR. De gemiddelde TOR gebruiker krijgt argwaan als hem zoiets gebeurt en zal de verbinding verbreken.

[Alfa1970]

Dat hoeft helemaal niet.
Zeker niet als het over een eigen webserver gaat, of een proxy, want proxies worden het meest gebruikt als man in the middle.

Het enige dat noodzakelijk is dat de proxy een eigen certificate serviced voor de site waar het over gaat die ondertekend is door een CA die vertrouwd wordt door jouw browser. Met één geldig intermediate CA certificate kun je dus het hele zogenaamd veilige SSL/HTTPS verhaal om zeep helpen.

Ieder Joe Smoe script kiddie kan dat.

Mensen moeten leren dat veiligheid op internet niet bestaat.

Als je iets veilig wilt hebben, dan moet je het in ieder geval zeer zeker niet aan het internet hangen.

[.oisyn]

Wat een onzin . Een proxy kan best een geldig certificaat serveren, alleen kan ie dat niet voor willekeurigewebsite.nl, want die CA's die door je browser vertrouwd worden geven die niet zomaar weg - daar gaat een stap van domain verification aan vooraf. Je zult dus op z'n minst over een gehackte CA moeten beschikken. Ik zeg dus niet dat het helemaal niet kan, maar wel dat niet "iedere Joe Smoe scriptkiddie" dat zomaar kan.

[Reactie gewijzigd door .oisyn op 26 juli 2024 00:13]

[freaky]

Enterprise netwerken werken veelal zo.

Het is alleen een kwestie van je eigen CA certificaat op die computer geinstalleerd krijgen. Als je een "echte" (globaal geaccepteerde) CA kunt kraken, nog beter.

[.oisyn]

Enterprise netwerken werken veelal zo.

Dat in een enterprise een proxy een self-signed certificate gebruikt die is uitgerold naar alle clients wil nog niet zeggen dat de attacker makkelijk bij de bijbehorende private key kan komen.

Als de private key dan uiteindelijk wel op straat ligt zijn de rapen gaar, maar dat geldt voor ieder certificaat.

[Reactie gewijzigd door .oisyn op 26 juli 2024 00:13]

[PizzaMan79]

Bij een gewone verbinding worden de pakketjes toch ook via allerlei nodes doorgestuurd? Zou daar dan niet een man in the middle aanval kunnen worden gedaan?

[.oisyn]

Binnen TOR in ieder geval niet, die data is geencrypt van jou tot aan de exit node. De exit node moet natuurlijk decrypten om het het gewone internet op te kunnen sturen. Tussen de exit node (en inclusief die node) en de uiteindelijke host kan natuurlijk wel een MITM aanval plaatsinvinden.

[Lapixx]

Een HTTPS verbinding is ook digitaal ondertekend. Een request "afvangen" gaat dus niet lukken zonder dat de gebruiker dit doorheeft, dan zou HTTPS een stuk minder vaak gebruikt worden.

De binary ondertekenen is ook een optie, maar dit werkt dan ook volgens (vrijwel) hetzelfde principe.

[Verwijderd]

Hier is wel degelijk over nagedacht, maar het zou zeer inefficient zijn om jouw oplossing te implementeren. Je vraagt het tor-netwerk namelijk om twee keer hetzelfde bestand te downloaden, wat zorgt voor extra bandwidth requirements bij de exit nodes.

Misschien begrijp ik het verkeerd. De eerste keer dat het bestand wordt gedownload door de "hacker", heeft het bestand een grootte van 100 bytes. Hij voegt daar 5 bytes aan toe met zijn malware. De tweede keer dat het bestand wordt gedownload, bevat het bestand 105 bytes. Dat zijn dus 2 verschillende bestanden, waardoor je niet kunt spreken over "twee keer hetzelfde bestand downloaden". Toch?

[frickY]

Het hele concept van Tor is zoveel mogelijk "mens in the middle" toevoegen. Dit lijkt me er een logisch gevolg van.
Het doel van Tor is meen ik anonimiteit, niet beveiliging.

[Reactie gewijzigd door frickY op 26 juli 2024 00:13]

[kipppertje]

Maar anonimiteit gaat hand in hand met beveiliging. Een beetje handig geschreven malware zou in staat moeten zijn om een gebruiker te ontmasken.
Op deze manier kunnen overheden heel gericht "de staatsvijanden" opsporen. Want juist deze groep maakt gebruik van het Tor project.

[Odyssey]

Verbeter mij als ik het mis heb, maar zorgde downloaden er niet voor dat je unanimiteit kwijt raakt?

[woekele]

Je kunt niet internetten zonder te downloaden (html/jpegs/css/javascript etc). Lijkt me beetje rare theorie dus.

[Verwijderd]

Zou er geen onderscheid moeten gemaakt worden tussen html/jpegs/css/javascript enerzijds en executable binaries die de gebruiker zelf zal uitvoeren anderzijds? Een .html bestand download en een .exe downloaden dat valt beiden onder downloaden maar na het downloaden is er een verschil.

[mhkool]

malware kun je in binaries maar ook in html, css en javascript stoppen.
Tor zal hoe dan ook iets moeten inbouwen om injecterende exit nodes te weren.
Ik wens de makers van Tor veel succes toe bij het bedenken van een goede oplossing.

[Verwijderd]

bestaat al lang. TLS/HTTPS. Simpel he? :-)

[Verwijderd]

Nee dat is idd onzin. Wanneer je bijvoorbeeld over tor een bestandje download gaat dat bestandje gewoon Door het tor netwerk en niet over free net dus no worries

[Cartman!]

Even opgezocht en volgens mij is vooral het idee erachter dat downloads/plugins etc kunnen zorgen dat, los van TOR, jouw IP-adres toch ergens anders terecht komt. Het is dus niet t downloaden zelf wat je IP prijsgeeft maar meer de download zelf die daarvoor kan gaan zorgen.

[keejoz]

Nee, die waarschuwing slaat op het feit dat sommige bestanden contact zoeken met buiten. Bv een pdf die images ophaalt op een webserver. Door het bestand te openen komt je werkelijke IP adres in hun server logs te staan omdat je PDF viewer niet geconfigureerd is om over Tor te werken.

[JAVE]

Als niet iedereen het doet wel

[runelaenen]

Ze zeiden dat over torrents downloaden je anonimiteit zou wegnemen al bleek dit niet waar te zijn en wilden ze enkel niet dat iedereen alle bandbreedte ging optorrenten Of dat is toch hoe ik het me herinner

[Monochrome]

Sommige torrent-software stuurt jouw ip-adres mee in requests naar trackers/peers. Hoewel je verbinding over tor loopt en anoniem is, geef je dus zelf in je pakketten je identiteit prijs.

De bandbreedte die p2p kost is inderdaad een probleem, maar dat is voor exit nodes op te lossen door p2p protocollen uit te schakelen.

[Verwijderd]

Verbeter mij als ik het mis heb, maar zorgde downloaden er niet voor dat je unanimiteit kwijt raakt?

Het is wetenschappelijk gezien onmogelijk om je unanimiteit kwijt te raken. Zelfs als je iets hebt gedownload, dan lukt het niet om je unanimiteit te downloaden. Zelfs als je je IP-adres per e-mail doorstuurt aan alle e-mailaccounts op de wereld, dan nog heb je je unanimiteit niet kwijtgeraakt.

[ro8in]

Tja dat is het nadeel aan Tor. Er zijn heel veel man in the middle, waarbij iedereen in principe gewoon wijzigingen aan het verkeer kan aanbrengen.

[bwerg]

Nouja, alleen aan het einde dus. Maar dat maakt het niet veel beter want elke verbinding loopt natuurlijk via een exit-node, dus daar gaat de stoute Russische meneer dan gewoon zitten.

[Durandal]

En dat is dus veel, veel minder danhet reguliere internet; nog veel meer man in the middle, en doorgaans geen encryptie.

We hebben dit gewoon nog niet meegemaakt. Nu we dit weten; beter opletten op de CRC verificatie codes, ook bij het reguliere net.

[freaky]

Vrij loze stelling.

Geen TOR:

Jij -> hoop hops -> eind bestemming

Wel TOR:

Jij -> hoop TOR nodes (welke bereikt worden via hops - maar altijd versleuteld) -> hoop hops (regulier verkeer zoals zonder TOR, kan versleuteld zijn (bijv https), maar hoeft niet) -> eind bestemming.

Aannemen dat de exit node een kortere afstand naar de eindbestemming heeft zal soms correct zijn, maar soms ook niet.

En misschien staat die exit node wel in China. Of bij de NSA zelf. Wie zal ik mijn verkeer vandaag eens laten sniffen. De NSA, China of de AIVD. Met TOR is alleen de afzender (hopelijk) onbekend.

Oh en die exit node kan natuurlijk gegarandeerd al je http cookies sniffen. Hoeft ie niet eerst voor in te breken op een lijn of voor bij de NSA te werken met wat taps her en der. Je kunt er maar rekening mee houden.

[bwerg]

Ja, maar ik vind mijn lokale netwerkbeheerder en ook de NSA toch minder dubieus dan een of andere Russische vent die gewoon een exit node opent met als doel een hele berg verbindingen te mitm-en en malware te injecteren.

Als je geen HTTPS (of varianten) gebruikt krijg je anonimiteit dus ten koste van integriteit.

[Reactie gewijzigd door bwerg op 26 juli 2024 00:13]

[blorf]

Als je geen HTTPS (of varianten) gebruikt krijg je anonimiteit dus ten koste van integriteit.

Dat idee vind ik iets propaganda-achtigs tegen anonimiteit hebben. Zwaaien met veiligheid als argument om privacy in te leveren is een trend.
Ik denk dat het meer zaak is de mogelijke activiteiten van malware te elimineren door een goed beveiligd eigen systeem, dus je security verplaatsen naar een ander level. Welke applicaties, devices en gebruikers krijgen welke permissies?
Iets "uitvoerbaars" downloaden van een openbare bron is altijd een risico. Ook bij een beveiligde verbinding bestaat nog steeds het risico dat de content van de aanbieder al eerder ergens mee is besmet. Die kan dan wel http-certificering toepassen maar daarmee neem je nog steeds een externe partij waarvan je het grootste deel niet kent in vertrouwen. Kortom: je weet nooit zeker dat wat je binnenhaalt ook is wat je denkt. Niemand vertrouwen, zelf controleren en zelf de risico's inperken lijkt mij de beste oplossing.

[bwerg]

Dat idee vind ik iets propaganda-achtigs tegen anonimiteit hebben. Zwaaien met veiligheid als argument om privacy in te leveren is een trend.

Ik zeg niet dat het éne beter is dan het ander. Maar de gedachte is vaak "gebruik Tor want meer privacy is beter" alsof het alleen wat toevoegd, terwijl je dus mogelijk dubieuze exit-nodes voor je kiezen krijgt, en je dus wel degelijk over de afweging moet nadenken. Vergelijkbaar met dat je sommige dingen misschien niet op een openbaar wifi-netwerk wil doen. Maar goed, dat geeft Tor zelf ook al wel aan.

Als je point-to-point-encryptie over Tor gebruikt heb je het beste van twee werelden. Helaas moet degene met wie je verbinding maakt dat ook ondersteunen.

En of je de andere partij kan vertrouwen is een probleem op een heel ander niveau. Misschien maak je wel op afstand verbinding met een eigen server (al kan je dan wel zorgen voor SSH) of vertrouw je de andere partij om een andere reden. Dat kan je normaalgesproken zelf afwegen maar als er iemand met de data op je verbinding kan prutsen ben je sowieso de sjaak. Nou heb je dat natuurlijk altijd als je verbinding niet versleuteld is maar je maakt het de enge mensen wel wat gemakkelijker doordat je vrijwillig van hun exit-node gebruik maakt.

[Reactie gewijzigd door bwerg op 26 juli 2024 00:13]

[Gomez12]

Reguliere net is veel meer directe verbindingen en veel minder concentratie van verkeer.

Tor-netwerk is (qua clearnet) gewoon een concentratie van verkeer op de exit-nodes.

Dus bij regulier inet moet je ontelbaar veel man in the middel hebben wil je enigszins effectief zijn, bij Tor ben je zo effectief.

[bwerg]

Nee, want daartegen heeft Tor encryptie. Alleen de exit-node ziet je data unencrypted, aangezien dat nou eenmaal de data is die uit de andere kant van de tunnel komt. Tenzij je verbinding op een hoger niveau ook nog encryptie gebruikt, natuurlijk, dan heb je nergens een probleem.

Ja, je kunt denial-of-service doen door de verbinding geheel te verbreken. Dan zal de verbinding wel een timeout geven en via een ander pad alsnog verbinden of zo, niet zo heel spannend lijkt me.

[Reactie gewijzigd door bwerg op 26 juli 2024 00:13]