Skip to content
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

Unable to connect to onion node electrum server #44

Open
Engelberg opened this issue Apr 8, 2020 · 29 comments
Open

Unable to connect to onion node electrum server #44

Engelberg opened this issue Apr 8, 2020 · 29 comments

Comments

@Engelberg
Copy link

I enabled the new built-in Tor support, and set custom server to a private electrum server with a v3 onion address. When I start up the wallet, the "connecting" message in the upper-left continues to flash, and when I tap on it, it shows on the status that Internet and Tor are connected, but Electrum is still connecting.

I double-checked that I entered the address correctly, and that the onion address is indeed accessible from other clients, and it's an electrum server I personally set up with a certbot based certificate (which works fine with electrum's mobile client, which also requires a certificate).

@t-bast
Copy link
Member

t-bast commented Apr 8, 2020

Can you share your logs? Make sure you edit your electrum server address and other private information.

@Engelberg
Copy link
Author

Sure, will do. Some additional info is that I was using the onion node successfully through with Phoenix through orbot. It looks like my server setting got deleted in the latest update and it was using a random server again (which is a little unfortunate, because it means the set of addresses which go together was exposed to someone at random), so I re-entered in the server, and switched over to using the new built-in Tor, and had the problem. I have not tried going back to orbot, but that's something that might be worth testing as a point of comparison.

@dpad85
Copy link
Member

dpad85 commented Apr 8, 2020

Hello,

Connecting to an onion electrum server does work, I have tested it both with a server we manage and a third party.

Following the 2019 attacks on Electrum, I believe that many servers have setup a ddos protection system and a lot of exit nodes are blocked. But you manage this server yourself and it works with other apps, so I guess that's something else.

Have you set the port in the electrum address you entered in Phoenix?

@Engelberg
Copy link
Author

I've emailed the log to bastien. I tested turning off the built-in Tor and going back to Orbot and setting Phoenix as a VPN-through-Orbot app, but am having the same trouble connecting to the electrum server from Phoenix, even via Orbot.

@t-bast
Copy link
Member

t-bast commented Apr 9, 2020

The logs are not yielding anything obvious. We see a lot of connection attempts where it seems to successfully connect, then lose connection after 10 seconds (timeout).

This pattern repeats very frequently:

2020-04-08 12:38:44,309 INFO  f.a.e.b.e.ElectrumClient  - connecting to server=<editedoutonionservername>.onion:50002
2020-04-08 12:38:44,314 INFO  f.a.e.b.e.ElectrumClient  - connected to server=<editedoutonionservername>.onion:50002
2020-04-08 12:38:54,328 INFO  f.a.e.b.e.ElectrumClient  - server=<editedoutonionservername>.onion:50002 connection error (reason=socks5, none, /127.0.0.1:10462 => <editedoutonionservername>.onion:50002, timeout)
2020-04-08 12:38:54,331 INFO  f.a.e.b.e.ElectrumClient  - server=<editedoutonionservername>.onion:50002 connection error (reason=socks5, none, /127.0.0.1:10462 => <editedoutonionservername>.onion:50002, timeout)
2020-04-08 12:38:54,332 INFO  f.a.e.b.e.ElectrumClient  - server=<editedoutonionservername>.onion:50002 channel closed: [id: 0xbc8a8bd9, L:::/:::<some_random_port> ! R:/127.0.0.1:10462]
2020-04-08 12:38:54,333 INFO  f.a.e.b.e.ElectrumClientPool  - lost connection to <editedoutonionservername>.onion:50002

There's one suspicious log line, but it's for the connection to the acinq node, not to electrum:

2020-04-08 15:48:18,265 INFO  f.a.p.AppViewModel$startNode$2  - tor message: STATUS_CLIENT: WARN DANGEROUS_SOCKS PROTOCOL=SOCKS5 ADDRESS=34.239.230.56:9735

@dpad85 I don't know if the 10 seconds timeout / reconnection pattern is something you've seen before?

@t-bast
Copy link
Member

t-bast commented Apr 9, 2020

One thing to note that may be related to this Phoenix release, is that when connecting to servers over Tor we use the SSL=OFF mode.

Maybe your server is rejecting those requests because they're not using SSL?

@sstone
Copy link
Member

sstone commented Apr 9, 2020

Maybe your server is rejecting those requests because they're not using SSL?

It's very likely since 50002 (the port you are using) is typically used for SSL connections. If you enable plain tcp sockets on your electrum server and create a hidden service for the relevant port (usually 50001) it should work.

@t-bast
Copy link
Member

t-bast commented Apr 9, 2020

Good catch, if that fixes the issue we should probably add this to our FAQ or explicitly mention it in the app (instructions below the textbox that lets users set their custom electrum server).

@Engelberg
Copy link
Author

When I first set up my electrum server last year, I initially set it up on port 50001 using the unencrypted TCP protocol, because that's certainly the easier way to set up the server. What I quickly discovered was that this was heavily frowned on by the community, and not well supported. Within the electrum desktop client, you have to go through a lot of hoops to specify that you want to use the unencrypted tcp protocol. In the Electrum mobile client, it doesn't support it at all (see spesmilo/electrum#5278). Even though Tor encrypts its own traffic, making SSL unnecessary, I was urged to use SSL as "best practice" by the Electrum community. So I bit the bullet and did the extra work to get an SSL certificate and set up my server in that recommended way. That allows me to use the Electrum mobile client, and makes it a lot easier to use the Electrum desktop client as well. All your documentation currently talks about needing an SSL certificate if you're going to connect to your own Electrum server via Phoenix, so I assumed you do the exact same thing as the Electrum mobile wallet. I'm surprised to hear that you actually do the opposite, and only support non-SSL connections over Tor.

@t-bast
Copy link
Member

t-bast commented Apr 10, 2020

I'm sorry you're getting bitten by that while you've done everything well...

The reason we do that is that we've had many user requests to remove the SSL requirement for Tor (for the reason you mention; when using Tor it really doesn't make any sense to add another layer of encryption on top, and people didn't want to bother with getting a valid SSL certificate). See ACINQ/eclair#1278 for details (where @sstone mentions that this PR has exactly the drawback you're running into).

We didn't add hooks to handle both options (Tor without SSL / Tor with SSL) because we weren't sure how to handle the UX to avoid it becoming a mess. But your use-case shows that we probably need to add a "Use TLS" checkbox in the custom electrum server page to handle exactly that...

@Engelberg
Copy link
Author

I wonder if an acceptable UX solution would be to use the port number to determine whether SSL is desired. That's probably not a 100% perfect way to do it, but most people seem to follow the standard port convention for electrum servers.

@t-bast
Copy link
Member

t-bast commented Apr 10, 2020

That's probably a good first step, I'll give it a quick try.

@t-bast
Copy link
Member

t-bast commented Apr 10, 2020

@CandleHater would that work for you? Is your electrum server exposing the unencrypted port 50001 and is that what you'll use in eclair-mobile?

@sstone
Copy link
Member

sstone commented Apr 10, 2020

It's very easy to setup your Electrum server to have its plain tcp service only accessible through TOR, and if you want to use it from clients that require SSL over TOR then you can setup 2 different hidden service (one for each port), so I'd leave things the way they are now.

@t-bast
Copy link
Member

t-bast commented Apr 10, 2020

Ok in that case what we currently have isn't great, because it doesn't allow you at all to use Tor with SSL.

I'll do a small change in eclair-mobile/phoenix so that when an onion address is used for the electrum server:

  • if it uses port 500001 then we disable SSL
  • otherwise we use strict SSL

That means the solution for people using a self-signed certificate for their electrum server over Tor will need to instead use the plain tcp service, and people with a valid certificate can use the TLS one.

Does that sound good?

@sstone
Copy link
Member

sstone commented Apr 10, 2020

I don't think that it is necessary, if someone wants Phoenix to use their Electrum .onion server then they just need to create a hidden service for its tcp port. It's safe and very easy.

@Engelberg
Copy link
Author

Engelberg commented Apr 10, 2020

@t-bast I like your proposed solution, and I feel there is value to accommodating SSL over Tor, especially if you can do it without complicating the UX. I frequently see SSL over Tor described as a best practice, offering added benefits even though Tor provides its own encryption, and would like to be able to follow these recommendations for the most secure setup.
https://tor.stackexchange.com/questions/11747/why-do-tor-hidden-service-operators-bother-with-ssl-tls-encryption
https://www.pcworld.com/article/2845152/digicert-is-considering-ssl-certificates-for-more-tor-hidden-services.html

@ghost
Copy link

ghost commented Apr 14, 2020

I had no problem connecting phoenix to my public electrumx server over tor version 3 (and version 2).

In "Set server...", I inserted:
j6avevv2nyk4oklpfyaembwvrifeaqbl6ljpp754f5i5ld7opfe5paqd.onion:50001
and it says: "Connected to: ...".

I run my electrumx server with the following anit-ddos variables set to zero:

COST_SOFT_LIMIT=0
COST_HARD_LIMIT=0

but run electrumx at 30% cpu with cpulimit to protect my server from ddos attacks.

@t-bast
Copy link
Member

t-bast commented Apr 14, 2020

Yes this is expected, there's no issue when using the plain tcp version (port 500001).
We're still not 100% sure how to best handle Tor + TLS without too much impact on the UX (matching on the port is a bit fragile) but we're looking into it.

@t-bast
Copy link
Member

t-bast commented Apr 14, 2020

TBH @Engelberg for now I'd recommend exposing a plain tcp version of your Electrum node to unblock you.
If you re-read the links you forwarded (and all the other discussions about Tor + TLS on the web) in the case of Phoenix/Eclair-Mobile TLS adds absolutely nothing (there's no client certificate and we're not inside a browser so no hostname validation), you don't get more security when adding TLS on top of Tor.

@ghost
Copy link

ghost commented Apr 14, 2020

@t-bast correction (2x): 50001 not 500001 :-)

@Engelberg
Copy link
Author

If you re-read the links you forwarded (and all the other discussions about Tor + TLS on the web) in the case of Phoenix/Eclair-Mobile TLS adds absolutely nothing (there's no client certificate and we're not inside a browser so no hostname validation), you don't get more security when adding TLS on top of Tor.

The quora link said: "Tor's encryption is a transport. Like clearnet routing. And yes - it can be also "played with", even discarded in case of all four chain members are malicious nodes, but even in that case a HTTPS on your side ensures you of MitM-resistance even in this bad screinario"

Is that not an example of how you get more security when adding TLS on top of Tor?

@t-bast
Copy link
Member

t-bast commented Apr 15, 2020

TBH that sentence doesn't make any sense to me. It seems completely inaccurate and it makes me feel like the author has no clue what he's talking about and just throws random technical words at the problem :)

If you can translate his example to something I understand we can probably discuss that further.

From what I've seen, the only reasons one would want to use TLS on top of Tor are:

  • using client certificates to whitelist incoming connections -> not our case
  • proving real-world identity / ownership of a brand -> not our case either
  • ensuring non-technical users see the green padlock in their browser when coming to your website -> not our case either

@vincenzopalazzo
Copy link

Hi @t-bast,

I want share with you a little problem that I have today with phoenix, I'm trying the Blockstream electrum server and blockstream provide the tor support on TPC connection only.
When I try to connect on the torv2 and torv3 phoenix, it remains to wait for the connection, I want ask if the phoenix want inside the TextView the url witl the following format `explorerzydxu5ecjrkwceayqybizmjjznk5izmitf2modhcusuqlid.onion:110' or I'm doing something wrong?

@t-bast
Copy link
Member

t-bast commented Jul 15, 2020

@vincenzopalazzo IIRC the latest phoenix version should be able to connect to electrum server over Tor.
It may simply be an issue with the port you're trying to connect to (Tor + TLS vs Tor only).

@dpad85 is better suited to let you know if the format you entered is the right one.

@dpad85
Copy link
Member

dpad85 commented Jul 20, 2020

There is a typo in the address written in their blogpost (there's a missing p somewhere). Please use: explorerzydxu5ecjrkwceayqybizmpjjznk5izmitf2modhcusuqlid.onion:110

@t-bast
Copy link
Member

t-bast commented Jul 20, 2020

48udhs

@ghost
Copy link

ghost commented Oct 25, 2020

I encountered this issue (I am running RaspiBlitz). The change of the port 50002 to 50001 worked. However - do I understand correctly that now the communication is now not encrypted by SSL and my IPS can potentially read it?

@dpad85
Copy link
Member

dpad85 commented Oct 27, 2020

do I understand correctly that now the communication is now not encrypted by SSL and my IPS can potentially read it?

No, with Tor communications are always encrypted.

However it just occurred to me that c31593c does not actually allow TOR+TLS as I thought it would - because there also is a rule in eclair-core: https://github.com/ACINQ/eclair/blob/bef94ed9c2c57dfd1a08f31d4f9a63990840cbe0/eclair-core/src/main/scala/fr/acinq/eclair/Setup.scala#L154. It should have been removed, could be a regression after a merge.

So for now the SSL checkbox for onion is actually ignored. Will fix.

dpad85 pushed a commit that referenced this issue Sep 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants