die raven homepage
Informationen zum Betrieb eines eigenen Tor Routers stehen in der Übersicht Einen Tor Server konfigurieren und auf der Wikiseite TheOnionRouter/Tor4Windows.
Wenn man mindestens 20 Kilobytes/s an Bandbreite erübrigen kann, was bei heutigen *DSL Breitbandangeboten der Fall ist, kann man schon einen eigenen Tor Router als Middleman oder Exit Node stellen, auch mit dynamischer IP-Adresse. Ein Middleman Node ist ein Tor Router, der nur Daten von anderen Tor Netzknoten entgegennimmt und an andere Netzknoten weiterleitet, selbst aber keine Daten zum Zielrechner transportiert, während ein Tor Router, der auch als Exit Node arbeitet, Daten vom und zum eigentlichen Zielrechner transportiert.
Besteht die Befürchtung, einen Tor Exit Node zu betreiben, weil man z. B. Repressalien seitens Sicherheitsbehörden erwartet, die aus Unkenntnis der Rechtslage und der Funktionsweise des Tor Netzwerks heraus auf Tor Exit Node Betreiber zugreifen könnten, kann man den eigenen Tor Router auch nur als Middleman Node betreiben, indem die Exit Policy auf "reject *:*" gesetzt wird oder über mehrere Exit Policies die Weiterleitung bestimmter Protokolle einschränken.
Ist man bereit, einen Tor Exit Node zu stellen, sollte darauf geachtet werden, dass der Rechner, auf dem Tor läuft, gemäß der Operational Security Anleitung abgesichert ist. Es ist auch von Vorteil, wenn man für Tor einen eigenständigen Rechner abstellen kann, auf dem nur Tor als Server läuft, wenn Tor als Exit Node betrieben wird. Sollte es einmal zu Beschlagnahmungen kommen, kann darauf verwiesen werden, dass für die Beschlagnahmung nur der betreffende Rechner in Frage kommt.
Weitere nützliche Informationen und Ratschläge enthält u. a. die FAQ des Chaos Computer Club e.V. Berlin zum Betrieb von Anonymisierungsdiensten, hauptsächlich Tor, die sich im Wesentlichen auf die Situation in der BRD bezieht.
Die Umsetzung der EU-Richtlinie zur Vorratsdatenspeicherung im "Gesetz zur Neuregelung der Telekommunikationsüberwachung und anderer verdeckter Ermittlungsmaßnahmen sowie zur Umsetzung der Richtlinie 2006/24/EG" sieht eine Verpflichtung von Anonymisierungsdiensten zur Datenvorratsspeicherung vor, die zur "Speicherung der ursprünglichen und der neuen Angabe sowie des Zeitpunktes der Umschreibung dieser Angaben nach Datum und Uhrzeit unter Angabe der zugrunde liegenden Zeitzone" zwingt.
Siehe dazu auch den Beitrag "We are fucked individually!" – Konsequenzen für Administratoren öffentlich betriebener Anonymisierungs-Server im ravenhorst Weblog vom 20.11.2007.
Am sichersten, aber auch kostspielig, ist der Tor Exit Node Betrieb über einen Root-Server im Ausland, den man anonym anmieten und bezahlen kann.
Es wird von einem Windows XP Rechner ausgegangen, der sich hinter einem Hardware-Router befindet. Die Vorgehensweisen und Verhaltensregeln sind aber bei Linux und Mac OS Rechnern dieselben.
Auf dem Rechner läuft Tor bereits als Client und soll nun zusätzlich als Middleman Node agieren, d. h. Tor nimmt nur Daten von anderen Tor Nodes entgegen und gibt Daten an andere Tor Nodes (inklusive den Tor Exit Nodes) weiter. Auf dem Rechner befindet sich neben dem Administratorkonto mindestens ein Benutzerkonto, mit dem gearbeitet wird – der Rechner wird also online nicht mit dem Administratorkonto benutzt, was eine Selbstverständlichkeit sein sollte. Bei dem Internetzugang handelt es sich um einen ADSL-Zugang mit dynamischer IP-Zuteilung durch den Provider.
Da sich bei dem Zugang die IP-Adresse jeden Tag ändert, der Tor Node aber immer unter einer gleichen Adresse erreichbar sein muss, ist die Einrichtung eines Kontos bei einem Diensteanbieter für dynamische IPs nötig, der die Auflösung der dynamischen IP in einen festen Domainnamen übernimmt. Der Bekannteste aus einer Vielzahl von Anbietern ist DynDNS.
Da bei Windows XP die Anzahl gleichzeitiger Verbindungsversuche limitiert wurden, aber eine möglichst hohe Anzahl für den Tor Node Betrieb günstig ist, sollte man den Patch zur Modifizierung der tcpip.sys zum Heraufsetzen des Limits anwenden.
Neben der Limitierung der Verbindungsversuche kann bei Windows XP Versionen ein Fehler auftreten, der sich umso mehr häuft, wenn parallel zum Tor Node verbindungsintensive Applikationen (z. B. P2P) betrieben werden und der zur Beendigung von Tor führt:
Das Auftreten des Fehlers kann man durch Optimierung der Parameter für TCP/IP Verbindungen und Änderung der Startparameter in der C:\boot.ini Datei verhindern bzw. hinauszögern. In dem Text zum Fehlerproblem werden die Registrywerte angegeben, die manuell anzupassen sind. Eine erste und schnelle Optimierung kann man über das grafische Programm TCPOptimizer durchführen. In der boot.ini ist hinter den Aufruf von Windows in der Sektion [operating systems] der Parameter /maxmem=N (N = maximal verfügbarer RAM in MB) zu setzen.
Für den Betrieb eines Tor Onion Routers ist es zudem wichtig, dass die Systemzeit präzise eingestellt ist, was durch Nutzung von Funktionen zur Zeitsynchronisierung mit Zeitservern ermöglicht wird.
Unter Windows kann man zum Beispiel mit einem geeigneten Hardware Router, der auch als Zeitserver für mit ihm verbundene Workstations fungieren kann, in Windows Tools zur Zeitsynchronisierung den Router als Zeitserver eintragen und den Router sich mit öffentlichen Zeitservern synchronisieren lassen.
Eine andere Methode ist die Installation des ntpd Prozesses, wie er unter Linux bekannt ist, als Windows Dienst mit einem eingeschränkten Benutzerkonto für den ntpd Dienst. Meinberg, der Hersteller von Hardware zur Zeitsynchronisierung bietet eine aktuell gehaltene Portierung des ntpd für Windows und den grafischen NTP Time Server Monitor mit entsprechenden Anleitungen zur Nutzung der Software an.
Bevor man einen Tor Node aktiviert, sollte man ein paar Maßnahmen zur Absicherung des Rechners ergreifen. Das gilt auch für Windows Rechner. Als Middleman Node tritt man zwar nicht auf Zielrechnern (und deren Logdateien) in Erscheinung, er ist aber wie ein Exit Node über das Tor Verzeichnis zu identifizieren.
Beim ersten Start eines neuen Tor Nodes werden sein Identitäts- und sein Onion-Schlüssel erzeugt, die besonders vor unberechtigtem Zugriff zu schützen sind. Dazu wird eine TrueCrypt Containerdatei angelegt, in die man neben den Schlüsseln auch gleich die Konfigurationsdatei torrc, die Fingerprintdatei, das zwischengespeicherte Verzeichnis und die Logdatei abspeichern kann oder es wird gleich das gesamte Dateisystem mit TrueCrypt verschlüsselt.
Eine Logdatei sollte man nur für das Aufspüren von Problemen aktivieren und dabei sensible Informationen erst gar nicht anlegen. Ansonsten ist es besser, sich die Statusmeldungen nur in einem Konsolefenster während der Laufzeit anzeigen zu lassen.
Wie die Tor Daten sollte sich das komplette Betriebssystem und die Verzeichnisse oder Daten, die ggf. zur Auslagerung von Daten verwendet werden, in einem verschlüsselten Dateisystem befinden.
Während unixoide Betriebssystemdistributionen wie Linux und *BSD freie und quelloffene Verschlüsselungslösungen enthalten, mit denen bereits bei der Installation oder nachträglich das komplette System verschlüsselt werden kann, muss man für Windows auf zusätzliche Verschlüsselungsanwendungen zurückgreifen.
Als Verschlüsselungsanwendungen, die in der Lage sind, Partitionen inklusive der Systempartition mit dem Windows Betriebssystem zu verschlüsseln bzw. Windows in einer verschlüsselten Partition zu betreiben, bieten sich folgende Lösungen an:
Für den Einsatz der quelloffenen und freien TrueCrypt Anwendung mit Containerdateien, Partitionen und der Windows Systempartition gibt es bei F!XMBR eine Reihe bebilderter Anleitungen.
Beispiel:
Erklärung:
Hinter Nickname gibt man den Kurznamen des Tor Nodes an, mit dem er im Verzeichnis steht. Hinter Address wird der Domainnamen des Diensteanbieters für dynamische IPs gesetzt. Über die E-Mail Adresse hinter ContactInfo ist man für Rückfragen und Informationen der Tor Verzeichnisserver Betreiber erreichbar. Der ORPort gibt die Nummer des Ports an, über den der eigene Node durch andere Nodes und die Verzeichnisserver von außen erreicht werden kann und über den die Daten ausgetauscht werden. Die ORListenAddress ist die interne IP-Adresse der Netzwerkschnittstelle des Windowsrechners, über die Daten entegengenommen und ausgesendet werden. Die ein- und ausgehende Bandbreite wird mit den Bandwidth Angaben fest auf 30 KB begrenzt (bei DSL-6000 wären ca. 20 - 90 KB möglich). Die Regel hinter ExitPolicy besagt, dass kein Datenaustausch zu Zielrechnern als Tor Exit Node stattfindet.Zuerst wird der TrueCrypt Container als virtuelles Laufwerk eingebunden, wenn man Tor nicht in einer verschlüsselten Partition, sondern in einer Containerdatei installiert hat.
Den Vorgang kann man bis auf die Eingabe des Passwortes "automatisieren", indem man nach einer Einbindung des Containers im TrueCrypt Menü Volumes den Eintrag Momentan eingebundene Volumes als Favoriten speichern auswählt. TrueCrypt legt dann im TrueCryptverzeichnis des Windows Benutzerprofils die Datei Favorite Volumes.xml an, die den Pfad und den Dateinamen der Containerdatei speichert.
Danach aktiviert man die folgenden Einstellungen über das Menü Einstellungen / Voreinstellungen:
Wichtig sind hier die Aktivierung des TrueCrypt-Hintergrundtasks und die Aktionen nach Benutzeranmeldung. Damit wird TrueCrypt automatisch nach Anmeldung des Benutzers gestartet, das Fenster zur Eingabe des Passworts angezeigt und nach dessen Eingabe die Containerdatei eingebunden.
Anschließend wird Tor mit dem Kommando
gestartet – "lw" ist hierbei wieder der Buchstabe des virtuellen TrueCrypt Laufwerks, in dem die Tor Daten gespeichert sind. Zweckdienlich legt man sich für den täglichen Torbetrieb eine Verknüpfung auf dem Desktop, im Startmenü oder in der Schnellstartleiste an.
Taucht der eigene Node danach regelmäßig in den Tor Node Statistiken mit dem Merkmal "Running: Yes" auf, die man mit dem Nickname des eigenen Nodes durchsuchen kann, ist der Node funktionsfähig.
Um Tor als Windowsdienst mit einem nicht priviligiertem Benutzerkonto laufen zu lassen, wird zunächst als Administrator ein neues Benutzerkonto angelegt, für das ein Benutzername und ein Passwort vergeben und dem jede Gruppenmitgliedschaft entzogen wird.
Mit tor.exe --service install im Tor Programmverzeichnis in der Eingabeaufforderung wird Tor als Windowsdienst installiert. In Zukunft wird Tor mit der Bezeichnung "Tor Win32 Service", dem Kommando LW:\Pfad\tor.exe --nt-service und dem Starttyp "Automatisch" immer automatisch im Hintergrund gestartet.
Um Tor mit dem angelegten Benutzerkonto laufen zu lassen, das sich als Dienst anmelden kann, aber nicht mehr als lokaler Dienst läuft, muss man anschließend in der Diensteverwaltung für den Dienst "Tor Win32 Service" die Anmeldung als "Lokales Systemkonto" auf das angelegte Benutzerkonto umstellen.
Danach kann man das Tor Benutzerkonto weiter einschränken, indem man die Sicherheitsrichtlinie als Administrator aufruft und dem Benutzerkonto über "Zuweisen von Benutzerrechten" im Zweig "Lokale Richtlinie" Rechte entzieht, wie zum Beispiel das Versagen aller anderen Anmeldungen bis auf das Recht, sich als Dienst anzumelden und des Rechts, mit dem Tor Benutzer vom Netzwerk aus auf den Computer zuzugreifen.
Wie für jeden anderen Benutzer auch, wird für das Tor Benutzerkonto ein Profil unter C:\Dokumente und Einstellungen\TorBenutzername erstellt. Die Tor Konfigurationsdatei torrc erwartet der Tor Dienst im Unterverzeichnis C:\Dokumente und Einstellungen\TorBenutzername\Anwendungsdaten\tor. Darin werden auch alle relevanten Daten zum Betrieb des Tor Routers gespeichert, wenn man nicht in der torrc ein anderes DataDirectory bestimmt. Hat man den Tor Router zuvor nicht als Dienst betrieben, sind also die torrc in das Unterverzeichnis und die übrigen Daten in das entsprechende DataDirectory zu kopieren.
Läuft der Tor Node ohne Probleme, kann man den eigenen Tor Node per E-Mail registrieren lassen, um den eigenen Nickname zu sichern oder um von den Tor Verzeichnis Betreibern im Falle wichtiger Informationen oder von Problemen kontaktiert zu werden.
Dazu sendet man eine E-Mail mit der Textnachricht:
Für das obige Beispiel z. B.:
Will man den eigenen Tor Node nicht nur als Middleman Node betreiben, sondern zum Exit Node erweitern, also für andere Benutzer auch als "Endstation" Daten zu Zielrechnern transportieren und zurückleiten, braucht man nur in der torrc die Zeile
editieren.
Beispiel (nach der StandardPolicy):
Erklärung:
Statt der Auflistung jeder Richtlinie mit einem vorangestellten ExitPolicy können alle Richtlinie auch in einer Zeile mit ExitPolicy Richtlinie1,Richtlinie2,... aufgezählt werden. Die Richtlinien werden von der ersten zur letzten Richtlinie verarbeitet, wobei die erste aufgefundene Richtline, die auf eine Verbindung zutrifft, angewendet wird.
Mit reject private:* wird der Datenverkehr zu Rechnern mit internen / privaten IP-Adressen / Netzwerken abgewiesen. Mit reject *:Port bzw. reject *:Port1-PortN wird der Datenverkehr zu Adressen mit Protokoll-Port N bzw. Portbereich 1-N abgewiesen – 25 und 119 besagt z. B., dass von anderen Benutzern der eigene Tor Exit Node nicht für Verbindungen zu Mailservern per SMTP und Newsservern per NNTP verwendet werden kann. Am Ende steht die generelle accept *.* Regel, die jeden Verkehr zu jedem Port bzw. mit jedem Dienst erlaubt, der zuvor nicht mit einer reject Regel verboten wurde.
Das * vor dem : steht also für die IP-Adresse eines Rechners oder in der Kombination IP-Adresse/Netzmaske für ein Netzwerk, das * nach dem : für einen einzelnen Port oder in der Kombiantion Port1-PortN für einen Portbereich.
Will man zum Beispiel nur zu einem speziellen Rechner oder einer kleinen Gruppe von Rechnern auf einen speziellen Port den Tor Router zum Exit Node machen, könnte man die ExitPolicy auch so gestalten:
In diesem Fall würde der Tor Router für verschlüsselte SMTPS und StartTLS Verbindungen zu den Mailservern aaa.bbb.ccc.ddd als Exit Node wirken und für alle anderen Verbindungen nur als Middleman Node.
Die obigen Schritte zur Einrichtung kann man auch mit dem grafischen Tor Kontrollprogramm Vidalia durchführen.
Dazu ruft man entweder über das Vidalia Kontrollpanel Weiterleitung einrichten oder über das Vidalia Systray Kontextmenü Einstellungen das Fenster für die Einstellungen von Tor auf und wechselt dann auf Server.
Mit Tor ist es auch möglich, anonym verborgene Internetdienste (Tor "hidden service") zu betreiben und anzubieten, ohne dass den Nutzern reale IP-Adressen und Domaininformationen zum Internetdienst bzw. Server bekannt werden. Also zum Beispiel einen eigenen Webserver, auf dem ein Weblog, eine Website oder ein Webforum gehostet wird.
Ein Anbieter, der die Anonymität seines Angebots und seiner Identität gewährleisten will, muss darauf achten, selbst keinerlei Informationen in den angebotenen Inhalten oder über die technische Plattform zu bieten, die zur Identifizierung seiner Person oder des Ortes führen, wo sein verborgener Dienst läuft. Für Dienste und Inhalte, die nicht auf dem eigenen Heimrechner gehostet werden, kann das zum Beispiel bedeuten, einen anonym bezahl- und administrierbaren Server anzumieten oder eine bereits existierende anonyme Hosting-Plattform zu nutzen.
Über Tor verborgene Internetdienste und Internetinhalte können so vor Zensur- und Verbotsmaßnahmen schützen, die sich gegen die Anbieter und Betreiber richten, polizeiliche und geheimdienstliche Maßnahmen und Methoden be- und verhindern, die zum Ziel haben, die Person bzw. Identität der Anbieter und Betreiber festzustellen, gesetzliche Zwangsvorschriften zur Anfertigung, Speicherung und Aushändigung von Logdateien unterlaufen und den Internetnutzern einen zusätzlichen Weg eröffnen, anonym Internetdienste zu nutzen und miteinander zu kommunizieren oder Inhalte zu konsumieren, die Verboten und der Zensur unterliegen.
Beispiele für per Tor verborgene Internetangebote finden sich auf der Seite core.onion, die selbst über einen verborgenen Internetdienst eines Tor Routers erreichbar ist und auf der man über die Toogle Suchmaschine weitere Angebote findet. Aber auch vom normalen WWW aus können verborgende Tor Internetangebote genutzt werden. Dafür sorgen Proxydienste wie tor2web oder der Onion-Proxy der German Privacy Foundation e. V.
Für den Betrieb eines verborgenen Internetdienstes über Tor und die Serveranwendung selbst sind ähnliche Sicherheitsmaßnahmen zu ergreifen wie für den Betrieb eines eigenen Tor Nodes.
Der Internetdiensteanbieter hat den Server eingerichtet und lässt ihn lokal über die loopback Adresse 127.0.0.1 und einer freien Portnummer laufen.
Die Tor Konfigurationsdatei torrc erhält entsprechende Einträge für den Internetdienst. Werden mehrere Internetdienste hinter Tor verborgen betrieben, benötigt jeder Dienst einen separaten Eintrag:
Das HiddenServiceDir Verzeichnis muss für das Benutzerkonto, unter dem Tor betrieben wird, mit Schreibrechten versehen sein, weil Tor darin ein eigenes Schlüsselpaar aus privatem und öffentlichem Schlüssel für den Dienst erstellt, das in der Datei private_key abgespeichert wird und die Datei hostname, in die der Tor Domainname aufgenommen wird.
Der besitzt üblicherweise die Form z.onion, wobei der z Anteil einen Hash des öffentlichen Schlüssels in Base32 kodierter Form enthält und .onion die virtuelle Top Level Domain für die Rechner darstellt, auf denen die verborgenen Dienste betrieben werden. Sie kann deshalb nur über Tor selbst "aufgelöst" werden.
Der Domainnamen kann auch die Form x.y.z.onion haben. Dann enthät der x Anteil Daten zur Authentifikation / Autorisation, die der Treffpunktknoten verlangt und der y Anteil Daten zur Authentifikation / Autorisation, die der Internetdienst verlangt – beides ebenfalls in Base32 Kodierung.
Die HiddenServicePort Zeile gibt zuerst die (virtuelle) Portnummer an, über den später die Nutzer meinen, von außen auf den Dienst zuzugreifen und danach die lokale Adresse mit der internen/lokalen Dienst-Portnummer, auf die der Internetdienst wirklich lauscht und an die Tor die über das Tornetz eingehenden Anfragen der Nutzer übergibt.
Der Onion Proxy des Diensteanbieters wählt aus allen Tor Nodes mehrere Onion Router aus, die später dem Onion Proxy des Internetnutzers als "Treffpunktknoten" dienen. Zu allen Treffpunktknoten baut der Onion Proxy des Diensteanbieters eine Tor Verbindungskette auf und übermittelt den Onion Routern seinen öffentlichen Schlüssel, wobei die Mitteilung mit dem privaten Schlüssel signiert ist.
Der Onion Proxy des Diensteanbieters stellt eine Dienstebeschreibung zusammen, die alle Treffpunktknoten, den öffentlichen Schlüssel und die Portnummer des Dienstes enthält, signiert sie mit dem privaten Schlüssel und übermittelt die Dienstebeschreibung an alle Tor Verzeichnisserver, von denen sie nach Überprüfung der Signatur und Zeitangaben in ein eigenes Verzeichnis für verborgene Internetdienste eingetragen wird. Die Dienstebeschreibungen verbleiben also auf den Tor Verzeichnisservern und werden nicht wie die Daten zu allen Tor Nodes über eine Verzeichniskopie an die Onion Proxys der Tor Nutzer übertragen.
Parallel entnimmt der Diensteanbieter den Tor "Domainnamen" seines Dienstes der Datei hostname und gibt die Informationen Internetnutzern auf Webseiten bekannt, übermittelt sie an Interessenten per E-Mail oder Instant Messaging usw.
Der Internetnutzer hat Informationen und Angaben zum verborgenen Internetdienst über eine Internetplattform, per E-Mail usw. erhalten. Er übergibt den string.onion Domainnamen des Dienstes als Teil der Adresse seiner Internetanwendung, die ihn an den Onion Proxy übergibt. Der ruft von den Tor Verzeichnisservern die Daten des Dienstes aus dessen Dienstebeschreibung (siehe Phase 4) ab, darunter auch die Adressen der Treffpunktknoten.
Der Onion Proxy des Internetnutzers wählt aus allen Tor Nodes einen Onion Router aus, der später dem Onion Proxy des Diensteanbieters als "Verbindungsknoten" dient und baut zum Verbindungsknoten eine Tor Verbindungskette auf.
Der Onion Proxy des Internetnutzers baut zusätzlich zu einem der Treffpunktknoten des Dienstenabieters eine separate Tor Verbindungskette auf und übermittelt dem Treffpunktknoten eine mit dem öffentlichen Schlüssel des Internetdienstes verschlüsselte Nachricht, die u. a. den Namen des Verbindungsknoten und einen Schlüsselmaterial-Anteil für einen gemeinsamen Sitzungsschlüssel mit dem Onion Proxy des Diensteanbieters per Diffie-Hellman Schlüsselvereinbarung enthält.
Der Treffpunktnoten sendet die Nachricht vom Onion Proxy des Internetnutzers über die Tor Verbindungskette an den Onion Proxy des Diensteanbieters, wo sie mit dem privaten Schlüssel entschlüsselt wird.
Der Onion Proxy des Diensteanbieters entnimmt der entschlüsselten Nachricht u. a. den Namen des Onion Routers, der als Vermittlungsknoten des Internetnutzers fungiert und den Schlüsselmaterial-Anteil für den gemeinsamen Sitzungsschlüssel. Danach bildet er den gemeinsamen Sitzungsschlüssel, baut eine neue separate Tor Verbindungskette zum Vermittlungsknoten des Internetnutzers auf und übergibt ihm u. a. den zweiten Schlüsselmaterial-Anteil. Der Vermittlungsknoten sendet die Nachricht über die Tor Verbindungskette an den Onion Proxy des Internetnutzers weiter.
Der Onion Proxy des Internetnutzers bildet ebenfalls den gemeinsamen Sitzungsschlüssel. Danach schalten sich die beiden Tor Verbindungsketten vom Onion Proxy des Internetnutzers zum Verbindungsknoten und vom Onion Proxy des Diensteanbieters zum Vermittlungsknoten über den Verbindungsknoten zusammen. An einer Verbindung zwischen einem anonymen Internetnutzer und einem anonymen Diensteanbieter sind also ingesamt sechs Onion Router für die beiden Tor Verbindungsketten und ein Onion Router als Verbindungsknoten beteiligt.
Der Onion Proxy des Internetnutzers sendet Anfragen des Internetnutzers, die zuerst mit dem gemeinsamen Sitzungsschlüssel und danach mit allen Sitzungsschlüssel der beteiligten Tor Router verschlüsselt sind, bis zum Verbindungsknoten.
Dort werden sie an den letzten Tor Router der Tor Verbindungskette des Diensteanbieters übergeben und – wieder schrittweise mit den Sitzungsschlüsseln "seiner" Tor Router verschlüsselt – zum Onion Proxy des Diensteanbieters weitergeleitet. Der entschlüsselt die Anfrage und leitet sie über den lokalen Diensteport an die Interntediensteanwendung (z. B. einen Webserver) weiter.
Die Antworten der Internetdiensteanwendung nimmt der Onion Proxy auf. Von dort werden sie, mit den gleichen Mechanismen wie bei den Anfragen, verschlüsselt über die Tor Verbindungskette des Diensteanbieters bis zum Verbindungsknoten und von dort über die Tor Verbindungskette des Internetnutzes bis zum Onion Proxy des Internetnutzers weitergeleitet. Nach Entschlüsselung der Antwortpakete übergibt sie der Onion Proxy an die Internetanwendung (z. B. einen Webbrowser) des Internetnutzers.
