Operatorzy uruchamiający BTCPay Server, samoobsługowe oprogramowanie płatności Bitcoin, poprzez jego standardowe wdrożenie Docker muszą przy najbliższej konfiguracji lub aktualizacji wyraźnie wybrać Tora, jeśli chcą zachować dostęp onion. Zmiana, wprowadzona w wersji 2.4.5, usuwa Tora z automatycznie dołączanych komponentów, przekształcając wcześniej dołączaną usługę w wybór konfiguracyjny administratora.

BTCPay opisał zmianę we wdrożeniu w ogłoszeniu z 5 października towarzyszącym wersji 2.4.5, podczas gdy oficjalna strona wydań na GitHubie odnotowuje publikację oprogramowania 6 października. W przypadku istniejących instalacji punktem wyzwalającym jest ich najbliższa konfiguracja lub aktualizacja Dockera — co oznacza, że komponent może wypaść z działającego wdrożenia w ramach rutynowej konserwacji, jeśli operator nie włączy go ponownie.

Zmiana ma znaczenie dla operatorów Dockera polegających na Torze, w tym dostępu przez adres onion serwera — punkt końcowy .onion udostępniany przez ukryte usługi Tora — którzy wcześniej otrzymywali tę usługę poprzez podstawowy fragment BTCPay Server. Fragmenty to komponenty konfiguracyjne używane do składania stosu Dockera.

Ponowne włączenie Tora po aktualizacji

BTCPay zaleca administratorom zapoznanie się ze zmianami we wdrożeniu przed aktualizacją. Po przejściu na wersję 2.4.5 instrukcja włączania Tora wygląda następująco:

sudo btcpay-fragments add opt-add-tor

Tor pozostaje wspierany, a BTCPay zapewnia, że istniejące dane pozostają w bieżących wolumenach Tora. Chroni to zapisane dane, choć dalszy dostęp onion nadal zależy od dołączenia i uruchomienia Tora we wdrożeniu.

Zgodnie z dokumentacją BTCPay Server opcjonalny fragment Tora opt-add-tor dodaje ukryte usługi i wybrany dostęp onion. Operatorzy mogą sprawdzić swoją konfigurację za pomocą btcpay-fragments show, polecenia, które niczego nie zmienia i raportuje zapisane dodatkowe oraz wykluczone fragmenty wraz z obowiązującymi fragmentami z ostatniego wygenerowanego manifestu. Sprawdzenie tego wyniku przed aktualizacją, a następnie ponownie po dodaniu fragmentu, daje administratorom zapis stanu przed i po, pokazujący, co stos faktycznie uruchamia. Polecenia zmieniające fragmenty wymagają uprawnień root i natychmiast stosują konfigurację ponownie.

Usługi prywatne wymagają osobnych wyjątków

Informacje o wydaniu 2.4.5 wskazują również na zmianę łamiącą w przypadku wychodzących żądań HTTP: cele w sieciach prywatnych są domyślnie blokowane dla połączeń Lightning, żądań LNURL, adresów URL powiadń o fakturach i webhooków. Ograniczenie ma zapobiegać server-side request forgery (SSRF), klasie podatności, w której aplikacja zostaje podstępnie skłoniona do wysyłania żądań do wewnętrznych lub w inny sposób ograniczonych zasobów sieciowych.

Ponieważ obie zmiany trafiają w tym samym wydaniu, jedna aktualizacja może dotknąć dwóch odrębnych części konfiguracji operatora: dostępności onion i wychodzących wywołań do adresów prywatnych. Przy włączonej ochronie operatorzy celowo korzystający z usług prywatnych muszą zezwolić na wymagane cele poprzez ssrfexceptions. Przewodnik operatora BTCPay zaleca ponowne uruchomienie aplikacji i przetestowanie dotkniętej integracji po zmianie ustawienia.