[bitcoin-dev] Bitcoin XTs Tor IP blacklist downloading system has significant privacy leaks.

[F L via bitcoin-dev]

Bitcoin XT contains an unmentioned addition which periodically downloads
lists of Tor IP addresses for blacklisting, this has considerable privacy
implications for hapless users which are being prompted to use the
software. The feature is not clearly described, is enabled by default,
and has a switch name which intentionally downplays what it is doing
(disableipprio). Furthermore these claimed anti-DoS measures are
trivially bypassed and so offer absolutely no protection whatsoever.

Connections are made over clearnet even when using a proxy or
onlynet=tor, which leaks connections on the P2P network with the real
location of the node. Knowledge of this traffic along with uptime metrics
from bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will
cause them to make a new request to the blacklist endpoint via the
clearnet on relaunch at the same time their P2P connections are made
through a proxy. Requests to the blacklisting URL also use a custom
Bitcoin XT user agent which makes users distinct from other internet
traffic if you have access to the endpoints logs.


https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

[Andrew LeCody via bitcoin-dev]

This should probably be posted on the BitcoinXT mailing-list, as Bitcoin
Core does not currently include this feature.

On Tue, Aug 18, 2015 at 6:36 PM F L via bitcoin-dev <

Post by F L via bitcoin-dev
Bitcoin XT contains an unmentioned addition which periodically downloads
lists of Tor IP addresses for blacklisting, this has considerable privacy
implications for hapless users which are being prompted to use the
software. The feature is not clearly described, is enabled by default, and
has a switch name which intentionally downplays what it is doing
(disableipprio). Furthermore these claimed anti-DoS measures are trivially
bypassed and so offer absolutely no protection whatsoever.
Connections are made over clearnet even when using a proxy or onlynet=tor,
which leaks connections on the P2P network with the real location of the
node. Knowledge of this traffic along with uptime metrics from
bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will cause
them to make a new request to the blacklist endpoint via the clearnet on
relaunch at the same time their P2P connections are made through a proxy.
Requests to the blacklisting URL also use a custom Bitcoin XT user agent
which makes users distinct from other internet traffic if you have access
to the endpoints logs.
https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Patrick Strateman via bitcoin-dev]

First of all I would like to say... LOL

Second Andrew LeCody is correct, this is off topic.

Post by F L via bitcoin-dev
Bitcoin XT contains an unmentioned addition which periodically
downloads lists of Tor IP addresses for blacklisting, this has
considerable privacy implications for hapless users which are being
prompted to use the software. The feature is not clearly described,
is enabled by default, and has a switch name which intentionally
downplays what it is doing (disableipprio). Furthermore these claimed
anti-DoS measures are trivially bypassed and so offer absolutely no
protection whatsoever.
Connections are made over clearnet even when using a proxy or
onlynet=tor, which leaks connections on the P2P network with the real
location of the node. Knowledge of this traffic along with uptime
metrics from bitnodes.io can allow observers to easily correlate the
location and identity of persons running Bitcoin nodes. Denial of
service can also be used to crash and force a restart of an
interesting node, which will cause them to make a new request to the
blacklist endpoint via the clearnet on relaunch at the same time their
P2P connections are made through a proxy. Requests to the
blacklisting URL also use a custom Bitcoin XT user agent which makes
users distinct from other internet traffic if you have access to the
endpoints logs.
https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Christophe Biocca via bitcoin-dev]

So I checked, and the code described *does not* run when behind a
proxy of any kind, including tor:

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23#diff-11780fa178b655146cb414161c635219R265

At least based on my admittedly weak understanding of how the internal works.

Hopefully I save the next reader of your post from also having to dig
around to find the code and realize this is a false alert.

On Tue, Aug 18, 2015 at 6:36 PM F L via bitcoin-dev <

Post by F L via bitcoin-dev
Bitcoin XT contains an unmentioned addition which periodically downloads
lists of Tor IP addresses for blacklisting, this has considerable privacy
implications for hapless users which are being prompted to use the
software. The feature is not clearly described, is enabled by default, and
has a switch name which intentionally downplays what it is doing
(disableipprio). Furthermore these claimed anti-DoS measures are trivially
bypassed and so offer absolutely no protection whatsoever.
Connections are made over clearnet even when using a proxy or onlynet=tor,
which leaks connections on the P2P network with the real location of the
node. Knowledge of this traffic along with uptime metrics from
bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will cause
them to make a new request to the blacklist endpoint via the clearnet on
relaunch at the same time their P2P connections are made through a proxy.
Requests to the blacklisting URL also use a custom Bitcoin XT user agent
which makes users distinct from other internet traffic if you have access
to the endpoints logs.
https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Christophe Biocca via bitcoin-dev
So I checked, and the code described *does not* run when behind a
https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23#diff-11780fa178b655146cb414161c635219R265
At least based on my admittedly weak understanding of how the internal works.
Hopefully I save the next reader of your post from also having to dig
around to find the code and realize this is a false alert.

That's not entirely correct.

The code does disable downloading of the Tor exit node list if fListen

Post by Christophe Biocca via bitcoin-dev
Connections are made over clearnet even when using a proxy or
onlynet=tor,

is false. However, in the common scenario of a firewalled node, where
the operator has neglected to explicitly set -listen=0, the code does
still download the Tor exit node list, revealing the true location of
the node. This is contrary to the previous behavior of not revealing any
IP information in that configuration.

FWIW Gregory Maxwell removed the last "call home" feature in pull-req
#5161, by replacing the previous calls to getmyip.com-type services with
a local peer request. Similarly the DNS seeds use the DNS protocol
specifically to avoid leaking IP address information.

tl;dr: Yes, Bitcoin XT has a privacy problem with the automatic Tor exit
node list download.

Post by Christophe Biocca via bitcoin-dev
On Tue, Aug 18, 2015 at 6:36 PM F L via bitcoin-dev <

Post by F L via bitcoin-dev
Bitcoin XT contains an unmentioned addition which periodically downloads
lists of Tor IP addresses for blacklisting, this has considerable privacy
implications for hapless users which are being prompted to use the
software. The feature is not clearly described, is enabled by default, and
has a switch name which intentionally downplays what it is doing
(disableipprio). Furthermore these claimed anti-DoS measures are trivially
bypassed and so offer absolutely no protection whatsoever.
Connections are made over clearnet even when using a proxy or onlynet=tor,
which leaks connections on the P2P network with the real location of the
node. Knowledge of this traffic along with uptime metrics from
bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will cause
them to make a new request to the blacklist endpoint via the clearnet on
relaunch at the same time their P2P connections are made through a proxy.
Requests to the blacklisting URL also use a custom Bitcoin XT user agent
which makes users distinct from other internet traffic if you have access
to the endpoints logs.
https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gregory Maxwell via bitcoin-dev]

On Wed, Aug 19, 2015 at 1:36 AM, Peter Todd via bitcoin-dev

Post by Peter Todd via bitcoin-dev
tl;dr: Yes, Bitcoin XT has a privacy problem with the automatic Tor exit
node list download.

It's not a bug, it's a feature: These concerns and others were
specifically called out when we rejected this submission to Bitcoin
Core in favor of a more generic approach that lacks the privacy
problems and avoids being explicitly punitave to the use of Tor.

At least it's not a full on block as soon a the node fills for the
first time like the first implementation.

[Peter Todd via bitcoin-dev]

Post by Peter Todd via bitcoin-dev
is false. However, in the common scenario of a firewalled node, where
the operator has neglected to explicitly set -listen=0, the code does
still download the Tor exit node list, revealing the true location of
the node. This is contrary to the previous behavior of not revealing any
IP information in that configuration.
FWIW Gregory Maxwell removed the last "call home" feature in pull-req
#5161, by replacing the previous calls to getmyip.com-type services with
a local peer request. Similarly the DNS seeds use the DNS protocol
specifically to avoid leaking IP address information.
tl;dr: Yes, Bitcoin XT has a privacy problem with the automatic Tor exit
node list download.

Oh, and I just checked, and Mike's original pull-req for the Tor
blacklist didn't include the proxy disable code; what's in master != the
pull-req, so the OP may have been looking at the wrong code by accident.
(I personally noticed this issue in the pull-req and didn't realise it
hadn't been merged into master w/o modifications)

https://github.com/mikehearn/bitcoinxt/commit/931a4d59a03c7e64d7d85ddfc07ae127533c7f28#diff-11780fa178b655146cb414161c635219R171

Kinda sloppy of Mike to be making changes in master that don't
correspond to the peer-reviewed pull-req code...

[Mike Hearn via bitcoin-dev]

The code was peer reviewed, in the XT project. I didn't bother submitting
other revisions to Core, obviously, as it was already rejected.

The quantity of incorrect statements in this thread is quite ridiculous.

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 4:45 PM, Mike Hearn via bitcoin-dev

Post by Mike Hearn via bitcoin-dev
The code was peer reviewed, in the XT project. I didn't bother submitting
other revisions to Core, obviously, as it was already rejected.
The quantity of incorrect statements in this thread is quite ridiculous.

Would you kindly link to said peer review as I was unable to find it
other than a couple of comments between you and Gavin which hardly
amounts to peer review.