Re: [Bitcoin-development] Tor / SPV
Yes correct, using hidden services just as a kind of more complicated, out of process/sandboxable SSL. > would the overall transactions/second the Bitcoin network could handle go > down? > If all nodes talked to each other all the time over Tor, probably yes because Bitcoin is quite sensitive to latency. But what I'm proposing here is less ambitious. It's just about protecting (parts of) end-user-to-network communication, which is a much less risky sort of change. P2P nodes would still talk to each other in the clear. SSL for everything is still an idea I like, but it's true that increasing bitcoind attack surface area is not something to take lightly. Considering that the clearnet sybil protection also relies on scaling > up the resource requirements for an attacker, why not require hidden > service addresses following a certain pattern, like a fixed prefix? I'm sure we can come up with all kinds of neat anti-sybil techniques, but IMHO they are separate projects. I'm trying to find an upgrade that's small enough to be easily switched on by default for lots of users, today, that is low risk for the network overall. Later on we can add elaborations. The SPV node could connect to the IP using Tor. It would preserve the > privacy of the SPV node - hard to see it's running Bitcoin. It also > reduces the ability of an attacker to MITM because the routing varies > with each exit node. Right so the key question is, to what extent does Tor open you up to MITM attacks? I don't have a good feel for this. I read about exit nodes routinely doing very naughty things, but I don't know how widespread that is. Probably you're right that with random selection of exits you're not excessively likely to get MITMd. How does Tor itself manage anti-sybil? I know they have the directory consensus and they measure nodes to ensure they're delivering the resources they claim to have. Punting anti-sybil up to the Tor people and letting them worry about it is quite an attractive idea. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
quote: > > but then you remove the implication that a node has to give both public > > and private IPs to a peer. If it's part of a batch of "addr"s, it could be > > my own hidden service ID, but it could also be one that I learned from > > someone else and is now propagating, for anyone to bootstrap with Tor > > hidden service peers if they'd like. > > > > Hmm. So you mean that we pick a set of peers we believe to not be sybils of > each other, but they might give us hidden services run by other people? I > need to think about that. If they're getting the hidden services just from > addr announcements themselves, then you just punt the issue up a layer - > what stops me generating 1 hidden service keys that all map to my same > malicious node, announcing them, and then waiting for the traffic to > arrive? If clearnet nodes inform of their own hidden service IDs, that > issue is avoided. > Considering that the clearnet sybil protection also relies on scaling up the resource requirements for an attacker, why not require hidden service addresses following a certain pattern, like a fixed prefix? Essentially also a PoW scheme... > My goal here is not necessarily to hide P2P nodes - we still need lots of > clearnet P2P nodes for the forseeable future no matter what. What would you consider as the main merits of clearnet nodes? Best regards, Isidor -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
On Wed, 2014-01-15 at 20:29 -0800, Miron wrote: > On Wed, 2014-01-15 at 23:51 +0100, Mike Hearn wrote: > ... > > 3) SPV wallets that want to get a good mix of nodes for measuring > > pending transactions identify nodes on the clearnet via their addr > > announcements+service flag, in the normal way. They select some of > > these nodes using the standard clearnet anti-sybil heuristics and > > connect without using Tor. They proceed to query them for their hidden > > The SPV node could connect to the IP using Tor. It would preserve the > privacy of the SPV node - hard to see it's running Bitcoin. It also > reduces the ability of an attacker to MITM because the routing varies > with each exit node. > It would also be good to gossip the mapping of (IP -> onion address). This would allow detection of a future MITM, since the MITM can't spoof the onion fingerprint. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
On Wed, 2014-01-15 at 23:51 +0100, Mike Hearn wrote: ... > 3) SPV wallets that want to get a good mix of nodes for measuring > pending transactions identify nodes on the clearnet via their addr > announcements+service flag, in the normal way. They select some of > these nodes using the standard clearnet anti-sybil heuristics and > connect without using Tor. They proceed to query them for their hidden The SPV node could connect to the IP using Tor. It would preserve the privacy of the SPV node - hard to see it's running Bitcoin. It also reduces the ability of an attacker to MITM because the routing varies with each exit node. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
On Wed, 2014-01-15 at 20:26 -0600, Brooks Boyd wrote: > My goal here is not necessarily to hide P2P nodes - we still > need lots of clearnet P2P nodes for the forseeable future no > matter what. Rather we're just using hidden services as a way > to get authentication and encryption. Actually the 6-hop > hidden service circuits are overkill for this application, a > 3-hop circuit would work just as well for most nodes that > aren't Tor-exclusive. > > > ... > communication to Tor doesn't change that. I agree the six-hop circuits > would be overkill for that; I wonder if the network slowdown you get BTW, I believe that the number of hops can be reduced below 3 on both sides (client/server). For Orchid, this will require a change to CircuitPathChooser. For other Tor implementations, it might require using the control port to custom-build a circuit. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
> > My goal here is not necessarily to hide P2P nodes - we still need lots of > clearnet P2P nodes for the forseeable future no matter what. Rather we're > just using hidden services as a way to get authentication and encryption. > Actually the 6-hop hidden service circuits are overkill for this > application, a 3-hop circuit would work just as well for most nodes that > aren't Tor-exclusive. > Ah, I see, so you're intending to use the Tor hidden services not for their original purpose (hiding), but rather as as "authentication" (someone may spoof my clearnet IP, but only I have the private key that makes this Tor hidden service connect to me, so you can trust when you connect to it it's really me). So if you trust the clearnet IP to be a friendly node, that makes a more secure connection, but if you're already talking to a bad node, moving the communication to Tor doesn't change that. I agree the six-hop circuits would be overkill for that; I wonder if the network slowdown you get on Tor will be worth the increased security? Yes, you'll be more protected from MITM, but if this is widely adopted, would the overall transactions/second the Bitcoin network could handle go down? Brooks -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
On Wed, 15 Jan 2014 23:51:21 +0100, Mike Hearn wrote: > The goal of all that is that we get to keep our existing IPv4 based > anti-sybil heuristics, so we can’t possibly make anything worse, > only better. Plus, we’ve now set things up so in future if/when we > come up with a better anti-sybil system based on anonymous identities > or other fancy crypto, we can take out the “connect via clearnet” > step and go straight to using hidden services with only a very small > set of code changes and no new protocol work. I think it might be ok to use proof-of-stake on as an anti-sybil scheme on tor.. people would obviously not want to associate their wallet with their IP address, but is there any harm in associating it with a (temporary) tor service id (especially one that isn't used for anything other than relaying bitcoin transactions)? If each node you connect too can sign some challenge with a key that controls some BTC (and your client node verifies that the funds are different) then that might be useful.. even if it were only a small 0.01BTC stake that would be similar to the cost of obtaining another IP through a cheap VPS or VPN and significantly higher than the cost to an attacker who is able to MITM everything and operate on any IP anyway. Rob -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
> > May need to modify the network address format to include the ability to > differentiate IPv6 clearnet vs. Tor addresses > sipa already implemented some clever hack where the 80-bit Tor keys are mapped to a subregion of reserved IPv6 space, giving magical IPv6 hidden service addresses. So addr packets can and do already contain onion addresses. > but then you remove the implication that a node has to give both public > and private IPs to a peer. If it's part of a batch of "addr"s, it could be > my own hidden service ID, but it could also be one that I learned from > someone else and is now propagating, for anyone to bootstrap with Tor > hidden service peers if they'd like. > Hmm. So you mean that we pick a set of peers we believe to not be sybils of each other, but they might give us hidden services run by other people? I need to think about that. If they're getting the hidden services just from addr announcements themselves, then you just punt the issue up a layer - what stops me generating 1 hidden service keys that all map to my same malicious node, announcing them, and then waiting for the traffic to arrive? If clearnet nodes inform of their own hidden service IDs, that issue is avoided. My goal here is not necessarily to hide P2P nodes - we still need lots of clearnet P2P nodes for the forseeable future no matter what. Rather we're just using hidden services as a way to get authentication and encryption. Actually the 6-hop hidden service circuits are overkill for this application, a 3-hop circuit would work just as well for most nodes that aren't Tor-exclusive. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
> > 2) Secondly, we bump the protocol version, add a service flag and > introduce a new P2P protocol command “tor?”. If a client sends a tor? > message to a node that has the new service flag set, it will respond with a > new “tor” message that contains a regular addr packet, with a single > address, the IPv6-ified version of its hidden service name. > Rather than a separate message type that implies binding a clearnet IP to a hidden service ID, why not add the service flag that the peer would like Tor addresses, and the remote peer can then add IPv6-ified hidden service addresses to "addr" messages? May need to modify the network address format to include the ability to differentiate IPv6 clearnet vs. Tor addresses, but then you remove the implication that a node has to give both public and private IPs to a peer. If it's part of a batch of "addr"s, it could be my own hidden service ID, but it could also be one that I learned from someone else and is now propagating, for anyone to bootstrap with Tor hidden service peers if they'd like. Brooks -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Tor / SPV
intro text starts here, protocol upgrade proposal starts further down Recently on IRC we have discussed what it'd take to use SSL on P2P connections, the goal being encryption and authentication of traffic to help avoid passive wiretapping and sybil attacks. Gregory pointed out - very reasonably - that OpenSSL is huge and very old-school C, meaning that using it to implement SSL would put a big piece of code exposed to the internet into the same process as people’s wallets. This would be not excellent. Also, even with encryption, with SSL you only get some resistance to traffic analysis. And it'd be a complicated upgrade. Tor is an option, but it has other disadvantages: 1) Also a giant piece of C that is likely to contain bugs 2) Breaks our anti-sybil heuristics when connecting to hidden services 3) MITM very likely when not connecting to hidden services 4) Is not usable as a library at all. Convention to use Tor is "tell user to start TorBrowser and connect to the SOCKS port". The latter point means in reality hardly anyone will ever connect via Tor, as you'd have to do extra setup and most people are lazy. Especially it's not going to work on mobile. It’s not worth doing something complicated if hardly anyone would use it. But recently I discovered this interesting piece of code: http://www.subgraph.com/orchid.html It is a pure Java implementation of the Tor protocol (client only, no relays), easily usable as a library. Sure enough after about an hour of fiddling around, I now have a bitcoinj that connects via Tor with no other software running. Suddenly making MultiBit, the Android Bitcoin Wallet app, Hive and other bitcoinj based wallets use Tor by default seems very plausible. So I started thinking about what it'd take to switch this on for everyone. The biggest problem is that SPV wallets can't verify unconfirmed/pending transactions for themselves, so they rely on counting the number of peers that announced it and assuming that their internet connections aren't being tampered with. Mostly this assumption is a good one - we have never heard anyone report that they were paid with a fake pending tx using a MITM attack. However, with Tor the chance of being MITMd goes up dramatically. Lots of people have reported exit nodes that are doing SSL stripping. Being sybilled when using exit nodes seems rather likely. Connecting to hidden services solve the MITM problem but screws you in a different way. Bitcoin Core has some weak heuristics in the code to try and ensure we don’t accidentally connect to nodes all controlled by the same guys … mostly by trying to keep a good mix of /16s. This is probably not very hard to defeat, but it does at least raise the bar beyond “buy lots of amazon VMs”. With hidden services we lose that. Also, there aren’t very many nodes running as hidden services - if all bitcoinjs started hitting them simultaneously they’d probably die. tl;dr the proposal starts here Let’s fix this so SPV wallets can use Tor by default. Downgrading things is not an option, it must be pure upgrade. We can do it like this: 1) Firstly, we observe that MITM only matters when we’re trying to count pending transaction announcements, but most of the load SPV wallets impose on the network is chain filtering. So it’s OK to download the chain from any arbitrary clearnet IP via Tor because we’re checking Merkle branches. This ensures we won’t put excessive load on hidden service nodes. 2) Secondly, we bump the protocol version, add a service flag and introduce a new P2P protocol command “tor?”. If a client sends a tor? message to a node that has the new service flag set, it will respond with a new “tor” message that contains a regular addr packet, with a single address, the IPv6-ified version of its hidden service name. 3) SPV wallets that want to get a good mix of nodes for measuring pending transactions identify nodes on the clearnet via their addr announcements+service flag, in the normal way. They select some of these nodes using the standard clearnet anti-sybil heuristics and connect without using Tor. They proceed to query them for their hidden service key. After they’ve done that, they record the public IP->hidden service mapping and can go ahead and connect back to them at any later time via Tor itself. This would seem to be pointless - did we not just go ahead and bypass Tor entirely, thus making neither node hidden? Is it not a dead cert that the next connection the node gets via Tor is likely the same computer? Yes, but it only matters the first time. As long as those nodes are somewhat stable the mapping will be recorded on disk and the next time the wallet starts, it’ll skip straight to using Tor. The goal of all that is that we get to keep our existing IPv4 based anti-sybil heuristics, so we can’t possibly make anything worse, only better. Plus, we’ve now set things up so in future if/when we come up with a better anti-sybil
