BTCPay macht Tor in v2.4.5 für Docker-Nutzer zur Option

BTCPay Server hat Tor aus den automatisch enthaltenen Komponenten seiner standardmäßigen Docker-Bereitstellung entfernt. Das gilt ab Version 2.4.5, die am 5. Oktober angekündigt und am 6. Oktober auf GitHub veröffentlicht wurde. Betreiber, die auf Onion-Zugriff angewiesen sind, einschließlich der Onion-Adresse ihres Servers, müssen Tor bei ihrem nächsten Setup oder Update ausdrücklich auswählen, damit der Dienst weiterläuft.

Damit wird ein zuvor standardmäßig gebündelter Dienst zu einer Konfigurationsentscheidung des Administrators. Docker-Bereitstellungen werden aus Fragmenten zusammengesetzt, also aus den Konfigurationskomponenten, die den Stack bilden. Tor befindet sich nun in einem optionalen Fragment statt im zentralen BTCPay-Server-Fragment. Nach dem Update lautet der Befehl zur erneuten Aktivierung: sudo btcpay-fragments add opt-add-tor.

BTCPay erklärt, dass Tor weiterhin unterstützt wird und vorhandene Daten in den aktuellen Tor-Volumes verbleiben, sodass gespeicherte Daten erhalten bleiben. Der fortgesetzte Onion-Zugriff hängt jedoch davon ab, dass Tor in der Bereitstellung enthalten ist und ausgeführt wird. Administratoren sollten die Änderungen an der Bereitstellung vor dem Update prüfen. Mit btcpay-fragments show lässt sich die Konfiguration einsehen. Der schreibgeschützte Befehl zeigt gespeicherte zusätzliche und ausgeschlossene Fragmente neben den effektiv verwendeten Fragmenten aus dem zuletzt erzeugten Manifest.

Warum das wichtig ist

Für Händler und Zahlungsabwickler, die BTCPay betreiben, ist die Standardkonfiguration häufig zugleich die tatsächliche Konfiguration. Wer ein Update durchführt, ohne die Versionshinweise zu lesen, könnte die Onion-Adresse, von der Kunden oder interne Tools abhängen, unbemerkt verlieren, ohne dass ein Datenverlust auf das Problem hinweist. Die Änderung macht Tor aus einer standardmäßig vorhandenen Funktion zu einer bewussten Datenschutzentscheidung.

Auswirkungen auf den Markt

Die Version 2.4.5 enthält außerdem eine inkompatible Änderung für ausgehende HTTP-Anfragen. Ziele in privaten Netzwerken werden für Lightning-Verbindungen, LNURL-Anfragen, URLs für Rechnungsbenachrichtigungen und Webhooks standardmäßig blockiert. Diese Maßnahme soll Server-Side Request Forgery (SSRF) verhindern. Betreiber, die absichtlich private Dienste verwenden, müssen die erforderlichen Ziele über ssrfexceptions freigeben, anschließend die Anwendung neu starten und die betroffene Integration testen. Wegen der Tor-Opt-in-Änderung und der SSRF-Härtung sollten Administratoren dieses Update als Konfigurationsprüfung und nicht als routinemäßigen Patch behandeln.