Betreiber, die die selbst gehostete Bitcoin-Zahlungssoftware BTCPay Server über die Standard-Docker-Bereitstellung betreiben, müssen Tor bei ihrem nächsten Setup oder Update ausdrücklich auswählen, wenn sie den Onion-Zugriff behalten wollen. Die mit Version 2.4.5 eingeführte Änderung entfernt Tor aus den automatisch enthaltenen Komponenten und macht aus einem bisher gebündelten Dienst eine Konfigurationsentscheidung des Administrators.

BTCPay erläuterte die Änderung der Bereitstellung in einer Ankündigung vom 5. Oktober, die zusammen mit Version 2.4.5 veröffentlicht wurde, während die offizielle GitHub-Release-Seite das Software-Release auf den 6. Oktober datiert. Bei bestehenden Installationen ist der maßgebliche Auslöser das nächste Docker-Setup oder Update – das heißt, die Komponente kann im Rahmen routinemäßiger Wartung aus einer laufenden Bereitstellung entfallen, sofern der Betreiber sich nicht erneut dafür entscheidet.

Die Anpassung ist bedeutend für Docker-Betreiber, die auf Tor angewiesen sind – einschließlich des Zugriffs über die Onion-Adresse ihres Servers, den .onion-Endpunkt, der von Tors Hidden Services bereitgestellt wird – und die den Dienst zuvor über das Kern-BTCPay-Server-Fragment bezogen. Fragmente sind die Konfigurationskomponenten, aus denen der Docker-Stack zusammengesetzt wird.

Tor nach dem Update wieder aktivieren

BTCPay rät Administratoren, die Änderungen an der Bereitstellung vor dem Update zu prüfen. Ab Version 2.4.5 lautet die Anweisung zum Aktivieren von Tor:

sudo btcpay-fragments add opt-add-tor

Tor wird weiterhin unterstützt, und BTCPay erklärt, dass bestehende Daten in den aktuellen Tor-Volumes verbleiben. Damit bleiben gespeicherte Daten erhalten; der fortgesetzte Onion-Zugriff hängt dennoch davon ab, dass Tor in der Bereitstellung enthalten ist und läuft.

Laut der BTCPay-Server-Dokumentation fügt das optionale Tor-Fragment opt-add-tor Hidden Services und ausgewählte Onion-Konnektivität hinzu. Betreiber können ihre Konfiguration mit btcpay-fragments show einsehen – ein Befehl, der nichts verändert und die gespeicherten zusätzlichen sowie ausgeschlossenen Fragmente neben den wirksamen Fragmenten des zuletzt generierten Manifests ausweist. Die Prüfung dieser Ausgabe vor dem Update und erneut nach dem Hinzufügen des Fragments gibt Administratoren einen Vorher-Nachher-Überblick darüber, was ihr Stack tatsächlich ausführt. Befehle, die Fragmente verändern, erfordern Root-Rechte und wenden das Setup sofort erneut an.

Private Dienste benötigen separate Ausnahmen

Die Release-Notes zu 2.4.5 identifizieren außerdem eine Breaking Change für ausgehende HTTP-Anfragen: Private Netzwerkziele werden standardmäßig für Lightning-Verbindungen, LNURL-Anfragen, Rechnungs-Benachrichtigungs-URLs und Webhooks blockiert. Die Beschränkung soll Server-Side Request Forgery (SSRF) verhindern, eine Klasse von Schwachstellen, bei der eine Anwendung dazu verleitet wird, Anfragen an interne oder anderweitig eingeschränkte Netzwerkressourcen zu senden.

Da beide Änderungen im selben Release enthalten sind, kann ein einzelnes Update zwei getrennte Bereiche des Setups eines Betreibers betreffen: die Onion-Verfügbarkeit und ausgehende Aufrufe privater Adressen. Beiiertem Schutz müssen Betreiber, die private Dienste bewusst nutzen, die erforderlichen Ziele über ssrfexceptions zulassen. Der BTCPay-Betreiberleitfaden empfiehlt, die Anwendung nach der Änderung der Einstellung neu zu starten und die betroffene Integration zu testen.