Eine .onion-Seite auf einem VPS hosten, ohne den Server zu verraten

Fangen wir mit dem an, was tatsächlich anders ist, denn es ist mehr als nur ein seltsam aussehender Hostname. Eine gewöhnliche Seite hängt von einer Kette externer Parteien ab, und ein Onion-Service hat diese Kette schlicht nicht.

• Kein Registrar und keine Registry. Eine v3-Onion-Adresse ist die Base32-Kodierung eines öffentlichen ed25519-Schlüssels, plus einer Prüfsumme und einem Versionsbyte — sechsundfünfzig Zeichen, erzeugt auf der eigenen Maschine in einem Bruchteil einer Sekunde. Niemand hat sie Ihnen verkauft, also kann niemand sie Ihnen wieder wegnehmen, und es gibt kein Verlängerungsdatum. Das ist das genaue Gegenteil des Risikomodells aus unserer Anleitung Eine Domain privat registrieren.
• Kein DNS. Nichts löst einen .onion-Namen auf. Der Client fragt das Tor-Netzwerk nach einem signierten Deskriptor, der unter diesem Schlüssel veröffentlicht ist, es gibt also keinen Resolver, der vergiftet werden könnte, keine Zone, die durchsickern könnte, und keinen Nameserver, der sich abschalten ließe.
• Keine Zertifizierungsstelle. Die Adresse ist der öffentliche Schlüssel, sodass der Client den Service gegen den eingetippten Namen überprüft. Das ist es, was “selbstauthentifizierend” bedeutet: Es gibt keinen Dritten, der für die Identität bürgt, weil Identität und Adresse dasselbe Objekt sind.
• Kein eingehender Port. Der Service öffnet ausgehende Circuits zu einer Handvoll Einführungspunkte und wartet dort. Ihre Firewall kann jedes eingehende Paket verwerfen, und die Seite funktioniert trotzdem. Nichts lauscht auf einer öffentlichen Adresse, also gibt es nichts zu scannen, keinen Fingerabdruck zu erfassen und nichts, das sich direkt fluten ließe.

Eine historische Anmerkung, die immer noch für Verwirrung sorgt: Die alten sechzehnstelligen Adressen sind Geschichte. Die Unterstützung für Onion-Services der Version 2 wurde im Oktober 2021 aus Tor entfernt, die Adressen funktionieren nirgendwo mehr, und alles, was Sie über sie finden, ist veraltet. Alles Folgende ist v3, die einzige Art, die es noch gibt.

Und seien Sie sich klar darüber, was davon nichts wegnimmt. Es gibt weiterhin eine physische Maschine in einem Rechenzentrum, einen Host, der weiß, dass sie existiert, eine Rechnung, die jemand bezahlt hat, und eine Anwendung, in die man einbrechen kann. Onion-Services verschieben die Adressebene außer Reichweite. Sie verschieben nicht den Server.

Menschen kommen zu Tor, weil sie eines von vier recht unterschiedlichen Dingen tun wollen, und die Risikoprofile sind nicht im Geringsten vergleichbar. Es lohnt sich zu wissen, wofür man sich da eigentlich entscheidet.

• Ein Middle-Relay leitet verschlüsselten Datenverkehr zwischen anderen Relays weiter. Es transportiert die Daten anderer Leute, berührt aber nie in deren Namen das offene Internet, weshalb es keine Beschwerden auf sich zieht.
• Eine Bridge ist ein nicht gelisteter Einstiegspunkt für Menschen, deren Zugang zu Tor blockiert ist. Gleiches Verkehrsprofil wie ein Middle-Relay, nur dass die Adresse aus dem öffentlichen Verzeichnis herausgehalten wird.
• Ein Exit-Relay ist die Stelle, an der der Datenverkehr anderer Leute Tor verlässt und unter Ihrer IP-Adresse das gewöhnliche Internet erreicht. Das ist dasjenige, das Missbrauchs-Mails und rechtliche Korrespondenz erzeugt, und es braucht bewusste Handhabung — unsere Tor-Relay-Anleitung deckt das richtig ab.
• Ein Onion-Service veröffentlicht. Er transportiert keinen Datenverkehr außer seinem eigenen, kontaktiert nie in irgendjemandes Namen das Clearweb und erzeugt deshalb überhaupt keine Missbrauchsmeldungen gegen Ihre IP. Es gibt keinen Exit, also gibt es auch keinen Ausgang.

Der letzte Punkt lohnt sich zu verinnerlichen, weil er routinemäßig missverstanden wird. Einen Onion-Service zu betreiben ist operativ das Unauffälligste, was Sie im Tor-Netzwerk tun können. Ihr Server baut ausgehende Verbindungen auf, die wie gewöhnlicher Tor-Client-Verkehr aussehen; er erscheint nie als Quelle einer Verbindung zum Server von irgendjemand anderem; und das, worüber sich die meisten Leute Sorgen machen — dass das Verhalten von jemand anderem auf Ihre IP zurückfällt —, ist strukturell unmöglich.

Sie müssen auch keinen Relay betreiben, um einen Onion-Service zu betreiben, und die beiden hält man besser getrennt. Ein Relay will Bandbreite, einen öffentlichen ORPort und ein veröffentlichtes ContactInfo. Ein Service will nichts davon. Wenn Sie beides wollen, tun Sie es auf zwei Servern.

Hier ist der Teil, zu dem die offizielle Dokumentation wenig sagt, und der Teil, der tatsächlich entscheidet, ob sich die Übung gelohnt hat. Tor, so konfiguriert wie unten beschrieben, ist höchst unwahrscheinlich das, was Ihren Server verrät. Die Software dahinter schon, weil diese Software unter der Annahme geschrieben wurde, dass ein Webserver gefunden werden will.

Das sind die Kanäle, ungefähr in der Reihenfolge, in der sie Leute erwischen:

• Derselbe Inhalt auf der öffentlichen IP. Wenn Ihr Webserver auch auf 0.0.0.0 lauscht, sieht jeder, der das Internet scannt, dieselbe Seite sowohl auf einer IP-Adresse als auch auf einer Onion-Adresse. Scanner, die das gesamte Internet erfassen, indizieren fortlaufend jeden offenen Port, und ihre Ergebnisse sind nach Body-Hash und nach Favicon-Hash durchsuchbar. Eine einzige Abfrage verknüpft die beiden. Das ist die mit Abstand häufigste Art, wie ein Onion-Service demaskiert wird, und es ist ein Konfigurationsfehler in einer einzigen Zeile.
• Server-Banner und Standardseiten. Eine unveränderte nginx- oder apache2-Installation beantwortet unbekannte Hostnamen mit einer Standardseite, druckt ihre Version in den Server-Header und verrät in der Fehlerausgabe oft den echten Hostnamen der Maschine. Jedes davon ist ein Korrelationsmerkmal.
• Absolute URLs. Redirects, kanonische Tags, Sitemaps, RSS-Feeds, Open-Graph-Tags und Passwort-Reset-E-Mails geben allesamt liebend gern eine vollqualifizierte Clearweb-URL aus. Eine einzige davon innerhalb der Onion-Version einer Seite genügt.
• Ausgehende Anfragen, die die Anwendung stellt. Analytics, Web-Fonts, CDN-Assets, Avatar-Dienste, Kartenkacheln, Webhooks und Update-Prüfungen gehen alle von der echten IP des Servers aus, und mehrere von ihnen verraten einem Dritten, welche Seite in diesem Moment gerade gerendert wurde. Eine selbstgehostete Seite mit einer von einer fremden Domain geladenen Schriftart hat einen Audit-Trail, den sie nicht beabsichtigt hat.
• Mail. Alles, was die Maschine verschickt, stempelt ihre echte IP in die Received-Header. Wenn der Service Mail versenden muss, ist das ein Designproblem, das bewusst gelöst werden muss — beginnen Sie mit unserer Mailserver-Anleitung, und gehen Sie standardmäßig davon aus, dass er gar nichts versenden sollte.
• Wiederverwendete Schlüssel und Fingerabdrücke. Derselbe SSH-Host-Schlüssel, der sowohl auf der öffentlichen IP als auch auf einer Onion-Adresse antwortet, verknüpft beide dauerhaft. Genauso dasselbe TLS-Zertifikat, dasselbe Favicon, dieselbe Analytics-Kennung oder dieselbe unverwechselbare Fehlerseite über zwei Projekte hinweg.
• Certificate Transparency. Wenn dieselbe Maschine jemals eine Clearweb-Domain über HTTPS bedient, wird das Zertifikat für diese Domain für immer in öffentliche, nur anhängbare Logs geschrieben. Das benennt die Maschine, nicht die Onion-Adresse, aber es benennt die Maschine.

Die gemeinsame Form all dessen ist immer dieselbe: Tor hat die Adresse verborgen, und etwas anderes auf dem Server hat sie veröffentlicht. Schritt acht weiter unten ist eine Checkliste, um das zu finden, bevor es jemand anderes tut.

Bevor Sie irgendetwas installieren, beantworten Sie eine Frage, denn alles Weitere hängt davon ab: Ist der physische Standort dieses Servers ein Geheimnis, das Sie zu wahren versuchen?

Es gibt drei ehrliche Antworten, und sie führen zu wirklich unterschiedlichen Aufbauten.

• Ja, der Standort ist der springende Punkt. Dann erledigt diese Maschine genau eine Aufgabe. Keine Clearweb-Seite, kein öffentlicher DNS-Eintrag, der auf ihre IP zeigt, keine Mail, kein anderer Service, der irgendwo lauscht. Bezahlen Sie es auf eine Art, die Ihren Namen nicht daran heftet — unsere Monero-Anleitung deckt die Mechanik ab, und no-KYC-Konten bedeuten, dass es nichts zu übergeben gibt außer einer Lieferadresse. Sie behalten die volle Drei-Hop-Konfiguration. Jede Abkürzung weiter unten, die Anonymität gegen Geschwindigkeit eintauscht, ist für Sie gesperrt, und das ist in Ordnung, weil Sie nicht auf Geschwindigkeit optimieren.
• Nein, der Server ist bereits öffentlich. Sie betreiben eine gewöhnliche Seite und möchten zusätzlich eine Onion-Adresse — für Leser hinter Zensur, für Menschen, die Ihre Domain lieber nicht auflösen wollen, oder weil Sie es einfach anbieten möchten. Niemand verbirgt etwas, Sie können also einen Single Onion Service verwenden, den Circuit von sechs Hops auf drei kürzen und die Adresse von der Clearweb-Seite aus mit einem Onion-Location-Header bewerben. Das ist ein Erreichbarkeits-Feature, und es ist ein völlig legitimer Grund, hier zu sein.
• Irgendwo dazwischen. Hier befinden sich die meisten Menschen tatsächlich, und es ist die gefährliche Option, denn “etwas verborgen” ist keine Eigenschaft, die ein Server haben kann. Entscheiden Sie sich für eine Seite. Wenn der Standort wirklich wichtig ist, bauen Sie so, als wäre er es. Wenn nicht, hören Sie auf, die Latenzkosten für eine Anonymitätseigenschaft zu zahlen, die Sie ohnehin nicht aufrechterhalten.

Schreiben Sie die Antwort auf, bevor Sie weitermachen. Fast jeder Fehler rund um das Thema dieser Anleitung entsteht dadurch, dass für den ersten Fall gebaut, aber so betrieben wird, als wäre es der zweite.

Wenn der Standort des Servers kein Geheimnis ist, ist der Betrieb beider Varianten unkompliziert und wirklich nützlich — so bieten große Nachrichtenorganisationen, Debian und mehrere Suchmaschinen ihre Seiten an. Zwei Mechanismen und ein Kompromiss, die man verstehen sollte.

Bewerben Sie sie mit Onion-Location. Ein einziger Header auf der Clearweb-Seite lässt Tor Browser eine Schaltfläche “.onion verfügbar” in der Adressleiste anzeigen und den Wechsel anbieten. Der Header wird nur auf Seiten beachtet, die über HTTPS ausgeliefert werden, und der Wert muss eine gültige Onion-URL sein:

add_header Onion-Location "http://<your-address>.onion$request_uri" always;

Es gibt ein HTML-Äquivalent für Hosts, bei denen Sie keine Header setzen können, das dieselbe HTTPS-Anforderung hat:

<meta http-equiv="onion-location" content="http://<your-address>.onion">

Platzieren Sie die Adresse außerdem irgendwo, wo ein Mensch sie lesen kann, in der Fußzeile oder auf einer Über-uns-Seite. Der Header erreicht nur Menschen, die bereits Tor Browser benutzen; die Fußzeile erreicht alle anderen.

Erwägen Sie einen Single Onion Service. Eine normale Onion-Verbindung hat sechs Hops — drei vom Client, drei vom Service —, und die drei des Service existieren einzig und allein, um zu verbergen, wo er steht. Wenn das kein Geheimnis ist, können Sie sie weglassen. Die Latenzverbesserung ist groß und sofort spürbar. Die Konfiguration ist absichtlich unverblümt:

# /etc/tor/torrc — these are INSTANCE-WIDE, not per service
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
SOCKSPort 0

Beide Optionen sind nur zusammen gültig, der SOCKS-Port muss deaktiviert werden, und sie gelten für jeden Onion-Service auf dieser Tor-Instanz — ein Opt-out pro Service gibt es nicht. Tor verweigert den Start, wenn Sie eine ohne die anderen setzen, und damit tut Ihnen die Software einen Gefallen. Wenn eine einzelne Instanz einen Service hostet, dessen Standort öffentlich ist, und einen weiteren, dessen Standort es nicht ist, betreiben Sie zwei Instanzen oder besser zwei Server.

Und akzeptieren Sie den Kompromiss. Beide Adressen zu veröffentlichen erklärt, dass derselbe Betreiber beide führt, und identischen Inhalt von beiden auszuliefern macht sie ohnehin trivial verknüpfbar. Das ist der Deal, und für eine öffentliche Seite kostet er nichts. Halten Sie die Hygiene trotzdem ein: keine absoluten Clearweb-URLs innerhalb der Onion-Version, Cookies, die pro Host begrenzt sind, sodass eine Sitzung nicht zwischen ihnen wandert, und eine Content-Security-Policy, die keine Assets herüberzieht.

Standardmäßig kann jeder, der Ihre Adresse kennt, den Service erreichen. Client-Autorisierung ändert das auf der Netzwerkebene statt auf der Anwendungsebene, und der Unterschied ist wichtiger, als er klingt.

Mit aktivierter Autorisierung ist der Deskriptor, den Ihr Service veröffentlicht, gegen eine Reihe von Client-Schlüsseln verschlüsselt. Ein Besucher ohne einen dieser Schlüssel kann ihn nicht entschlüsseln, kann die Einführungspunkte nicht erfahren und kann sich deshalb überhaupt nicht verbinden — er erreicht keine Anmeldeseite, er bekommt keine Ablehnung, er bekommt gar nichts. Der Service ist nicht ungelistet; er ist unsichtbar.

Erzeugen Sie ein x25519-Schlüsselpaar pro Client. Jedes Werkzeug dafür ist auf einer Debian-Maschine bereits vorhanden:

openssl genpkey -algorithm x25519 -out alice.prv.pem

# private key — goes to the client, never to the server
grep -v 'PRIVATE KEY' alice.prv.pem | base64 -d | tail -c 32 | base32 | tr -d '='

# public key — goes on the server
openssl pkey -in alice.prv.pem -pubout | grep -v 'PUBLIC KEY' \
  | base64 -d | tail -c 32 | base32 | tr -d '='

Legen Sie auf dem Server den öffentlichen Schlüssel in ein Verzeichnis authorized_clients innerhalb des Service-Verzeichnisses. Der Dateiname ist beliebig, solange er auf .auth endet, wodurch der Widerruf zu einer Frage des Löschens einer einzigen Datei wird:

mkdir -p /var/lib/tor/onion-site/authorized_clients
echo "descriptor:x25519:<ALICE-PUBLIC-KEY>" \
  > /var/lib/tor/onion-site/authorized_clients/alice.auth
chown -R debian-tor:debian-tor /var/lib/tor/onion-site
systemctl reload tor@default

Auf dem Client kommt der private Schlüssel in das Verzeichnis, das ClientOnionAuthDir benennt, in eine Datei, die auf .auth_private endet, wobei die Adresse darin wiederholt wird. Tor Browser hat unter seinem Datenordner ein eigenes Verzeichnis dafür und fragt nach einem Schlüssel, wenn er auf einen Service trifft, der einen braucht:

# /var/lib/tor/onion-auth/mysite.auth_private
<address-without-the-.onion>:descriptor:x25519:<ALICE-PRIVATE-KEY>

Das ist das richtige Werkzeug für eine Staging-Seite, ein Admin-Panel, eine private Dateiablage oder ein selbstgehostetes Nextcloud, das nur Sie benutzen — alles, wo die ehrliche Antwort auf “wer sollte sehen können, dass es das gibt?” lautet: “niemand außer uns”. Die Kosten sind real und administrativ: Sie müssen den Leuten Schlüssel über einen Kanal zukommen lassen, dem Sie vertrauen, und Sie müssen daran denken, sie hinterher wieder zu entfernen.

Onion-Services fallen auf ihre eigene, besondere Art aus, und keine davon sieht wie ein gewöhnlicher Ausfall aus. Vier Dinge lohnt es sich einzurichten, bevor man sie braucht.

Denial of Service ist das eigentliche operative Problem. Weil es keine IP-Adresse zu filtern gibt, greifen die üblichen Abwehrmaßnahmen nicht, und eine gezielte Flut von Anfragen an die Einführungspunkte ist billig zu verschicken. Tor hat zwei Antworten darauf, beide pro Service in torrc gesetzt: HiddenServiceEnableIntroDoSDefense 1 drosselt Anfragen an den Einführungspunkten, und HiddenServicePoWDefensesEnabled 1 lässt Clients ein kleines Proof-of-Work-Rätsel lösen, das unter Last schwerer wird, sodass legitime Besucher einen Moment warten, während eine Flut teuer wird. Schalten Sie beides von Anfang an ein; die Kosten sind vernachlässigbar, solange Sie niemand angreift.

Halten Sie die Uhrzeit korrekt. Deskriptoren werden gegen Zeitperioden veröffentlicht und nachgeschlagen, die von einem gemeinsamen Netzwerkwert abgeleitet sind. Ein Server, dessen Uhr stark abgedriftet ist, veröffentlicht an der falschen Stelle und wird unerreichbar, während er in seinen eigenen Logs vollkommen gesund erscheint. Stellen Sie sicher, dass ein NTP-Client läuft, halten Sie die Maschine auf UTC, und prüfen Sie das, wenn ein Service auf mysteriöse Weise aufhört aufzulösen.

Monitoring muss durch Tor laufen. Kein kommerzieller Uptime-Dienst kann eine .onion-Adresse abfragen, was bedeutet, dass die übliche Antwort für Sie nicht verfügbar ist. Führen Sie die Prüfung selbst aus, von einer zweiten Maschine, die nicht die ist, die den Service hostet — ein Cron-Job, der torsocks curl -s --max-time 60 gegen eine bekannte URL ausführt und die Ausgabe mit einer bekannten Zeichenkette vergleicht, genügt und kostet nichts.

Planen Sie mehr als eine Instanz ein, wenn Verfügbarkeit wichtig ist. OnionBalance lässt mehrere Backend-Server sich eine einzige Onion-Adresse teilen: Eine Frontend-Instanz hält den Schlüssel, dem die Adresse gehört, und veröffentlicht einen Deskriptor, der auf die Einführungspunkte der Backends zeigt, sodass Sie Lastverteilung und Failover bekommen, ohne dass sich die Adresse jemals ändert. Das sind mehr bewegliche Teile, als die meisten Seiten brauchen, aber es ist die unterstützte Antwort, und es lohnt sich zu wissen, dass es sie gibt, bevor Sie sich selbst in eine einzelne Maschine hineinmanövriert haben.

Eine letzte betriebliche Gewohnheit: Ein Neustart von Tor nimmt den Service für ein paar Sekunden offline, während er neu veröffentlicht, und eine Neuinstallation, die /var/lib/tor löscht, nimmt ihn für immer offline. Behandeln Sie dieses Verzeichnis so, wie Sie einen privaten Schlüssel behandeln würden, denn genau das ist es.

Eine Onion-Adresse entfernt den Registrar, den Resolver, die Zertifizierungsstelle und den offenen Port. Sie entfernt sonst nichts, und genau zu sein, was den Rest angeht, ist das, was ein nützliches Werkzeug von einem falschen Sicherheitsgefühl unterscheidet.

Sie repariert nicht die Anwendung. Eine verwundbare Web-App hinter einem Onion-Service ist eine verwundbare Web-App; das Erste, was viele Angreifer tun, nachdem sie Code-Ausführung erlangt haben, ist eine ausgehende Anfrage zu stellen, die die echte Adresse des Servers preisgibt. Geben Sie der Maschine den Zehn-Minuten-Durchgang aus unserer Debian-Härtungsanleitung, halten Sie sie gepatcht, und behandeln Sie sie als exponiert, auch wenn nichts lauscht.

Sie verbirgt den Server nicht vor den Leuten, die ihn betreiben. Wir wissen, dass ein Server existiert, wann er bereitgestellt wurde und wie seine IP-Adresse lautet, weil wir diejenigen sind, die sie zugeteilt haben. Das gilt für jeden Host, überall, und wer Ihnen etwas anderes erzählt, verkauft Ihnen etwas. Was wir genau sagen können, ist, was wir damit tun, und das steht in unserer ehrlichen Bestandsaufnahme dessen, was ein kryptobezahlter VPS verbirgt.

Sie besiegt nicht aus sich heraus einen geduldigen, gut ausgestatteten Gegner. Datenvolumen und Timing sind an den Rändern des Netzwerks sichtbar, und ein Service, der immer dann still wird, wenn eine bestimmte Person schläft, verrät Ihnen etwas. Ebenso wenig hilft es, wenn der Inhalt Sie identifiziert: derselbe Schreibstil, derselbe PGP-Schlüssel, derselbe Avatar oder dasselbe Forenpseudonym wie eine öffentliche Identität schließt den Kreis, egal wie gut der Transport ist.

Zur Kalibrierung, wie wir selbst dastehen: Onion-Services sind auf jeder Stufe willkommen und brauchen nichts Besonderes von uns, weil sie keine Ports öffnen und keinen Missbrauchs-Traffic erzeugen. Wir betreiben no-KYC-Konten, die nur eine Adresse brauchen, an die Zugangsdaten geliefert werden. Wir behandeln routinemäßige Urheberrechts-Korrespondenz als operative Angelegenheit statt als automatische Abschaltung, wir reagieren auf gültige Gerichtsbeschlüsse in der Jurisdiktion, in der der Server steht, und die harte Untergrenze ist absolut und gilt hier genau wie überall sonst: kein CSAM, keine Terrorismus-Inhalte, keine Ausnahmen. Lesen Sie die Nutzungsrichtlinie und wie wir mit Missbrauchsmeldungen umgehen, bevor Sie etwas aufbauen, das Sie ungern umziehen würden. Unsere Tor-freundliche VPS-Seite hat die Anleitung zu den Stufen.