Tor ephemeral hidden service rejuvenation

Willtech commented at 8:20 pm on November 15, 2019: contributor

Is your feature request related to a problem? Please describe. N/A #Privacy

Describe the solution you’d like The security of the solution provided by integration with Tor is able to be improved by allowing rejuvenation of the ephemeral hidden service. This allows that a new ephemeral hidden service can be created, or, that the hidden service is ‘once only’, it pops into existence, exists for a while and then disappears.

Provide a gui checkbox, configuration item and command-line switch for Regenerate Ephemeral Service. In reality, when set, each time the Bitcoin Core client starts it first removes then generates new ~/bitcoin/onion_private_key

It is also possible to add a gui button that deletes the key next startup by flag whereas the configuration item and command-line switch operate as described and delete the file every startup.

Describe alternatives you’ve considered As an alternative, a launch script could be used to remove ~/bitcoin/onion_private_key before lauching Bitcoin Core

Additional context There is limited opportunity, however, for the serious about maximum privacy having the re-use of the ephemeral service allows the tracing third-party node to wait to reconnect and gather direct intelligence what transactions and blocks the node gossips. With this feature, there is no reuse.

Willtech added the label Feature on Nov 15, 2019

Willtech renamed this:
~~Ephemeral Hiiden Service Rejuvenation~~
Ephemeral Hiden Service Rejuvenation [Tor]
on Nov 15, 2019

fanquake added the label P2P on Nov 15, 2019

JeremyCrookshank commented at 10:20 pm on November 15, 2019: contributor

Concept ACK. If general consensus is positive I’d like to create this.

laanwj commented at 8:55 am on November 18, 2019: member

General concept ACK. More user control over the automatic Tor hidden service would be useful.

Say, a button to generate a new hidden service.

Though, specifically, I’m interested in why you’d want to create a new hidden service every launch. The gossip process is slow, and it will take ages for other peers to find you and connect to you again. By that time you’ve already moved on. How I see it, you might as well just disable incoming connections.

laanwj renamed this:
~~Ephemeral Hiden Service Rejuvenation [Tor]~~
Tor ephemeral hidden service rejuvenation
on Nov 18, 2019

Willtech commented at 10:54 pm on December 1, 2019: contributor

In support of the feature, once your ephemeral service is discovered once it can be added to a peer’s .conf as an addnode= line which we should expect allows for the node to be connected to again fairly easily when it comes online, and so a tick box to allow creation of a new ephemeral hidden service is requested, along with an on-demand create new ephemeral hidden service button. This does not disable incoming connections but only prevents tracking of gossiping across multiple sessions.

ghost commented at 9:43 pm on September 17, 2020: none

Concept ACK

#19635 (comment)

gmaxwell commented at 12:44 pm on October 1, 2020: contributor

Having a button would be harmless, I suppose, except for the additional review, testing, and potential for user confusion. But from the above it sounds to me that the motivation for this sort of thing is largely misguided.

Having a per-session HS would be pointless– it would get no or essentially no connections, and it would waste network resources rumoring useless addresses and attempting to connect to them. It is also unnecessary: Bitcoin works perfectly fine over tor without creating any HS or accepting incoming connections– and this is generally the most private way to use it.

Bitcoin also does not do a particularly complete job of preventing a given host from being tracked across different identities– e.g. the content of your addrman database will usually uniquely identify you (particularly if an attacker does some work to tag your state), similarly the mempool can be abused in this manner too using slow to confirm transactions. The swapping from one identity to another would also create a temporal signal (X stops, Y starts at the same time) which could be used to trace the user.

Having short lived pseudonymous identities is with some respect the worse of all worlds– not getting additional inbound connectivity, not providing a useful service to the network, wasting rumour/connect resources, and still leaking information that could be used by an attacker to continually stay connected to a particular target.

For different protocols where inbound connections are important the considerations might be entirely different.

Edit: After some reflection I guessed that maybe people are trying to imitate the new-identity button in torbrowser. If so: bitcoin already makes every single connection with new circuits, so nothing is needed there.

Willtech commented at 11:04 am on October 5, 2020: contributor

Let’s keep it simple. A setting to create a new ephemeral session each restart of Bitcoin Core (bitcoin-gui/bitcoind) and a button to do so immediately.

Having a per-session HS would be pointless

Per Bitcoin Core run session is certainly not pointless, in fact very much the thing this calls for.

X stops, Y starts at the same time) which could be used to trace the user.

It is certainly not necessary to close off the old ephemeral session, it can simply time out as far as Tor network is concerned.

ghost commented at 7:37 pm on October 5, 2020: none

When was the first time I thought about having such option and where did I read about it?

Also, if you delete this file, the next time bitcoind loads it will generate a new key file and xxxxxxxx.onion address. Note that while a malicious party cannot necessarily associate the server with you as a person, as long as your server has the same xxxx.onion address they will know it is run by the same person. For absolute security delete onion_private_key at each reboot or some frequent interval.

https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service

Why do I think we need to automate renewal of onion address?

Because user may forget about deleting onion_private_key for a long time. This blog has so many articles about vulnerabilities or ways to attack Tor users: http://hackerfactor.com/blog and we cannot assume Tor is super anonymous which will somehow protect privacy of Bitcoin users. I am not sure but if there are ways or possible in future to associate transactions with onion service then using the same address for long is bad practice.

As sipa, gmaxwell and few others mentioned changing it on every restart will affect the way it works. Also will depend on the time bitcoind is running before restart. So, best solution is to have one option if enabled it should either ask the user to save the time interval or randomly delete the file once in every few days.
Bitcoin works perfectly fine over tor without creating any HS or accepting incoming connections– and this is generally the most private way to use it. @gmaxwell I am not sure If I agree with this statement or maybe need more details/context.
Why should you run a Bitcoin hidden service on your node?

It increases the privacy of other Bitcoin users who are anonymizing their actions via Tor. Specifically, it is a countermeasure to many of the “network observer” attacks listed on the Open Bitcoin Privacy Project’s threat model.
It makes your own node more robust against Sybil attacks and network partitions.
It doesn’t require much more computational resources to run, just the one-time setup cost of configuring your machine.

https://blog.lopp.net/how-to-run-bitcoin-as-a-tor-hidden-service-on-ubuntu/

I have also suggested two points to be added in Tor documentation: #19961#pullrequestreview-496994023

Examples to run Bitcoin as onion service, use of tor bridges and safe ways to connect over tor Checking onion address

gmaxwell commented at 10:39 am on October 8, 2020: contributor

Per Bitcoin Core run session is certainly not pointless, in fact very much the thing this calls for.

The fact that it’s what you’re asking for alone does not make it non-pointless. :) I think I gave an adequate explanation as to why changing your HS endpoint largely defeats the purpose of having a HS endpoint at all, it’s not clear to me how much of my comment you’ve read.

https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service Why do I think we need to automate renewal of onion address? Because user may forget about deleting onion_private_key for a long time.

The bitcoin wiki is an open public wiki, most changes go without any review by anyone. It frequently contains confused or wrong information for substantial spans of time. (it also frequently has good stuff… but “the wiki says something” isn’t by itself much of a case).

I am not sure but if there are ways or possible in future to associate transactions with onion service then using the same address for long is bad practice.

That would be a serious vulnerability in its own right. If someone is concerned about that the best move is to not have a HS on that node at all. If we’re just speculating about some hypothetical vulnerability that might somehow be discovered, not running a HS is the only clear solution. Otherwise any particular rotation schedule might be insufficient.

Also, it sounds like the text you are quoting is concerned with identifying material on your own machine… however there is absurdly identifying material all over a bitcoin install– in the logs, in the ancillary data created by the databases, in the shell histories of cli users, etc.

It makes your own node more robust against Sybil attacks and network partitions.

Unlikely: Connecting out to HS likely does, but your nodes HS address is unrelated to making out-bound connections. Inbound connections are potentially entirely attacker controlled.

But I think my question there wasn’t clear. I am not criticising the use of HS, but pointing out that if someone is operating in some super security paranoid mode then the correct move is to not listen at all on the node they are trying to protect, because any listening lets attackers actively connect into them. Frequently changing HS addresses is the worst of all worlds– attackers can still connect but because the address often changing it won’t add much (if any) connectivity to the network and even wastes peers time/bandwidth with useless old addresses (this could potentially be reduced by adding a expiration time to addr records– but that seems like a lot of work for a behaviour without much clear utility).

Aside, pages like https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service are extremely outdated and wrong. No configuration is needed to setup a hidden service now beyond having a tor install with a working control port, and using that is covered in tor.md. The reason it doesn’t go into more detail is because those details are all automated and not needed anymore.

willcl-ark commented at 4:21 pm on September 21, 2023: contributor

We think this issue is now resolved as this can be done by removing the keyfile, please feel free to comment here or open another issue if you disagree.

willcl-ark closed this on Sep 21, 2023

Willtech commented at 10:05 pm on January 1, 2024: contributor

We think that is what the configuration is for, less digging in files. If we must all configuration can be added strictly by command line.

Tor ephemeral hidden service rejuvenation #17491