Bitcoin Core 31.0 : une diffusion privée pourrait révéler l'adresse IP de l'expéditeur

Un bug qui peut exposer l’adresse IP

Le problème touche les utilisateurs de Bitcoin Core 31.0 lorsque -privatebroadcast est activé, que les transactions sont diffusées via le RPC sendrawtransaction, que Tor est joignable pour les connexions sortantes, que des connexions IPv4 ou IPv6 sortantes peuvent être établies directement, et que BIP324 v2 transport n’est pas désactivé avec -v2transport=0.

Selon la notice publiée par Bitcoin Core, quand private broadcast choisit un pair IPv4 ou IPv6 qui annonce la prise en charge de v2, la connexion initiale passe bien par le proxy Tor. Mais si l’échange initial en v2 échoue, le logiciel retente en v1. Cette nouvelle tentative ne passe alors plus par Tor et se connecte directement au pair via IPv4 ou IPv6, ce qui expose l’adresse IP de l’émetteur au destinataire.

Les connexions v1 initiales, vers des pairs qui n’annoncent pas v2, ne sont pas concernées : elles sont, elles aussi, correctement routées via Tor. Le bug est limité à la reconnexion v1 qui suit un échec de poignée de main v2. Les connexions vers les pairs .onion et I2P ne sont pas affectées, car elles restent routées par leurs proxys respectifs lors d’une reconnexion v1.

Les utilisateurs concernés et la parade

Bitcoin Core précise que cet incident contredit la promesse figurant dans les notes de version 31.0 : « Their IP address (and thus geolocation) is never known to the recipients ».

L’équipe indique aussi qu’un échange v2 a peu de chances d’échouer avec un pair qui prend réellement en charge ce transport. En revanche, le bug peut être déclenché plus facilement par un pair malveillant qui ferme volontairement la poignée de main v2 afin de forcer une reconnexion en v1.

En attendant la version 31.1, Bitcoin Core recommande trois solutions de contournement aux utilisateurs de -privatebroadcast. La première consiste à désactiver la fonctionnalité avec -privatebroadcast=0. La deuxième est de couper le transport v2 avec -v2transport=0, ce qui fait passer toutes les connexions du nœud par le protocole v1 non chiffré.

La troisième option consiste à faire passer le trafic IPv4/IPv6 sortant par Tor avec -proxy=127.0.0.1:9050, en remplaçant 9050 par le port SOCKS de Tor si besoin. Bitcoin Core avertit toutefois que cette configuration rend le nœud plus facile à attaquer par Sybil.

Le crédit de la découverte du bug revient à Eugene Siegel.