# Tor ## Vad det är Med Tor får den som avlyssnar en förbindelse inte veta vem som talar med vem. Varje anslutning skickas genom en kedja av maskiner, och ingen av dem känner till både var trafiken började och var den slutar. Kedjan väljs av klienten, ett program som heter tor och körs på läsarens egen dator, och den är oftast tre reläer lång: en vakt (guard) som klienten återanvänder som sin väg in, ett mellanrelä och ett utgångsrelä (exit) som öppnar den sista anslutningen till målet. Klienten bygger kretsen ett steg i taget och kommer överens om en separat nyckel med varje relä. Sedan lindar den in varje bit data i ett krypteringslager per steg. Varje relä skalar av sitt eget lager och får bara veta vilken granne som kom före och vilken som kommer efter. De kapslade lagren är löken i namnet på designartikeln, The Second-Generation Onion Router. I vardagligt tal är reläerna tillsammans Tor-nätverket, tor med gemener är programmet och Tor Browser är webbläsaren som är paketerad för att använda det. Data färdas i celler av fast storlek, så ett relä ser en ström av likformiga block i stället för formen på de ursprungliga paketen. Många TCP-anslutningar delar en krets: nya anslutningar återanvänder den i ungefär tio minuter innan klienten bygger en ny, medan en lång anslutning stannar där den började. Applikationer når klienten via en lokal SOCKS-proxy, och bara TCP tar den vägen. Designartikeln säger rakt ut att den inte tunnlar protokoll som UDP. Frivilliga kör reläerna, och vart och ett publicerar en beskrivning (descriptor) med sina nycklar, sin adress, sin bandbredd och sin utgångspolicy (exit policy). Ett litet antal katalogauktoriteter (directory authorities) röstar om vilka reläer som ska listas och signerar resultatet som ett konsensusdokument, som varje klient hämtar innan den väljer väg. ## Varför det spelar roll För den som driver en publik webbplats är Tor först och främst ett faktum om publiken. En läsare som kommer via Tor ser ut att komma från ett utgångsreläs adress och inte från sin egen, och listan över reläer är publik med flit, eftersom varje klient behöver den för att välja väg. En webbplats kan alltså känna igen trafik från Tor och behandla den annorlunda. Tor Project står själv på att den som driver en webbplats har rätt att blockera den, även om projektet hoppas att det inte sker. Beslutet som återstår gäller vad ni gör med de läsarna: betjänar dem som alla andra, bromsar dem, ställer en utmaning framför dem eller ger dem en väg in som aldrig lämnar Tor-nätverket, vilket är precis vad en onion-adress gör. Det lönar sig att vara noga med vad Tor lovar, eftersom designartikeln räknar upp vad den lämnar utanför. Den gör inte anspråk på att stå emot en observatör som kan se båda ändarna av en anslutning och jämföra tidpunkter och volym, och projektets dokumentation tillägger att forskarna inte känner till någon praktisk design med låg latens som klarar det på ett tillförlitligt sätt. Tor försöker inte dölja att någon använder Tor, bara vad den personen använder det till. Och Tor krypterar inte den sista sträckan, från utgångsreläet till målet. Jämfört med ett VPN är förtroendet ordnat på ett annat sätt. En VPN-leverantör ser både användaren och målet och ombeds titta bort. I Tor ser inget enskilt relä båda, och klienten vägrar att lägga två reläer ur samma deklarerade familj, eller ur samma /16 av IPv4-adresser, på en och samma väg. Priset är latens, eftersom varje begäran passerar tre frivilliga maskiner, så sidor som är lätta och klarar sig med få förfrågningar fram och tillbaka fungerar bäst för läsare över Tor. En onion-adress kostar en daemon till, en privat nyckel till att skydda och ingen öppen inkommande port, och därför ryms den på liten infrastruktur. ## Så ser det ut i praktiken Företagets egen webbplats går att läsa över Tor. [Kommandoradssidan](/sv/cli/) publicerar onion-adressen bredvid ett `curl`-kommando som hämtar texten i Markdown via en lokal tor-klient. Adressen är med avsikt vanlig `http://`. En onion-adress är tjänstens egen publika nyckel, så kretsen är autentiserad och krypterad innan något HTTP alls talas, och ett certifikat skulle bara bevisa en gång till det som adressen redan bevisar. Om företagets enda produktionsvärd också klarade onion-tjänsten avgjordes inte genom tyckande. Maskinen har en enda kärna och ungefär 464 MB användbart minne, och den terminerade redan TLS för sju domäner och körde en git-forge. [Ett dygns mätningar på värddatorn med 512 MB](/sv/portfolio/ran-the-whole-company-on-one-512mb-host-109/) gav svaret: under dygnet höll sig det tillgängliga minnet över ungefär 310 MB av de 464, swapen stannade vid 2,6 % och processorn vilade 99,7 % av tiden. [Integritetssidan](/sv/privacy/) skriver ner vad som följer av att öppna den dörren. Gemini- och Gopher-kopiorna av webbplatsen räknar hur många förfrågningar de besvarar per dag, och inget annat. Över Tor räknas ingenting alls, och det finns ingen inställning som skulle tillåta det, eftersom att veta vem som läste en onion-adress är just det som protokollet finns till för att förhindra. Där står också att företaget hellre inte vill veta än kunna veta. ## Var det går fel **Namnet slås upp utanför Tor.** Ett program som skickar sina anslutningar till en SOCKS-proxy kan ändå slå upp värdnamnet själv först, via den vanliga resolvern, och den uppslagningen talar om för det lokala nätverket och DNS-leverantören vilken webbplats som besöks. Anslutningen går sedan genom Tor, men målet har redan läckt. I `curl` skiljer en enda flagga: med `--socks5` slås namnet upp lokalt, med `--socks5-hostname` lämnas det till proxyn och utgångsreläet slår upp det. ```sh # Resolves the name locally, then connects through the proxy curl -s --socks5 127.0.0.1:9050 https://example.org/ # Hands the name to tor; the exit relay looks it up curl -s --socks5-hostname 127.0.0.1:9050 https://example.org/ ``` **Klartext efter utgången.** Tor krypterar stegen mellan reläerna, inte det sista. Utgångsreläet öppnar en vanlig TCP-anslutning till målet och skickar det som applikationen gav det, så ett inloggningsformulär som skickas över vanlig HTTP kan läsas av den som driver utgångsreläet och av vem som helst i nätet bortom det. Leverera HTTPS för allt som lämnar Tor-nätverket. En onion-tjänst kringgår frågan, eftersom dess trafik aldrig lämnar nätverket. **En adress står för många läsare.** Hastighetsbegränsningar och spärrar som utgår från klientens adress behandlar ett utgångsrelä som en enda besökare, fast många använder det samtidigt. En gräns som är inställd för en person stänger ute alla vars krets råkar sluta där, och en spärr som en enda missbrukare har förtjänat drabbar dem allihop. Bestäm medvetet hur utgångsadresser ska behandlas, i stället för att låta en generell regel per adress avgöra. **Identiteten färdas inuti kretsen.** Tor döljer nätverksadressen och gör ingenting åt vad applikationen säger. En inloggning på ett personligt konto, en webbläsare med en särpräglad uppsättning eller ett dokument som hämtar något när det öppnas knyter sessionen till en person, hur många reläer som än ligger emellan. Projektets egen dokumentation påpekar att trafiken från applikationen fortfarande måste rensas på användarens sida. Det är det jobbet som Tor Browser tar på sig och som en vanlig webbläsare som pekas mot proxyn inte gör. **Ett utgångsrelä på en hemuppkoppling.** Vakter och mellanreläer drar sällan på sig klagomål om missbruk. Utgången är det ställe som målen ser trafiken komma ifrån, så klagomålen och en och annan rättslig förfrågan hamnar hos den som driver den, och reläguiden från Tor Project säger att man inte ska köra ett utgångsrelä hemifrån. En frivillig med en enda hemadress kan köra en brygga (bridge) i stället, ett olistat relä som samma guide rekommenderar för just det läget. **Att räkna med att UDP fungerar.** Röstsamtal, många spel och verktyg som skickar sina egna DNS-frågor bygger på UDP, och Tor bär bara TCP-strömmar. Sådana program fungerar inte genom Tor, och ett program som inte tvingas genom proxyn kan helt enkelt ansluta direkt, utanför Tor, utan att säga något om det. ## Läs mer - [Tor Specifications](https://spec.torproject.org/) — protokollet, vägvalet, katalogen och specifikationerna för onion-tjänster samlade på ett ställe. - [Tor: The Second-Generation Onion Router](https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.pdf) — designartikeln: kretsar, celler, utgångspolicyer och en uttrycklig lista över vad designen inte försöker göra. - [Tor Path Specification](https://spec.torproject.org/path-spec/) — hur en klient väljer vakt, mellanrelä och utgång, och vilka reläer som inte får dela väg. - [Types of relays on the Tor network](https://community.torproject.org/relay/types-of-relays/) — vakter, mellanreläer, utgångsreläer och bryggor, med den rättsliga exponering som var och en innebär för den som driver den. - [HTTPS encryption and Tor](https://support.torproject.org/about-tor/security/https-encryption-and-tor/) — en interaktiv bild av vad en tjuvlyssnare ser med Tor, med HTTPS, med båda och med ingetdera.