Los operadores que ejecutan BTCPay Server, el software de pagos en Bitcoin autoalojado, mediante su despliegue estándar de Docker deben seleccionar explícitamente Tor en su próxima configuración o actualización si desean conservar el acceso onion. El cambio, introducido con la versión 2.4.5, elimina Tor de los componentes incluidos automáticamente, convirtiendo un servicio que antes venía incluido en una decisión de configuración del administrador.

BTCPay detalló el cambio de despliegue en un anuncio fechado el 5 de octubre que acompañó a la versión 2.4.5, mientras que la página oficial de versiones en GitHub registra el lanzamiento del software el 6 de octubre. Para las instalaciones existentes, el punto de activación relevante es su próxima configuración o actualización de Docker, lo que significa que el componente puede desaparecer de un despliegue en funcionamiento como parte del mantenimiento rutinario, a menos que el operador lo reactive.

El ajuste es significativo para los operadores de Docker que dependen de Tor, incluido el acceso a través de la dirección onion de su servidor, el punto de acceso .onion expuesto por los servicios ocultos de Tor, y que anteriormente recibían el servicio a través del fragmento principal de BTCPay Server. Los fragmentos son los componentes de configuración utilizados para ensamblar la pila de Docker.

Cómo reactivar Tor después de la actualización

BTCPay recomienda a los administradores revisar los cambios de despliegue antes de actualizar. Una vez en la versión 2.4.5, la instrucción para habilitar Tor es:

sudo btcpay-fragments add opt-add-tor

Tor sigue siendo compatible, y BTCPay indica que los datos existentes permanecen en los volúmenes actuales de Tor. Esto preserva los datos almacenados, aunque el acceso onion continuado sigue dependiendo de incluir y ejecutar Tor en el despliegue.

Según la documentación de BTCPay Server, el fragmento opcional de Tor opt-add-tor agrega servicios ocultos y conectividad onion seleccionada. Los operadores pueden inspeccionar su configuración con btcpay-fragments show, un comando que no modifica nada e informa los fragmentos adicionales y excluidos guardados junto con los fragmentos efectivos del último manifiesto generado. Revisar esa salida antes de la actualización y de nuevo después de agregar el fragmento brinda a los administradores un registro del antes y el después de lo que su pila está ejecutando realmente. Los comandos que alteran fragmentos requieren privilegios de root y reaplican la configuración de inmediato.

Los servicios privados necesitan excepciones separadas

Las notas de la versión 2.4.5 también identifican un cambio importante para las solicitudes HTTP salientes: los destinos de red privada se bloquean de forma predeterminada para las conexiones Lightning, las solicitudes LNURL, las URL de notificación de facturas y los webhooks. La restricción tiene como objetivo prevenir el server-side request forgery (SSRF), una clase de vulnerabilidad en la que una aplicación es engañada para enviar solicitudes a recursos de red internos o restringidos.

Dado que ambos cambios llegan en la misma versión, una sola actualización puede afectar dos partes distintas de la configuración de un operador: la disponibilidad onion y las llamadas salientes a direcciones privadas. Con esa protección habilitada, los operadores que utilizan intencionalmente servicios privados deben permitir los destinos necesarios a través de ssrfexceptions. La guía de operadores de BTCPay indica reiniciar la aplicación y probar la integración afectada después de cambiar la configuración.