# Tor ## Hva det er Tor skjuler hvem som snakker med hvem for alle som lytter på linjen, ved å sende hver forbindelse gjennom en kjede av maskiner der ingen enkelt maskin kjenner både starten og slutten. Kjeden velges av klienten, et program som heter tor og kjører på leserens egen datamaskin, og den er som regel tre reléer lang: en vakt (_guard_) som klienten bruker om igjen som inngang, et mellomrelé og et utgangsrelé (_exit_) som tar den siste forbindelsen til målet. Klienten bygger denne kretsen ett ledd om gangen og forhandler fram en egen nøkkel med hvert relé. Deretter pakker den hver bit data inn i ett krypteringslag per ledd. Hvert relé skreller av sitt eget lag og får bare vite hvem som kom før, og hvem som kommer etter. Lagene inni hverandre er løken i tittelen på designartikkelen, The Second-Generation Onion Router. I dagligtale er reléene samlet Tor-nettverket, tor med liten forbokstav er programmet, og Tor Browser er nettleseren som er pakket for å bruke det. Data flyttes i celler med fast størrelse, så et relé ser en strøm av like store blokker i stedet for formen på de opprinnelige nettverkspakkene. Mange TCP-forbindelser deler én krets: nye forbindelser gjenbruker den i ca. ti minutter før klienten bygger en ny, mens en lang forbindelse blir værende der den startet. Applikasjonene når klienten gjennom en lokal SOCKS-proxy, og bare TCP går denne veien; designartikkelen sier rett ut at den ikke tunnelerer protokoller som UDP. Frivillige driver reléene, og hvert av dem publiserer en beskrivelse med nøkler, adresse, båndbredde og utgangsregler (_exit policy_). Et lite sett katalogautoriteter stemmer over hvilke reléer som skal listes, og signerer resultatet som et konsensusdokument som hver klient henter før den velger rute. ## Hvorfor det er viktig For den som driver et offentlig nettsted, er Tor først og fremst et faktum om publikum. En leser som kommer over Tor, ser ut til å komme fra adressen til et utgangsrelé og ikke fra sin egen, og listen over reléer er offentlig med vilje, fordi hver klient trenger den for å velge rute. Et nettsted kan altså kjenne igjen Tor-trafikk og behandle den annerledes. Tor Project står selv på at operatører har rett til å blokkere den, selv om prosjektet håper de lar være. Det du da må avgjøre, er hva du gjør med disse leserne: betjener dem som alle andre, bremser dem, setter en utfordring foran dem eller gir dem en vei inn som aldri forlater Tor-nettverket, og det siste er det en onion-adresse gjør. Det lønner seg å være presis om hva Tor lover, for designartikkelen lister selv opp det som er holdt utenfor. Den hevder ikke å slå en observatør som kan se begge ender av en forbindelse og sammenligne tidspunkter og volum, og prosjektets dokumentasjon legger til at forskerne ikke kjenner noe praktisk design med lav latens som klarer det pålitelig. Tor prøver heller ikke å skjule at noen bruker Tor, bare hva de bruker det til. Og den siste strekningen, fra utgangsreléet til målet, krypteres ikke. Sammenlignet med et VPN er tilliten fordelt annerledes. En VPN-leverandør ser både brukeren og målet og blir bedt om å se bort. På Tor ser ingen enkelt relé begge deler, og klienten nekter å sette to reléer fra samme erklærte familie, eller fra samme /16 av IPv4-adresser, på én rute. Prisen er latens, siden hver forespørsel krysser tre frivillige maskiner, så sider som er lette og trenger få rundturer, fungerer best for lesere over Tor. Å tilby en onion-adresse koster én daemon til, én privat nøkkel til å passe på og ingen åpen innkommende nettverksport, og derfor får det plass på liten infrastruktur. ## Slik ser det ut i praksis Selskapets eget nettsted kan leses over Tor. [Kommandolinjesiden](/nb/cli/) publiserer onion-adressen ved siden av en `curl`-kommando som henter Markdown-teksten gjennom en lokal tor-klient. Adressen er vanlig `http://` med vilje: en onion-adresse er tjenestens egen offentlige nøkkel, så kretsen er autentisert og kryptert før det i det hele tatt snakkes HTTP, og et sertifikat ville bare bevise på nytt det adressen allerede beviser. Om selskapets eneste produksjonsvert også kunne bære onion-tjenesten, ble avgjort med målinger og ikke med synsing. Verten har én kjerne og rundt 464 MB brukbart minne, og den terminerer allerede TLS for sju domener og kjører en git-forge. [Et døgn med målinger på verten med 512 MB](/nb/portfolio/ran-the-whole-company-on-one-512mb-host-109/) ga svaret: selv på det laveste var rundt 310 MB av de 464 tilgjengelig, og prosessoren var ledig 99,7 % av tiden, med swap på 2,6 %. [Personvernsiden](/nb/privacy/) slår fast hva som følger av å åpne den døren. Gemini- og Gopher-kopiene av nettstedet har en daglig opptelling av forespørsler og ingenting annet. Over Tor telles ingenting i det hele tatt, og det finnes ingen innstilling som ville tillatt det, fordi det å vite hvem som leste en onion-adresse, er nettopp det protokollen finnes for å hindre. Siden sier at selskapet heller vil la være å vite enn å kunne vite. ## Hvor det går galt **Navnet slås opp utenfor Tor.** Et program som sender forbindelsene sine til en SOCKS-proxy, kan likevel slå opp vertsnavnet selv først, gjennom den vanlige navneoppslagstjenesten, og det oppslaget forteller det lokale nettverket og DNS-leverandøren hvilket nettsted som besøkes. Forbindelsen går deretter gjennom Tor, men målet har allerede lekket. I `curl` er forskjellen ett eneste valg: med `--socks5` slås navnet opp lokalt, med `--socks5-hostname` overlates det til proxyen, og utgangsreléet slår det opp. ```sh # Slår opp navnet lokalt, kobler så til gjennom proxyen curl -s --socks5 127.0.0.1:9050 https://example.org/ # Gir navnet til tor; utgangsreléet slår det opp curl -s --socks5-hostname 127.0.0.1:9050 https://example.org/ ``` **Klartekst etter utgangen.** Tor krypterer leddene mellom reléene, men det siste leddet går som det er. Utgangsreléet åpner en vanlig TCP-forbindelse til målet og sender det applikasjonen ga det, så et innloggingsskjema som sendes over vanlig HTTP, kan leses av den som driver utgangsreléet, og av alle på nettet bortenfor. Lever HTTPS for alt som forlater Tor-nettverket. En onion-tjeneste slipper unna spørsmålet, fordi trafikken dens aldri forlater nettverket. **Én adresse står for mange lesere.** Grenser for antall forespørsler og utestenginger knyttet til klientadressen behandler et utgangsrelé som én besøkende, selv om mange bruker det samtidig. En grense tilpasset én person stenger ute alle hvis krets tilfeldigvis ender der, og en utestenging som én misbruker har gjort seg fortjent til, rammer dem alle. Bestem med vilje hvordan utgangsadresser skal behandles, i stedet for å la en generell regel per adresse bestemme for deg. **Identiteten reiser inne i kretsen.** Tor skjuler nettverksadressen og gjør ingenting med det applikasjonen sier. En innlogging på en personlig konto, et særpreget nettleseroppsett eller et dokument som henter noe når det åpnes, knytter økten til en person, uansett hvor mange reléer som ligger imellom. Prosjektets egen dokumentasjon påpeker at applikasjonstrafikken fortsatt må renses på brukerens side. Den jobben tar Tor Browser på seg, og den blir liggende når en vanlig nettleser bare pekes mot proxyen. **Et utgangsrelé på en hjemmelinje.** Vakt- og mellomreléer trekker sjelden til seg klager på misbruk. Utgangen er der målene ser trafikken komme fra, så klager og en og annen juridisk henvendelse går til den som driver den, og relé-veiledningen fra Tor Project sier at du ikke bør drive en utgang hjemmefra. En frivillig med én hjemmeadresse kan heller drive en bro (_bridge_), et relé som står utenfor den offentlige listen, og som den samme veiledningen anbefaler i den situasjonen. **Forventningen om at UDP skal virke.** Taleanrop, mange spill og verktøy som sender egne DNS-spørringer, er avhengige av UDP, og Tor frakter bare TCP-strømmer. Slike programmer går ikke gjennom Tor, og et program som ikke tvinges gjennom proxyen, kan rett og slett koble direkte til, utenfor Tor, uten å si fra. ## Les mer - [Tor Specifications](https://spec.torproject.org/) — protokollen, rutevalget, katalogen og spesifikasjonene for onion-tjenester, samlet på ett sted. - [Tor: The Second-Generation Onion Router](https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.pdf) — designartikkelen: kretser, celler, utgangsregler og en uttrykkelig liste over det designet ikke prøver på. - [Tor Path Specification](https://spec.torproject.org/path-spec/) — hvordan en klient velger vakt, mellomrelé og utgang, og hvilke reléer som ikke får dele rute. - [Types of relays on the Tor network](https://community.torproject.org/relay/types-of-relays/) — vakt-, mellom-, utgangs- og broreléer, med den juridiske risikoen hvert av dem gir den som driver det. - [HTTPS encryption and Tor](https://support.torproject.org/about-tor/security/https-encryption-and-tor/) — en interaktiv visning av hva en avlytter ser med Tor, med HTTPS, med begge og med ingen av dem.