-
Notifications
You must be signed in to change notification settings - Fork 35.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tor ephemeral hidden service rejuvenation #17491
Comments
Concept ACK. If general consensus is positive I'd like to create this. |
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. |
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. |
Concept ACK |
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. |
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.
Per Bitcoin Core run session is certainly not pointless, in fact very much the thing this calls for.
It is certainly not necessary to close off the old ephemeral session, it can simply time out as far as Tor network is concerned. |
https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service
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.
@gmaxwell I am not sure If I agree with this statement or maybe need more details/context.
https://blog.lopp.net/how-to-run-bitcoin-as-a-tor-hidden-service-on-ubuntu/
Examples to run Bitcoin as onion service, use of tor bridges and safe ways to connect over tor |
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.
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).
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.
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. |
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. |
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. |
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 CoreAdditional 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.
The text was updated successfully, but these errors were encountered: