Operators die BTCPay Server, de zelf gehoste Bitcoin-betalingssoftware, via de standaard Docker-implementatie draaien, moeten Tor bij hun volgende installatie of update expliciet selecteren als ze onion-toegang willen behouden. De wijziging, geïntroduceerd met versie 2.4.5, verwijdert Tor uit de automatisch opgenomen onderdelen, waardoor een voorheen gebundelde dienst een configuratiekeuze van de beheerder wordt.

BTCPay beschreef de wijziging in de implementatie in een aankondiging van 5 oktober die bij versie 2.4.5 hoorde, terwijl de officiële GitHub-releasepagina de softwarerelease op 6 oktober vermeldt. Voor bestaande installaties is de relevante trigger hun volgende Docker-installatie of -update — wat betekent dat het onderdeel bij routinematig onderhoud uit een draaiende implementatie kan verdwijnen, tenzij de operator er opnieuw voor kiest.

De aanpassing is belangrijk voor Docker-operators die afhankelijk zijn van Tor, waaronder toegang via het onion-adres van hun server — het .onion-eindpunt dat door Tors hidden services wordt aangeboden — en die de dienst voorheen via het core BTCPay Server-fragment kregen. Fragmenten zijn de configuratieonderdelen waarmee de Docker-stack wordt samengesteld.

Tor na de update opnieuw inschakelen

BTCPay adviseert beheerders om de wijzigingen in de implementatie door te nemen voordat ze updaten. Zodra versie 2.4.5 actief is, luidt de instructie om Tor in te schakelen:

sudo btcpay-fragments add opt-add-tor

Tor blijft ondersteund, en BTCPay zegt dat bestaande gegevens in de huidige Tor-volumes blijven staan. Daarmee blijven opgeslagen gegevens bewaard, al blijft voortgezette onion-toegang afhankelijk van het opnemen en draaien van Tor in de implementatie.

Volgens de documentatie van BTCPay Server voegt het optionele Tor-fragment opt-add-tor hidden services en geselecteerde onion-connectiviteit toe. Operators kunnen hun configuratie inspecteren met btcpay-fragments show, een opdracht die niets wijzigt en naast de opgeslagen toegevoegde en uitgesloten fragmenten ook de effectieve fragmenten uit de laatst gegenereerde manifest rapporteert. Die uitvoer vóór de update controleren en opnieuw na het toevoegen van het fragment geeft beheerders een voor-en-na-overzicht van wat hun stack feitelijk draait. Opdrachten die fragmenten wijzigen vereisen root-rechten en passen de setup direct opnieuw toe.

Privédiensten vereisen aparte uitzonderingen

De releaseverslagen 2.4.5 melden ook een breaking change voor uitgaande HTTP-verzoeken: bestemmingen op privénetwerken worden standaard geblokkeerd voor Lightning-verbindingen, LNURL-verzoeken, factuurmeldings-URL's en webhooks. De beperking is bedoeld om server-side request forgery (SSRF) te voorkomen, een klasse van kwetsbaarheden waarbij een applicatie wordt misleid om verzoeken te sturen naar interne of anderszins beperkte netwerkbronnen.

Omdat beide wijzigingen in dezelfde release zitten, kan één update twee afzonderlijke onderdelen van de setup van een operator raken: de beschikbaarheid van onion en uitgaande aanroepen naar privéadressen. Nu deze beveiliging is ingeschakeld, moeten operators die bewust privédiensten gebruiken de benodigde bestemmingen toestaan via ssrfexceptions. De operatorgids van BTCPay zegt dat de applicatie opnieuw moet worden gestart en dat de betreffende integratie moet worden getest na het wijzigen van de instelling.