BTCPay rend Tor optionnel sous Docker dans sa version 2.4.5

BTCPay Server a retiré Tor des composants automatiquement inclus dans son déploiement Docker standard à partir de la version 2.4.5, annoncée le 5 octobre et publiée sur GitHub le 6 octobre. Les opérateurs qui dépendent de l’accès onion, notamment de l’adresse onion de leur serveur, doivent désormais sélectionner explicitement Tor lors de leur prochaine installation ou mise à jour pour le maintenir en fonctionnement.

Cette évolution transforme un service auparavant inclus par défaut en option de configuration pour l’administrateur. Les déploiements Docker sont assemblés à partir de fragments, c’est-à-dire les composants de configuration qui constituent la pile, et Tor se trouve désormais dans un fragment optionnel plutôt que dans le fragment central de BTCPay Server. Après la mise à jour, il faut exécuter la commande suivante pour le réactiver : sudo btcpay-fragments add opt-add-tor.

BTCPay indique que Tor reste pris en charge et que les données existantes demeurent dans les volumes Tor actuels, ce qui préserve les données stockées. Le maintien de l’accès onion dépend toutefois de l’inclusion et de l’exécution de Tor dans le déploiement. Les administrateurs sont invités à examiner les changements apportés au déploiement avant la mise à jour. Ils peuvent vérifier leur configuration avec btcpay-fragments show, une commande en lecture seule qui répertorie les fragments supplémentaires et exclus enregistrés, ainsi que ceux effectivement utilisés dans le dernier manifeste généré.

Pourquoi c’est important

Pour les commerçants et les processeurs de paiements qui utilisent BTCPay, la configuration par défaut est souvent la configuration effectivement utilisée. Un opérateur qui effectue une mise à jour sans lire les notes de version pourrait perdre discrètement l’adresse onion dont dépendent des clients ou des outils internes, sans perte de données qui signalerait le problème. Cette évolution fait passer Tor d’une option implicite par défaut à une décision délibérée en matière de confidentialité.

Impact sur le marché

La version 2.4.5 introduit également une modification incompatible pour les requêtes HTTP sortantes : les destinations sur des réseaux privés sont bloquées par défaut pour les connexions Lightning, les requêtes LNURL, les URL de notification de facture et les webhooks. Cette mesure vise à prévenir la falsification de requêtes côté serveur (SSRF). Les opérateurs qui utilisent volontairement des services privés doivent autoriser les destinations nécessaires via ssrfexceptions, puis redémarrer l’application et tester l’intégration concernée. Entre l’activation facultative de Tor et le renforcement contre les SSRF, les administrateurs devraient considérer cette mise à jour comme une révision de configuration, et non comme un correctif de routine.