ensure ADD_ONION implementation is compatible with upstream changes, next generation onion addresses

gits7r commented at 0:25 am on November 24, 2016: none

Very soon Tor will implement proposal 224, also known as next generation onion services.

This means the addresses will be bigger, whole keys (ed25519) base 32 encoded and with .onion at the end. Example: a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion

This means ADD_ONION:BEST will produce a new key (best which is ed25519) rather than RSA1024.

Bitcoin Core should fully support the new address types, or change torcontrol.cpp#L473 from ADD_ONION:BEST to ADD_ONION:RSA1024 . The 2 address types (RSA1024 and ed25519) will work simultaneously for a transition period, which means Bitcoin Core also has to support both to ensure working configurations do not break.

This affects new setups, nodes that previously generated a RSA1024 key and upgrade Tor should be able to preserve that key based on current code.

fanquake added the label Upstream on Nov 24, 2016

jonasschnelli added the label P2P on Nov 24, 2016

gmaxwell commented at 10:52 pm on November 24, 2016: contributor

Thanks for the update. This will require a fairly extensive P2P protocol rework for us for full support (as we’re limited to 128 bit ‘addresses’ at the p2p level.); but we could still support the new style HSes without rumoring.

While we’re discussing this, is there any good way that we could determine which HS a given localhost connection was coming from? We could use that for certain kinds of anti-DOS mechanisms.

sipa commented at 2:02 am on November 26, 2016: member

I believe we should in the short term switch to issuing ADD_ONION:RSA1024, and prioritize proposing an upgrade to the P2P protocol to murmur larger network addresses.

gits7r commented at 1:58 pm on November 27, 2016: none

@gmaxwell np. I also think the P2P protocol should have full support for ‘addresses’ > 128 bit, since maybe we will need support for other network types and as we can see sometimes whole keys are used as ‘addresses’. @sipa if we will do things in this order, we need to change:

torcontrol.cpp#L473 from private_key = "NEW:BEST"; to private_key = "NEW:RSA1024";

This should be a backport, because it applies to all releases using ADD_ONION Tor controller feature. I think this is not ideal and it’s better fixing the p2p limitation, because sooner rather than later RSA1024 onion services will be no longer be supported in the Tor network, and we will need to again switch to private_key = "NEW:BEST";. or AT LEAST private_key = "NEW:ED25519";

BEST = the latest HS version, currently v2 with RSA1024/SHA1. In the next major stable release it will be v3 with ed25519 keys . So BEST is kind of dynamic from this point of view. Each particular HS version can be mentioned with NEW:RSA1024 or NEW:ED25519 (when v4 will come along - no plans for this, probably very far in the future). The problem is that older deprecated versions are not to be supported forever in the network or even as a controller command, which is why I strongly think it’s better to fix our p2p ‘addresses’ limitation and remove Bitcoin Core’s worry from what Tor considers and uses as BEST for HS with the additional benefit of supporting any other network with big address format if needed.

As for your question @gmaxwell at this moment Tor doesn’t have a feature to tag circuits based on .onion addresses. So, for a local node being reachable on .onion the peers connecting will always appear to be “addr”: “127.0.0.1:” connected to “addrlocal”: “hostname.onion:8333” . So, the only different element for multiple connected peers is their port, but this is no reliable element to make a DoS assumption because of obvious reasons (a different honest peer might later have the same port or a malicious peer rebuilds the rendezvous circuit and gets a different port). For these reasons we also can’t map remote peers to unique addresses in the 127.0.0 class. There is no concept of remote peer HS address from Tor’s perspective. The remote peer can be a client-only, it may not even run a HS at all and still connect to other HSes just fine by establishing rendezvous circuits.

If you think about it other way around, a server running more HSes simultaneously should use a different virtualport for each one, so that at least it can bucket clients (or remote peers in our context) groups to a given onion hostname (but still with no way to distinguish deeper clients from each other within the buckets). This is not too great as well, the best bet here is to run one HS per Tor instance.

laanwj referenced this in commit 6da581064f on Nov 28, 2016

laanwj commented at 4:17 pm on November 28, 2016: member

Thanks for the heads-up. Switched to RSA1024 keys explicitly in #9234.

laanwj referenced this in commit 7d3b627395 on Nov 28, 2016

laanwj referenced this in commit 94531b5350 on Nov 30, 2016

MarcoFalke referenced this in commit 82e29e8b7c on Nov 30, 2016

UdjinM6 referenced this in commit 7c426cd3b6 on Mar 22, 2017

UdjinM6 referenced this in commit 01a3477547 on Mar 22, 2017

str4d commented at 7:11 am on March 24, 2017: contributor

Cross-linking to https://github.com/zcash/zcash/issues/1111 as the P2P changes for Tor’s HS2.0 are also necessary for I2P support.

str4d commented at 1:03 pm on April 1, 2017: contributor

While we’re discussing this, is there any good way that we could determine which HS a given localhost connection was coming from? We could use that for certain kinds of anti-DOS mechanisms.

FWIW this is trivially accessible in I2P, so it would be worth considering in the end design even if it is hard or impossible to implement for Tor.

laanwj commented at 9:30 am on April 2, 2017: member

While we’re discussing this, is there any good way that we could determine which HS a given localhost connection was coming from? We could use that for certain kinds of anti-DOS mechanisms.

No, because in Tor, connections never come from hidden services. Hidden services are only used to find an endpoint, they are not a general identifier for endpoints. A connection coming in to a hidden service carries no metadata that can be used to persistently identify the other side (this is a privacy feature, not a bug).

It is possible to work around this by using a more extensive negotiation process. For example Ricochet and Torchat do this. A naive way (used by Torchat IIRC) is to connect to each other’s hidden service and pass tokens back and forth to prove to each other to ‘own’ the respective hidden service. Another way (slightly more efficient, used by Ricochet) is to make the connecting side sign a token with their hidden service private key.

This in itself is not useful for anti-DoS protection as generating hidden service keys is cheap. It’d have to be combined with some PoW mechanism on first connect from a new service.

UdjinM6 referenced this in commit ff30aed68f on Apr 11, 2017

thokon00 referenced this in commit 05d2057e7d on Apr 17, 2018

leto commented at 11:03 pm on February 3, 2020: contributor

If somebody wanted to work on this, are there any suggestions for how to support new HSv3 Tor services? Last comments are almost 3 years old, so I figure some things have changed

sipa commented at 11:06 pm on February 3, 2020: member

Unfortunately this needs a protocol change first, because the existing P2P system has no way to relay such addresses (it has a flat 128-bit namespace for all IP addresses; we basically inject onion addresses into that space by special casing a particular range). See BIP 155 (https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki) for a proposal that does this.

leto commented at 11:23 pm on February 3, 2020: contributor

@sipa I see that it says “a reference implementation is at …”, is the next step to write a reference implementation of BIP155? It seems that this is not a consensus change, and we could start teaching nodes about this new addrv2 message type and they could still connect to older nodes correctly by using GOSSIP_ADDRV2_VERSION. I would be interested to be mentored by a dev that is more familiar with the p2p layer if that is interesting to anybody. I am pretty familiar with internals but I have never made large modifications to the p2p layer.

There seems to be new active attacks against v3 HS’s described here: https://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html and supposedly those have many new mitigations compared to the older v2 HS’s that Bitcoin only supports currently. It seems important for Bitcoin Core to support HSv3 for user privacy.

gits7r commented at 10:32 pm on February 4, 2020: none

@leto this is off topic in this ticket so I’ll be very short - the article sounds more scary than it actually is, it’s not a deanonymization, it is a guard discovery attack, one that has been known and researched for many years (that is why entry guards were implemented in the first place). And it is unrelated if the hidden service is version 2 or version 3. It only has to do with the fact that a hop (a server in a Tor circuit) is always selected by the client/visitor which can always be the attacker. So, it’s true that this ticket must get some priority at some point, but the article linked is not directly related to this ticket.

Hopefully we can work on the protocol change soon and implement v3 addresses as well, because they offer so many improvements.

vasild commented at 10:54 am on September 14, 2020: member

This can be closed as fixed by #9234.

gits7r commented at 5:20 pm on September 14, 2020: none

@vasild NEGATIVE.

This can be only closed as fixed as soon as #18884 is 100% complete. This ticket needs the P2P protocol upgrade, to support larger addresses. In #9234 we only made sure our ADD_ONION automated feature will still work and remain compatible with newer Tor versions without breaking onion land nodes, otherwise we would be requesting a key type that is not supported in our P2P protocol.

vasild commented at 12:10 pm on October 12, 2020: member

#19954 is now merged

MarcoFalke closed this on Oct 12, 2020

DrahtBot locked this on Feb 15, 2022

ensure ADD_ONION implementation is compatible with upstream changes, next generation onion addresses #9214