Schlagwort: SelfHosted (Seite 1 von 7)

Kurzfassung: www.kernel-error.de ist zusätzlich als Tor Hidden Service erreichbar.
Meine .onion-Adresse: jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion

Der ursprüngliche Beitrag war ziemlich kurz gehalten. Seither werde ich immer wieder gefragt, wie das eigentlich zusammenspielt und was man bei so einem Setup alles bedenken muss. Also habe ich ihn deutlich erweitert und versuche, den Aufbau von der Idee bis zum fertigen vHost nachvollziehbar zu machen – inklusive der Stolperfallen, die ich unterwegs eingesammelt habe.

Warum überhaupt eine Onion-Variante?

Die Seite läuft ohnehin unter HTTPS mit aktuellen Cipher-Suites, Post-Quantum Key Exchange und HSTS. Technisch gesehen passiert zwischen Besucher und Server also schon heute nichts Unverschlüsseltes. Trotzdem gibt es ein paar Gründe, die für einen zusätzlichen Hidden Service sprechen:

• Metadaten-Minimierung: Beim Clearnet-Abruf sieht der Provider mindestens, dass jemand mit meiner IP spricht. DNS-Resolver, Transit-Router und der Exit-Punkt kennen das Ziel. Bei einem Hidden Service ist außerhalb des Tor-Netzwerks gar nichts mehr zu sehen – weder IP noch DNS-Namen.
• Kein Exit-Node: Wer meine Seite über einen normalen Tor-Browser mit Clearnet-URL besucht, spricht am Ende über einen Exit-Node mit meinem Server. Der Exit sieht zwar nur TLS, kann aber Metadaten wie SNI oder Zielhost mitbekommen und je nach Land auch gesperrt werden. Mit einer Onion-Adresse fällt der Exit-Node komplett weg.
• Keine CA-Abhängigkeit: Die .onion-Adresse ist der Public-Key-Hash selbst. Wer die korrekte Adresse kennt, spricht kryptografisch nachweisbar mit meinem Server – ganz ohne Zertifikatsausstellerin und ohne OCSP-Kaskade.
• Zensurresistenz: Sollte der Clearnet-Zugang aus irgendeinem Grund blockiert sein – falsche DNS-Antworten, gesperrte IP, generelle Sperre der Domain – bleibt die Onion-Variante unabhängig davon erreichbar.
• Spielerei und Lerneffekt: Ich finde das Konzept hinter v3-Onions schlicht spannend. Ed25519-Keys, Rendezvous-Protokoll, Introduction Points – da steckt eine Menge gut durchdachte Krypto drin, die man am eigenen Dienst deutlich besser versteht als aus Diagrammen.

Wie das Ganze aufgebaut ist

Der Blog läuft in einer FreeBSD-Jail mit Nginx, PHP-FPM und einer eigenen Tor-Instanz. Für den Hidden Service sind drei Bausteine relevant:

• Der Tor-Daemon hält das Schlüsselmaterial und den Rendezvous-Teil. Er lauscht nicht auf einer öffentlichen IP, sondern hängt sich in das Tor-Netzwerk und meldet dort den Dienst an.
• Nginx stellt einen eigenen vHost bereit, der ausschließlich auf einer Loopback-Adresse (127.0.0.6:80) lauscht. Öffentlich erreichbar ist dieser vHost nie – er wird ausschließlich vom lokalen Tor-Prozess angesprochen.
• PHP-FPM liefert wie gewohnt über einen Unix-Socket die WordPress-Inhalte aus – allerdings ohne FastCGI-Cache für den Onion-Pfad. Dazu gleich mehr.

Der Vorteil dieser Trennung: Alles, was der Tor-Daemon an den Nginx weiterreicht, kommt garantiert aus dem Tor-Netzwerk. Und alles, was der Clearnet-vHost ausliefert, geht garantiert nicht über das Onion-Interface. Zwei saubere Welten, gleiche Codebasis, null Überschneidung im Cache.

Tor-Daemon: torrc

Die minimale Konfiguration für einen v3-Hidden-Service ist überraschend kurz:

HiddenServiceDir      /var/db/tor/hidden_service/
HiddenServiceVersion  3
HiddenServicePort     80 127.0.0.6:80
SocksPort             127.0.0.6:9050
Log                   notice file /var/log/tor/notices.log

Beim ersten Start legt Tor in HiddenServiceDir das komplette Schlüsselmaterial selbst an: den privaten ed25519-Schlüssel, die daraus abgeleitete hostname-Datei mit der .onion-Adresse und ein paar weitere Dateien für die Introduction-Points. Diese Dateien sind privilegiert – wer sie hat, kann den Dienst übernehmen und sich gegenüber der Welt als mein Server ausgeben. Entsprechend gehören sie dem _tor-User, haben mode 700 und sind im Backup separat behandelt.

Die Adresse selbst ist 56 Zeichen lang und wird aus dem ed25519-Public-Key abgeleitet. Aenderbar ist sie nicht – wer eine bestimmte Wunschadresse will, muss mit Tools wie mkp224o so lange Schlüssel durchprobieren, bis der Base32-Prefix passt. Hat mich nicht gereizt, dafür ist meine Adresse eben zufällig.

Nginx-vHost für den Onion-Service

Der eigentliche vHost ist bewusst klein gehalten. Kein Cache, kein TLS, keine QUIC-Spielereien – alles, was spezifisch für den Clearnet-Teil ist, fehlt hier:

server {
    listen 127.0.0.6:80;
    server_name jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion;

    root  /usr/local/www/www.kernel-error.de;
    index index.php index.html index.htm;

    # access/error-logs per Default aus (keine Besucher-Spuren im Dateisystem).
    # Nur bei Bedarf zu Debugging-Zwecken aktivieren und später wieder aus.
    #access_log /var/log/nginx/www-kernel-error-de-access_tor.log combined;
    #error_log  /var/log/nginx/www-kernel-error-de-error_tor.log;

    add_header X-Robots-Tag      "noarchive, noimageindex" always;
    add_header Permissions-Policy "interest-cohort=()"    always;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~* \.(css|gif|ico|jpeg|jpg|js|png|svg|webp|woff2?)$ {
        access_log off;
        expires 30d;
        add_header Cache-Control "public";
        try_files $uri =404;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_index index.php;

        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO       $fastcgi_path_info;

        # Cache hart deaktivieren - kein gemeinsamer Pool mit dem Clearnet-vHost
        fastcgi_no_cache      1;
        fastcgi_cache_bypass  1;
    }
}

Ein paar Punkte sind bewusst so gewählt:

• listen 127.0.0.6:80: Die Adresse ist frei wählbar innerhalb von 127.0.0.0/8, muss aber mit dem HiddenServicePort in der torrc übereinstimmen. Ich nehme bewusst nicht 127.0.0.1, damit der Onion-Listener klar vom Standard-Loopback zu unterscheiden ist – hilft beim Debugging und bei sockstat.
• Kein TLS: Zwischen Tor-Daemon und Nginx liegt nur die Loopback-Schnittstelle, dafür braucht es kein Zertifikat. Und .onion-Zertifikate gibt es nur über kommerzielle CAs (Extended Validation), Let’s Encrypt stellt keine aus. Der eigentliche Schutz auf dem Draht kommt komplett aus dem Tor-Protokoll – End-to-End verschlüsselt vom Tor-Client bis hier zur Loopback-Adresse.
• Getrennte Logs (per Default aus): Im Normalbetrieb sind access_log und error_log im Onion-vHost auskommentiert – so entstehen erst gar keine Dateien mit IP-, User-Agent- oder Pfad-Informationen der Onion-Besucher. Zum Debugging lassen sich die beiden Zeilen kurz einkommentieren, danach bewusst wieder aus. Wichtig ist auf jeden Fall, dass Clearnet- und Onion-Zugriffe nie im gleichen Logfile landen – über Zeitstempel und User-Agent-Muster ließen sich sonst leicht Korrelationen bilden.
• X-Robots-Tag: noarchive, noimageindex verhindert, dass Suchmaschinen die Onion-Variante cachen oder Bilder indexieren. noindex setze ich bewusst nicht – wer die Onion-Adresse kennt, darf sie auch in Verzeichnissen auftauchen lassen.
• Permissions-Policy: interest-cohort=() schaltet Googles FLoC-/Topics-API explizit aus. Für einen Privacy-Blog im Tor-Netz ist das eher symbolisch, schadet aber nicht.

Der Knackpunkt: Cache-Isolation

Der Clearnet-vHost nutzt einen FastCGI-Cache (fastcgi_cache_path), damit WordPress nicht jede Seitenauslieferung neu rendern muss. Das ist für einen Blog mit statischen Inhalten ein riesiger Performance-Boost. Genau dieser Cache ist aber auch der Punkt, an dem man sich beim Onion-Betrieb ins Knie schießen kann.

Wenn der Onion-vHost denselben Cache-Pool verwenden würde, könnten zwei unerwünschte Effekte auftreten:

• Cross-Origin-Leakage im HTML: WordPress baut absolute Links anhand der siteurl/home-Option. Die steht auf https://www.kernel-error.de. Wenn eine Clearnet-Anfrage cached, landen in jedem Link Clearnet-URLs im Cache-Eintrag. Liefert der Onion-vHost dann dieselbe Seite aus dem Cache, sieht der Tor-Besucher eine Seite voller Clearnet-Links – und jeder Klick würde ihn aus dem Hidden Service hinauskatapultieren.
• Fingerprinting über Cache-Keys: Abhängig davon, wer die Seite zuerst aufgerufen hat, liefert der Cache deterministisch „warme“ oder „kalte“ Antworten. Ein Angreifer, der beide Varianten beobachtet, kann Rückschlüsse ziehen. Klein, aber unnötig.

Die Lösung ist bewusst stumpf: Der Onion-vHost bekommt gar keinen fastcgi_cache_path-Verweis. Zusätzlich stehen im location ~ \.php$-Block die beiden Schalter fastcgi_no_cache 1 und fastcgi_cache_bypass 1, damit selbst bei versehentlich geerbter Konfiguration weder gelesen noch geschrieben wird. Jeder Request rendert frisch durch den FPM.

Bei der Besucher-Zahl über den Hidden Service ist das unkritisch. Die Clearnet-Seite bleibt gleichzeitig durch ihren eigenen Cache schnell – beide Welten profitieren von ihrer jeweils passenden Strategie.

Der Onion-Location-Header und die Meldung im Tor Browser

Damit Besucher überhaupt erfahren, dass es eine Onion-Variante gibt, setzt der Clearnet-vHost zwei zusätzliche Header:

add_header Onion-Location "http://jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion$request_uri" always;
add_header Alt-Svc        'http="jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion:80"; ma=86400' always;

Der Onion-Location-Header ist ein vom Tor-Project definiertes Signal. Ruft man den Blog im Tor Browser (Version 9.5 oder neuer) über die Clearnet-Adresse auf, blendet der Browser eine unauffällige „.onion available“-Schaltfläche in der URL-Leiste ein und bietet an, auf die Hidden-Service-Variante umzuschalten. Das ist die „Meldung“, die einige irritiert: Sie kommt nicht von meiner Seite, sondern direkt vom Tor Browser, der den Header interpretiert.

Wichtig dabei: Der Tor Browser akzeptiert den Header nur, wenn ein paar Bedingungen erfüllt sind. Das verhindert, dass ein kompromittierter Server Besucher auf fremde Hidden Services umlenken kann:

• Die Ursprungsseite muss per HTTPS ausgeliefert worden sein.
• Die im Header angegebene .onion-Adresse muss wohlgeformt sein (v3, 56 Zeichen, Base32).
• Die Nutzerin muss die Umleitung aktiv bestätigen – es gibt keine automatische Weiterleitung.

Der Alt-Svc-Header (RFC 7838) ist die generische Variante. Einige alternative Clients nutzen ihn, um Alternative-Services im Hintergrund vorzumerken. Für den Tor Browser ist primär der Onion-Location-Header relevant, Alt-Svc ist eher Absicherung.

DNS als zusätzliche Verifikation

Ein Header auf der Seite ist eine gute Sache – wer dem Server vertraut, bekommt den Hinweis auf den Onion-Service. Was aber, wenn jemand meine Angabe kontrollieren will, ohne die Seite selbst aufgerufen zu haben?

Dafür habe ich einen einfachen TXT-Record im DNS hinterlegt:

dig +short TXT www.kernel-error.de
"onion=jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion"

Das Format onion=… ist kein offizieller Standard, sondern meine persönliche Konvention. Es gibt einen Internet-Draft von Alec Muffett (draft-muffett-same-origin-onion-v2), der einen ähnlichen Ansatz beschreibt, aber als RFC nie durchgegangen ist. Bis sich etwas Standardisiertes etabliert, bleibe ich bei meinem einfachen Ansatz: Wer wissen will, ob die Onion-Adresse wirklich zu mir gehört, vergleicht den Header, den TXT-Record und meine öffentlichen Ankündigungen. Die Zone selbst ist DNSSEC-signiert, der TXT-Record ist also nicht spürbar manipulierbar, solange der Resolver DNSSEC validiert.

Wem das zu wacklig ist: Für .onion gibt es auch kommerzielle Zertifikate (DigiCert stellt EV-Zertifikate für Onion-Services aus). Damit könnte man die Onion-Seite zusätzlich hinter HTTPS legen und in der Tor-Browser-URL-Leiste wäre die Organisation sichtbar. Für einen privaten Blog ist der Aufwand und die Kosten aber deutlich höher als der Nutzen.

Warum kein TLS-Zertifikat nötig ist

Der Punkt irritiert am Anfang fast jeden: Eine Webseite ohne HTTPS, im Jahr 2026, fühlt sich einfach falsch an. Wenn man sich aber anschaut, wofür TLS im Clearnet eigentlich da ist, wird schnell klar, warum es bei einem Tor Hidden Service tatsächlich überflüssig ist.

TLS erfüllt zwei Aufgaben gleichzeitig:

• Vertraulichkeit auf der Leitung: Niemand zwischen Client und Server soll mitlesen können – weder der ISP, noch das WLAN im Cafe, noch ein Transit-Provider.
• Identitätsnachweis des Servers: Der Client muss sicher sein können, dass er tatsächlich mit dem Server spricht, der hinter dem Domainnamen steht. Diese Aufgabe übernimmt die CA-Kette, die das Zertifikat an den DNS-Namen bindet.

Bei einem Tor Hidden Service sind beide Aufgaben bereits in das Protokoll selbst eingebaut – ohne dass irgendwo ein Zertifikat im Spiel wäre:

• Vertraulichkeit kommt aus dem Tor-Tunnel: Der Datenstrom zwischen Client und Hidden Service lauft durch mehrere übereinander gelegte Verschlüsselungsschichten. Jedes Relay kann nur die eigene Schicht entfernen und sieht dadurch nur das nächste Ziel, nicht den Inhalt und auch nicht den gesamten Pfad. Auf dem Draht ist der Traffic zu keinem Zeitpunkt im Klartext zu sehen – ein zusätzliches TLS würde dieselbe Eigenschaft nur ein zweites Mal liefern.
• Authentizität steckt in der Adresse: Die 56 Zeichen einer v3-Onion sind keine willkürliche Zeichenfolge, sondern die Base32-Darstellung eines ed25519-Public-Keys (plus Checksumme und Versionsbyte). Beim Verbindungsaufbau fordert der Tor-Client vom Server eine Signatur an und prüft sie gegen genau diesen Public-Key. Passt sie nicht, kommt keine Verbindung zustande. Damit übernimmt die Adresse selbst die Rolle, die im Clearnet das Zertifikat spielt – nur dass hier keine CA existieren muss, die das beglaubigt.

Anders formuliert: Der Hidden Service ist von der ersten Byte an selbst-authentisierend. Die Sicherheitsgarantie steht und fällt mit der korrekten Onion-Adresse, nicht mit einem Dritten, der sie beglaubigen müsste. Deshalb hat Let’s Encrypt für .onion-Adressen bewusst nie Zertifikate ausgestellt – es gibt schlicht nichts, was eine CA hier noch verifizieren könnte, was nicht schon durch die Adresse selbst belegt wäre.

Den einzigen verbleibenden Nutzen eines Zertifikats – das sichtbare Organisationskürzel in der Tor-Browser-URL-Leiste bei EV-Zertifikaten – kann man sich für einen privaten Blog guten Gewissens sparen.

Firewall und Systemhärtung

Die schöne Eigenschaft eines Hidden Service: Es muss kein zusätzlicher Port nach außen geöffnet werden. Der Tor-Prozess baut nur ausgehende Verbindungen auf, der Nginx-Onion-vHost lauscht nur auf der Loopback-Adresse. Aus Sicht einer Firewall ändert sich durch den Hidden Service gar nichts.

Trotzdem gibt es ein paar Punkte, die ich bewusst setze:

• Jail-Isolation: Tor und Nginx laufen in derselben FreeBSD-Jail. Die Jail hat nur die öffentliche IP für den Clearnet-Nginx und separate Loopback-Adressen für interne Dienste. Dadurch kann der Tor-Prozess nicht „aus Versehen“ auf andere Dienste zugreifen – und er teilt sich seinen Kernel-Namespace nur mit dem, was ich bewusst in dieselbe Jail gelegt habe.
• Dateirechte: /var/db/tor/hidden_service/ gehört dem _tor-User, mode 700. Das private Schlüsselmaterial muss genauso behandelt werden wie ein TLS-Private-Key – wer es hat, kann meine .onion übernehmen.
• WordPress-Härtung: Der Login (wp-admin, wp-login.php) wird über das Plugin WPS Hide Login auf eine nicht-offensichtliche URL gelegt und ist ohnehin nur via Clearnet mit HTTPS erreichbar. Im Onion-vHost wird die Login-URL weder verlinkt noch erwähnt. Administration findet ausschließlich über die Clearnet-Variante statt.
• Keine Log-Korrelation: Die getrennten Access-Logs habe ich schon erwähnt. Zusätzlich analysiere ich sie separat und führe keine IPs aus dem Clearnet-Log mit dem Onion-Log zusammen. Das wäre technisch möglich, würde aber den Sinn des Setups konterkarieren.
• Keine externen Ressourcen: Das Theme und die eingebundenen Plugins laden keine Fonts von Google, keine Scripts von CDNs, keine Gravatare aus der Welt. Wenn ein Element doch mal nach www.kernel-error.de auflaufen sollte (etwa durch ein falsch konfiguriertes Plugin), würde der Tor Browser das als Mixed-Origin-Request anzeigen und viele Nutzerinnen würden es nicht mehr laden – das fällt dann schnell auf und ich fixe es.

Warum das als „sicher“ gilt

„Sicher“ ist immer relativ – gegenüber welchem Angreifer, unter welchem Modell? Ein paar Eigenschaften kann man aber konkret benennen:

• End-to-End verschlüsselt: Tor baut zwischen Client und Hidden Service einen dreistufigen Tunnel durch Rendezvous- und Introduction-Points. Keiner der Zwischenknoten sieht, wer mit wem spricht oder was übertragen wird. Auf dem Draht sieht außerdem niemand eine .onion-Adresse – die Rendezvous-Logik wählt den Zielknoten indirekt.
• Kryptografische Authentizität der Adresse: Die 56 Zeichen der v3-Onion sind der Base32-codierte ed25519-Public-Key samt Checksumme und Versionsbyte. Wer die richtige Adresse getippt oder kopiert hat, landet kryptografisch garantiert auf dem Server, der den zugehörigen privaten Schlüssel hat. Keine CA, kein DNS, kein Zwischenhändler kann das verändern, ohne dass die Adresse anders aussieht.
• Kein TLS nötig: Verschlüsselung kommt aus dem Tor-Tunnel, Authentizität aus der Adresse selbst. Details dazu stehen weiter oben im eigenen Abschnitt – kurz: TLS würde die Eigenschaften nicht ergänzen, sondern nur doppeln.
• Anonymität der Besucher: Der Server sieht keine echte Client-IP, nur einen Rendezvous-Punkt im Tor-Netz. Zensur und Traffic-Analyse auf dem letzten Stück entfallen vollständig.
• Vertraulichkeit für mich: Der Server ist nicht öffentlich erreichbar, es gibt keinen offenen Port, den man mit nmap finden könnte. Die öffentliche IP des Servers ist durch die Tor-Rendezvous-Logik nicht aus dem Netzwerkverkehr ableitbar, solange ich nicht durch Fehlkonfiguration (etwa hart verlinkte Clearnet-URLs im HTML) Hinweise leake.

Stolperfallen und was man besser lässt

• WordPress-URLs: siteurl und home bleiben auf der Clearnet-URL. Einige Anleitungen empfehlen, bei Aufruf der Onion-Variante die URL dynamisch umzuschreiben. Das habe ich bewusst nicht gemacht – es führt zu kaputten Canonical-Links, mischt Content- und Admin-Bereich und bricht meist den Blöck-Editor. Stattdessen akzeptiere ich, dass im Onion-HTML auch mal eine Clearnet-Link vorkommt (etwa im Footer), und setze darauf, dass der Tor Browser korrekt warnt, bevor er dort hinschickt.
• Externe Embeds: YouTube-Videos, Twitter-Embeds, Gravatare – alles Dinge, die eine Onion-Seite sofort deanonymisieren könnten, wenn sie geladen würden. Das Theme und die Plugins auf diesem Blog laden bewusst keine externen Ressourcen.
• Redis/Object-Cache: Der Object-Cache speichert keine gerenderten HTML-Seiten, sondern nur WP-interne Objekte. Hier ist die Vermischung unkritisch, weil die resultierenden URLs erst beim Rendern (durch den jeweiligen vHost) entstehen.
• FastCGI-Cache: Wie oben beschrieben – für die Onion-Variante komplett deaktiviert. Wer es trotzdem aktivieren will, braucht zwingend einen eigenen fastcgi_cache_path, eigenes Key-Schema und muss den Host-Teil im Cache-Key haben.
• Monitoring: Klassische Uptime-Checks von außen funktionieren auf .onion-Adressen nicht ohne weiteres. Dienste wie Uptime-Kuma können inzwischen Tor-Proxy nutzen, ansonsten hilft ein kleiner curl --socks5-hostname-Check.

Was man noch härter machen kann

Für meinen privaten Blog halte ich das beschriebene Setup für ein solides Minimum. Wer seinen Hidden Service strenger absichern will – etwa weil dort Whistleblower-Material, Redaktions-Inhalte oder andere wirklich schutzwürdige Dinge liegen – sollte ein paar zusätzliche Punkte beachten:

• Zusätzliche HTTP-Header: Referrer-Policy: no-referrer verhindert, dass beim Klick auf einen externen Link die .onion-URL als Referer mitgeschickt wird. Content-Security-Policy (restriktiv, z. B. default-src 'self'; img-src 'self' data:;) blockt Mixed-Origin-Requests hart, bevor der Browser sie überhaupt versucht. Dazu X-Content-Type-Options: nosniff und X-Frame-Options: DENY, damit Clickjacking und MIME-Sniffing ausgeschlossen sind.
• server_tokens off: Im Haupt-vHost ist der Nginx-Version-String schon länger abgeschaltet und durch einen eigenen Custom-Header ersetzt. Im Onion-vHost gehört server_tokens off; genauso rein – ohne das steht die Nginx-Version in jeder 404-Seite und erleichtert Fingerprinting.
• Tor-Daemon härten: Sandbox 1 in der torrc aktiviert unter FreeBSD Capsicum und unter Linux Seccomp-Filter. Damit bekommt der Tor-Prozess nur die Syscalls, die er wirklich braucht. Zusätzlich lässt sich mit HiddenServiceEnableIntroDoSDefense 1 sowie HiddenServiceEnableIntroDoSRatePerSec und HiddenServiceEnableIntroDoSBurstPerSec ein integrierter DoS-Schutz am Introduction-Point aktivieren – seit Tor 0.4.2 gibt es das als Plugin-freie Bordmittel.
• Client Authorization: Für wirklich nicht-öffentliche Dienste kennt Tor einen Mechanismus, bei dem nur Clients mit passendem x25519-Key-Paar den Hidden Service überhaupt erreichen. Die Adresse ist dann zwar im Tor-Netz bekannt, ohne die Private-Key-Datei auf dem Client kommt man aber keinen Zentimeter weit. Für einen öffentlichen Blog unpassend, für ein Journalisten-Dropbox-Setup die wichtigste Absicherung überhaupt.
• Offline-Backup der Hidden-Service-Keys: Wenn der Inhalt von /var/db/tor/hidden_service/ verloren geht, ist die .onion-Adresse weg – es gibt keinen Weg, sie wiederherzustellen. Das private Schlüsselmaterial gehört deshalb auf einen verschlüsselten Offline-Datenträger und sollte genauso behandelt werden wie ein TLS-Root-Key. Wer die Adresse überträgt, überträgt gleichzeitig die Fähigkeit, sie zu betreiben – das ist nichts, was in einem Cloud-Backup liegen sollte.
• Jail-/Container-Trennung von Tor und Web: Aktuell laufen Tor-Daemon und Nginx in derselben FreeBSD-Jail, weil sie über die Loopback-Adresse sowieso miteinander sprechen müssen. Wer paranoider sein will, packt den Tor-Prozess in eine eigene Jail mit eigener Loopback-IP und forwardet nur den HiddenService-Port – dann kann ein kompromittierter WordPress-Prozess nicht mal versehentlich an die Schlüsseldateien. Für mich persönlich ist der Aufwand zurzeit nicht gerechtfertigt, für einen Hochrisiko-Service aber eine ernsthafte Option.
• Ehrliche Einschätzung zur Anonymität des Betreibers: Wer einen Hidden Service betreibt, um die eigene Identität zu schützen, muss auch alles drumherum sauber haben – Domain-Whois, Zertifikats-SANs auf dem Clearnet-Host, Uptime-Monitoring, Backups, Zeitstempel in Git-Commits, selbst die Systemzeit auf dem Server. Die .onion-Adresse alleine macht den Betreiber nicht anonym. Sie ist ein Baustein, kein Gesamtkonzept.

Für diesen Blog ist das bewusst nicht alles umgesetzt. Ich veröffentliche unter Klarnamen und möchte nur die Daten meiner Besucher besser schützen. Für jemanden, der aus guten Gründen wirklich anonym bleiben muss, sind die Punkte oben Pflicht, nicht Kür.

Fazit

Ein Tor Hidden Service für einen bestehenden WordPress-Blog ist überraschend geradlinig aufzusetzen. Die technische Umsetzung umfasst im Kern einen Tor-Daemon mit v3-Konfiguration, einen getrennten Nginx-vHost ohne HTTPS und ohne FastCGI-Cache, sowie zwei Header im Clearnet-vHost. Der Aufwand bleibt überschaubar, der Gewinn an Erreichbarkeit und Metadaten-Minimierung ist messbar.

Wer die Adresse im Tor Browser aufruft, bekommt exakt den gleichen Blog zu sehen – nur ohne TLS-Handshake, ohne Exit-Node und ohne Spur im eigenen DNS-Resolver. Die Seite wird nicht häufig aus dem Tor-Netz aufgerufen, aber sie ist für die Fälle da, in denen sie gebraucht wird. Und ehrlich gesagt: Es macht auch einfach Spaß, ein System so zu bauen, dass beide Welten sauber nebeneinander existieren.

Siehe auch: HTTP/3 und QUIC, Post-Quantum TLS für Nginx, TLS-ECDHE einfach erklärt

Fragen? Einfach melden.