Tor gir personvern bare under antagelse om at minst en node i den tilfeldig valgte kjeden ikke er angriperstyrt (siden vi snakker om trafikkanalyse, bare avlytting på trafikk inn og ut av denne noden, uten å prøve å dekryptere den, teller som "kontroll"). Dette er sannsynlig. Hvis angriperen kontrollerer, si 50% av alle noder, og nettleseren din bruker en kjede med lengde 5, så vinner angriperen med sannsynlighet 0,5 ⁵ = 1/32.

For å redusere slike angrep kan du konfigurere klienten din til å velge kjeder ikke-enhetlig, men i stedet for å håndheve en "global spredning" slik at kjeden vil gå gjennom noder i flere land som ikke liker hverandre.

Det gjør det ikke. Å kjøre et stort antall noder er en av Tor's største svakheter. Ved å feste kan du velge bestemte noder du vil bruke, men det er viktig å velge noder godt og å prøve å unngå å oppføre seg dårlig, ettersom en bane som er dirigert helt gjennom sammenstøtende noder, ikke er sikker, og hver sammenstøtende node reduserer den effektive sikkerheten.

Det er anstrengelser for å prøve å bedømme hvilke noder som fungerer bra ut fra hvor lenge de har eksistert, men en pasient og dyktig angriper kan filtrere inn mange noder over tid mens de er ganske vanskelig å oppdage.

Selv om hele overføringskjeden ikke er kompromittert, kan en viss forståelse oppnås ved å se på tidspunktet for pakker som går inn og ut av en node. Forsinkelser på overføringer kan hjelpe, men vil øke ventetiden og støttes for øyeblikket ikke av Tor.

Er det noen ikke-tekniske mottiltak, f.eks. ville noen gripe inn hvis 3000 nye mistenkelige noder ville dukke opp på AWS?

Ja. Det er systemer og personer som overvåker nettverket, og operatørene for katalogmyndighet vil blokkere flom av åpenbart mistenkelige nye stafetter. Dette skjer regelmessig med tvilsomme akademiske forskningsprosjekter, uvanlig sjenerøse nye stafettoperatører og mer skumle aktører.

Faktisk skjedde det hypotetiske scenariet ditt nesten bokstavelig i desember 2014. Noen gikk og fyrte opp 3300 stafetter på Googles skyservere av en eller annen grunn. Ingenting skjedde. stafettene ble blokkert; de mottok nesten ingen trafikk; og det er vanskelig å si hva operatørene til og med prøvde å oppnå.

RELAY_EARLY angrepet er sannsynligvis det verste eksemplet. I første halvdel av 2014, en angriper, tilsynelatende amerikanske akademiske / regjeringen forskere ved Carnegie Mellon University SEI CERT, kombinert hundre raske stafetter og en sikkerhetsfeil for å deanonymisere utallige brukere, noe som fører til flere arrestasjoner i USA og potensiell risiko fra enhver annen part registrerer trafikk på det tidspunktet.

I tillegg til å kjøre tusenvis av noder, vil en angriper måtte kjøre de tusenvis av noder i en lang tid fordi en del av beslutningsprosessen om hvilke noder som skal brukes anser konsensus vekt, som inkluderer oppetid som en faktor. I tillegg er det flagg som kan legges til noder av de høyest rangerte reléene (etter konsensus) som markerer et stafett som et dårlig stafett, noe som negativt påvirker hvor mye bruk det vil få.

Det meste av Tor's beskyttelse mot denne typen angrep vil være relatert til begrensningene for hvor gammelt et stafett må være for å få en betydelig del av trafikken.

Alle disse svarene er feil, til og med den mest oppstemte. Tor har flere spesifikke funksjoner som demper dette, kalt sybilangrep. Mens mellom- og utgangsstafetten kan byttes hvert 10. minutt, blir det første stafetten, vakten, veldig lenge hos deg. Dette sikrer at selv om en angriper oppretter et stort antall stafetter, vil de ikke være i stand til enkelt å få deg til å bruke stafetten deres.

Tenk deg at angriperen får sjansen til å kontrollere vakt og avslutte stafett. , og den sjansen bestemmes ut fra prosentandelen releer de kontrollerer. Vil du heller at de får et nytt skudd for å identifisere deg med liten sannsynlighet for suksess en gang hvert 10. minutt, eller en gang hvert år? Sistnevnte er hvordan Tor opererer, til tross for all feilinformasjonen ovenfor.

https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters

Jeg er en ny bruker, og kan derfor ikke legge til dette som en kommentar - men det er som svar på bruker1535427

(som kommentert av IceyEC for bruker1535427 innlegg) Tor bruker 3 x humle i en krets mellom deg og sluttserveren.

I noen tilfeller vil den bruke mer, for eksempel når du kobler til en "skjult tjeneste" eller ".onion Site", da dette bruker 3 x humle mellom deg og det som er referert til som et "møtested" (som bare er en annen normal reléknutepunkt i Tor-nettverket) pluss 3 ganger videre hopp fra "møtestedet" til sluttdestinasjonsserveren.
Men bortsett fra dette, er Tor hardkodet til å bruke 3 x humle.

I utgangspunktet kan dette virke kontraintuitivt - da jeg trodde dette selv. Det er imidlertid flere grunner til å holde den på 3 x humle.
Noen av disse årsakene (men ikke begrenset til) er:

1 - å øke antall humle gir latens, noe som påvirker hastigheter og brukervennlighet og brukeropplevelse negativt.

2 - (slags påfølgende fra årsak 1) Hvis det å øke humle for alle brukere bremser ting samlet sett, men "potensielt" kan legge til ekstra lag med sikkerhet, kan ikke et svar være det Tor tillater brukere å velge hvor mange humle de bruker for å lage kretsen deres på bekostning av høyere ventetid, hvis den enkelte anser utvekslingen akseptabel?
vel, faktisk nei. Dette vil bety at forskjellige brukere vil ha forskjellige "banelengder" og dermed vil servere være "et ekstra, potensielt identifiserende stykke informasjon" for eksempel, kanskje du er den eneste personen som spesifikt valgte å gå gjennom si 123 humle? hvis en angriper kunne bestemme antallet humle, kan de være i stand til å identifisere eller i det minste skille deg fra annen trafikk ved denne faktoren alene.
Kort fortalt er det dårlig å øke antall humle for hver krets, og det gir brukerne muligheten til å variere antall humle selv.

3 - som bringer meg til en annen grunn, tilsynelatende (og også mot-intuitiv), har tester vist at bruk av 4 eller flere humle i praksis faktisk ikke gir mer sikkerhet enn du ville fått med bare 3 x humle. I ettertid har kun 3 x humle teknisk sett den høyeste sikkerheten, samtidig som du gir raskere tilkoblinger (noe som er pent om du tenker på det!)

det viktige å ta bort fra dette er det:
- Så lenge en angriper IKKE styrer BEGGE "entry" OG "exit" noder,
- I tillegg til at sluttserveren din er enten en ".onion server", eller en " åpen webserver med HTTPS "

så er du relativt trygg. hvis angriperen kjenner både inngangs- og utgangsnodene, er spillet over. den beseirer hele poenget i Tor-nettverket.

Den eneste måten dette kan hjelpe en angriper er hvis de løp hver stafettknute, og videre at de var sikre på dette. Styrken til Tor er at en gitt node ikke vet om noden den videreformidler data til er en annen reléknute eller sluttbruker. Jeg kunne ikke finne informasjon online om Tor bruker et spesifisert antall hopp per tilkobling, for hvis for eksempel en angriper visste at Tor kobler 5 relénoder mellom en bruker og et endepunkt, og angriperen så 5 av deres relé noder i en kjede, ville de vite IP-en til sluttpunktet og brukeren.

Av denne grunn vil jeg gjette at Tor ikke bruker et konstant antall hopp.

Når det er sagt alt dette, hvis angriperen kjørte en utgangsnode og du brukte den til å koble til et vanlig HTTP-nettverksnettsted, ville de kunne se alle dataene du sendte over, selv om du selv ikke kan se IP-en til brukeren. / p>