Using Sparrow with Tor daemon #83
Comments
|
Yes - just configure the proxy settings: proxy on, host localhost, port 9050. Sparrow will prefer this if it is configured. |
|
There are no proxy settings inside the Core RPC tab. Will inputting them inside the Public Server tab or Private Electrum tab do the trick? Perhaps proxy setting could be abstracted from the various backend options? |
|
I ought to have mentioned I'm pointing this at a Bitcoin Core node that is not local to the Sparrow machine. |
|
Unfortunately the bwt project which Sparrow uses internally to connect to Bitcoin Core is waiting on proxy support on one of it's dependencies, the rust-bitcoincore-rpc project. Essentially, that project needs to update to a newer version of it's jsonrpc library for Tor proxy support to be possible. You can see the open PR for this here: rust-bitcoin/rust-bitcoincore-rpc#154 This is a good place to track this, so cc'ing @shesek (who is aware of the above) |
|
May I ask why Sparrow is using BWT to connect to Bitcoin Core? Would it be possible to connect directly via RPC as Specter and FullyNoded do, for example? |
|
Sparrow uses the Electrum server protocol to remain independent from the Bitcoin Core wallet. Using the Bitcoin Core RPC directly would effectively mean recreating BWT in some way in order to maintain this independence. If Bitcoin Core ever decided to build an address-based index this would not be an issue - unfortunately this seems very unlikely. |
|
OK so as I understand it, this functionality is delegated to BWT itself, which is packaged as a binary inside of Sparrow? I think I can get the PR above or equivalent functionality into the sparrow stack, I just need to know what the dependency chain is. Swappable transports were implemented in rust's jsonrpc library since 0.12.0. I was just able to create a PR here to get the new transport machinery into the actual bitcoincore rpc library. But it sounds like from up thread that there remains the issue of after this gets merged we need to update BWT to use an optional tor transport. Correct? |
Yes correct. Updating BWT shouldn't be an issue, but @shesek would be able to comment better on this. |
|
Outstanding Action: Discuss with @shesek the possibility of an "optional tor transport" in bwt |
|
I would prefer that it wasn't low priority and am willing to give dev resources to actually writing the code to do so. However, the code is going to be contingent upon getting this merged first. |
|
I regard this as Medium Priority (although I'm not recommending this approach - I don't think opening Bitcoin Core RPC over Tor is a great idea for privacy reasons). However I certainly see the need for this, and I know @shesek is keen to implement it in BWT once the necessary support has been added to rust-bitcoincorerpc. |
|
What privacy leak are you concerned about with RPC over Tor?
…On Fri, May 21, 2021 at 1:03 AM craigraw ***@***.***> wrote:
I regard this as Medium Priority (although I'm not recommending this
approach - I don't think opening Bitcoin Core RPC over Tor is a great idea
for privacy reasons). However I certainly see the need for this, and I know
@shesek <https://github.com/shesek> is keen to implement it in BWT once
the necessary support has been added to rust-bitcoincorerpc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6YY427ESEZSTHZV3GIWC3TOYAUJANCNFSM4Z5PX5JQ>
.
|
|
The issue is that most places the .onion address and RPC auth will be stored are not password protected - config files etc. Learning the RPC .onion address means you can easily extract all the watched addresses and their balances. Worse, you can do this remotely, which makes it even easier than scanning the Bitcoin Core wallet files themselves. That said, some many not consider this an attack vector they are concerned about - it's one wouldn't be happy with though. |
|
I am not sure where you get the idea that RPC over Tor is not password
protected but somehow RPC over not-Tor is better. In every case I’ve ever
seen, Core has RPC credentials set and even if those aren’t encrypted on
disk, I’m not sure how learning the onion address grants access to the RPC
credentials.
Am I misunderstanding your claim?
…On Fri, May 21, 2021 at 9:08 AM craigraw ***@***.***> wrote:
The issue is that most places the .onion address and RPC auth will be
stored are not password protected - config files etc. Learning the RPC
.onion address means you can easily extract all the watched addresses and
their balances. Worse, you can do this remotely, which makes it even easier
than scanning the Bitcoin Core wallet files themselves.
That said, some many not consider this an attack vector they are concerned
about - it's one wouldn't be happy with though.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6YY4ZPKIKEUEAW5V2JJ7DTOZZO3ANCNFSM4Z5PX5JQ>
.
|
|
RPC over not-Tor is generally limited to local network attacks, which is not true for RPC over Tor. RPC credentials are usually not encrypted on disk in config files etc. The standing advice has been to not expose RPC beyond localhost: https://bitcoin.stackexchange.com/questions/69080/rpc-json-outside-localhost |
|
Ok this isn’t anything to do with Tor but is an indictment of any kind of
remote node. Unfortunately this seems unavoidable if you want to have
multiple wallets on multiple devices and don’t want to independently sync
them. It seems that the way to deal with what you’re talking about is to
not allow external nodes of any kind. Personally I think limiting sparrow
to only be usable with an internal node is not a great idea. People want to
be able to use their existing nodes for their wallets. I really like
sparrow and the only barrier to using it is being able to input a remote
node.
…On Fri, May 21, 2021 at 9:22 AM craigraw ***@***.***> wrote:
RPC over not-Tor is generally limited to local network attacks, which is
not true for RPC over Tor. RPC credentials are usually not encrypted on
disk in config files etc.
The standing advice has been to not expose RPC beyond localhost:
https://bitcoin.stackexchange.com/questions/69080/rpc-json-outside-localhost
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6YY42DMMX44MWZV2YEVEDTOZ3DRANCNFSM4Z5PX5JQ>
.
|
Electrum servers don't carry this risk, since they index the entire blockchain, and you can't learn anything about a particular wallet by connecting to them.
Thanks - and as I said before I'm keen to support this functionality. Just wanted to point out the risks. Let's make it happen. |
|
Understood. Yes, contingent on getting a valid Authenticated RPC connection
to Core you can absolutely have a privacy leak. I’m primarily contesting
the “ease” of that attack in the presence of Torv3 (blinded keys keep onion
addrs undiscoverable). The link is also encrypted so network actors have no
insight. Finally you’d have to get read access to the disk of the remote
node to get the credentials to Auth to the RPC.
I misunderstood your original statement. Glad that you’re willing to merge
something that would implement this. I’ll steward the requisite PRs in the
dependencies and revisit here when the deps are ready.
😎
…On Fri, May 21, 2021 at 9:35 AM craigraw ***@***.***> wrote:
Ok this isn’t anything to do with Tor but is an indictment of any kind of
remote node.
Electrum servers don't carry this risk, since they index the entire
blockchain, and you can't learn anything about a particular wallet by
connecting to them.
I really like sparrow and the only barrier to using it is being able to
input a remote node.
Thanks - and as I said before I'm keen to support this functionality. Just
wanted to point out the risks. Let's make it happen.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6YY44MQLPPHB75MEVVCILTOZ4TLANCNFSM4Z5PX5JQ>
.
|
|
I express my interest on this feature, but it works with electrum already, so if possible to mention RPC on the title. |
|
@ProofOfKeags any progress on this front? |
I believe this is stuck in the dependencies still. We are approaching a release that allows archival nodes and will advise our users to go that route to use Sparrow when complete. Until the dependencies get caught up pruned nodes will be unable to use Sparrow unfortunately |
Thanks, but I'm a little confused - is use of RPC over Tor in rust-bitcoincorerpc connected to node pruning in some way? |
|
rust-bitcoin/rust-bitcoincore-rpc#180 has been merged. The library was released at 0.14.0 5 days ago which includes the changes for swappable transports. So this should allow for sending over a sock5 tor connection to the core instance in question.
Not at all. They are separate concerns. Though both of them affect our current users. But this issue is strictly about remote node access over tor. |
Sweet! 🎉 Will be looking into adding SOCKS proxy support to BWT, probably in the coming days. |
|
Should this issue be closed? |
|
Indeed it should. Thanks for the upstream work. |
Sorry to necrobump, was this support added to BWT? |
Yes, SOCKS5 proxy support was added to bwt (bwt-dev/bwt#21, bwt-dev/bwt@97f9edf) And to Sparrow in v1.51: https://github.com/sparrowwallet/sparrow/releases/tag/1.5.1 |
|
Cheers, take care |
Love the built-in tor support, but this does not play nicely when running the tor daemon for other applications as Sparrow wants port 9050, which is occupied. Would it be possible to offer to use the existing connection instead of Sparrow's built-in option?
The text was updated successfully, but these errors were encountered: