Tor: Difference between revisions
NotATether (talk | contribs) Migrate contents from https://github.com/bitcoin/bitcoin/pull/25927/ |
|||
| Line 36: | Line 36: | ||
bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node. | bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node. | ||
== Security considerations == | |||
Using CJDNS, I2P, or Tor alone without other networks may make a node more susceptible to [[Weaknesses#Sybil_attack|Sybil attacks]]. You can use `bitcoin-cli -addrinfo` to see the number and type of addresses known to your node. | |||
If all of your connections are controlled by a Sybil attacker, they can easily prevent you from seeing confirmed transactions and, with more difficulty, even trick your node into falsely reporting a transaction as confirmed on the blockchain. | |||
This is significantly less of a concern if you make `-addnode` connections to trusted peers (even if they're CJDNS, I2P, or Onion addresses). | |||
It's also alleviated with IPv4/IPv6 connections (especially when using the `-asmap` configuration option) due to the cost of obtaining IPs in many networks. | |||
A connection to a single honest peer is enough to thwart an attempted eclipse attack. | |||
== Network Partitioning == | |||
If too many of the single network nodes use onlynet=[network], it could become difficult for the nodes to communicate with the rest of the entire Bitcoin network, increasing the chance of network partitioning. It is essential that some nodes access a combination of networks. | |||
=Hidden services= | =Hidden services= | ||
Revision as of 05:49, 26 August 2022
Tor is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran. Bitcoin's security model assumes that your node is well connected to the rest of the network, so even in less-censored countries using bitcoin over both Tor and clearnet can avoid being partitioned from the network by the internet service provider. Preserving privacy means not only hiding the content of messages, but also hiding who is talking to whom (traffic analysis). Tor provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis.
Bitcoin can run easily on the Tor network.
Tor installation & use
todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers
Please follow the instructions provided with installation files and read the list of warnings. Tor doesn't magically anonymize all your traffic just because you install it.
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic.
This is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in.
On the taskbar of your compute you'll see a small green onion when Tor is running.
Note on 2022: This project that executes Tor service on Windows with the above interface, and display an icon on the taskbar is called Tor Vidalia Bundle and it's not maintained anymore, deprecated and not recommended. To see how to configure Tor service on Linx or Windows check Setting up a Tor hidden service.
Bitcoin Core
See Setting up a Tor hidden service, see also Bitcoin Core instructions for Tor.
GUI
Once you have your Tor client up & running, you can configure your Bitcoin client to use it.
Select in menu Settings -> Options
Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number)
Configuring an application to use Tor is also called to torify it.
(needs a brief howto here)
the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC Conducting business using bitcoin-otc can be done more anonymously when directly connected to a Freenode IRC hidden service.
bitcoind
Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).
bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node.
Security considerations
Using CJDNS, I2P, or Tor alone without other networks may make a node more susceptible to Sybil attacks. You can use `bitcoin-cli -addrinfo` to see the number and type of addresses known to your node.
If all of your connections are controlled by a Sybil attacker, they can easily prevent you from seeing confirmed transactions and, with more difficulty, even trick your node into falsely reporting a transaction as confirmed on the blockchain.
This is significantly less of a concern if you make `-addnode` connections to trusted peers (even if they're CJDNS, I2P, or Onion addresses). It's also alleviated with IPv4/IPv6 connections (especially when using the `-asmap` configuration option) due to the cost of obtaining IPs in many networks. A connection to a single honest peer is enough to thwart an attempted eclipse attack.
Network Partitioning
If too many of the single network nodes use onlynet=[network], it could become difficult for the nodes to communicate with the rest of the entire Bitcoin network, increasing the chance of network partitioning. It is essential that some nodes access a combination of networks.
Hidden services
Hidden services run within the Tor network and can be connected to using the -connect= parameter to bitcoind so long as bitcoin is configured to use a Tor proxy. Bitcoin users do not need to use hidden services, since Tor can be used to increase anonymity of normal internet traffic, including bitcoin connections, but there are some technical reasons why hidden services may be beneficial; for more information see the Tor project's documentation.
Services are listed at Fallback_Nodes#Tor_network along with instructions for using them.
Pooled Mining
Some mining pools are available as a hidden service on the tor network. Any pool can be reached over tor. The general methodology here is to tell your mining client to use your local Tor proxy. This is client specific but there are some helpful hints.
Linux / BSD
Any client can have its traffic routed via Tor by using the torify command and invoking the miner with that. Another method is to set the http_proxy environment variable as some miners use libraries which support that.
Windows / OS X
It is possible to set the http_proxy environment variable as some miners use libraries which support that.
mIRC
mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC.
Register your nick with freenode nickserv
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname.
Connect to Freenode IRC without using tor & execute
/msg nickserv register <password> <email>
You will see something like this
-NickServ- An email containing nickname activation instructions has been sent to <email>
-NickServ- If you do not complete registration within one day, your nickname will expire.
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc.
Add SASL support to your mIRC installation
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit").
Type /dialog -m SASL.main SASL.main to open the SASL connection manager.
Add Freenode entry.
Network is Freenode.
Username and NS Password must match your nickserv reservation.
Auth Type can be PLAIN
setup mIRC to use Tor
Add the entry for Freenode onion IRC server
Configure mIRC to use a Proxy (your local Tor proxy)
Now you should be able to connect.
Bitcoin forum where this topic is discussed
How Tor works
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.
Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple layers of encryption that are pulled away for each node. Hence the name The Onion Router, which is always capitalized as Tor, and never TOR or t.o.r.
Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:
Send to this IP: <IP of Relay1> <Encrypted data for Relay1>
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:
Send to this Tor node: <Relay2> <Encrypted data for Relay2>
Relay2 decrypts his payload:
Send to this Tor node: <Relay3> <Encrypted data for Relay3>
Relay3 receives the real TCP payload, which he sends to the destination:
Send to this IP: <IP of destination> <Unencrypted payload>
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the exit node) can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!
The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.
However, Tor is weak to a timing attack that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.
Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):
- S-ISP & Relay3
- Relay1 & Relay3
- S-ISP & D-ISP
- Relay1 & D-ISP
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)
Because the first relay (the entry node) is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three entry guards that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.
These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an EWallet instead of the Bitcoin client when using Tor.
To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a network status consensus document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many directory mirrors, which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.
Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:
- The destination tells several Tor relays to act as introduction points for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.
- The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.
- The sender creates a four-node Tor circuit. The fourth node is called the rendezvous point.
- The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.
- The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.
For clients, hidden services are more secure than encrypted Tor HTTPS connections because:
- If the destination remains anonymous, they are less likely to become controlled by an evil party.
- The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:
- S-ISP & Destination
- Relay1 & Destination
Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:
- Your Internet service is cut off.
- If the hidden service went down at that exact moment, you are unmasked.
The same sort of timing attacks as above are also possible.
See the Tor design paper for more info.
Exchange Restrictions
Some exchanges will treat activity occurring through Tor with greater precautions. For instance, the now-defunct Mt. Gox signup sheet read:
- Please be advised that accessing your account via the Tor network and/or public proxies may result in a temporary suspension of your account, and having to submit AML documents.