BTCPay v2.4.5 hace Tor opcional en Docker

BTCPay Server ha eliminado Tor de los componentes incluidos automáticamente en su implementación estándar de Docker a partir de la versión 2.4.5, anunciada el 5 de octubre y publicada en GitHub el 6 de octubre. Los operadores que dependen del acceso onion, incluida la dirección onion de su servidor, ahora deben seleccionar Tor explícitamente durante su próxima configuración o actualización para mantenerlo activo.

El cambio convierte un servicio que antes venía incluido en una opción de configuración del administrador. Las implementaciones de Docker se ensamblan a partir de fragmentos, es decir, los componentes de configuración que forman la pila, y Tor ahora reside en un fragmento opcional en lugar de hacerlo en el fragmento principal de BTCPay Server. Tras actualizar, la instrucción para volver a activarlo es: sudo btcpay-fragments add opt-add-tor.

BTCPay afirma que Tor sigue siendo compatible y que los datos existentes permanecen en los volúmenes actuales de Tor, por lo que la información almacenada se conserva. Sin embargo, mantener el acceso onion depende de incluir y ejecutar Tor en la implementación. Se recomienda a los administradores revisar los cambios de la implementación antes de actualizar. También pueden inspeccionar su configuración con btcpay-fragments show, un comando de solo lectura que informa de los fragmentos adicionales y excluidos guardados, junto con los efectivos del último manifiesto generado.

Por qué es importante

Para los comercios y procesadores de pagos que utilizan BTCPay, la configuración predeterminada suele ser la configuración efectiva. Un operador que actualice sin leer las notas de la versión podría perder silenciosamente la dirección onion de la que dependen sus clientes o sus herramientas internas, sin que haya pérdida de datos que permita detectar el problema. El cambio convierte Tor de una opción predeterminada implícita en una decisión de privacidad deliberada.

Impacto en el mercado

La versión 2.4.5 también introduce un cambio incompatible para las solicitudes HTTP salientes: los destinos de redes privadas quedan bloqueados por defecto en las conexiones de Lightning, las solicitudes LNURL, las URL de notificación de facturas y los webhooks. La medida está diseñada para prevenir la falsificación de solicitudes del lado del servidor (SSRF). Los operadores que utilicen servicios privados de forma intencionada deben permitir los destinos necesarios mediante ssrfexceptions, reiniciar la aplicación y probar la integración afectada. Entre la activación opcional de Tor y el refuerzo contra SSRF, los administradores deberían tratar esta actualización como una revisión de configuración, no como un parche rutinario.