LedgerHQ / ledger-live-desktop

⛔️ DEPRECATED - Ledger Live (Desktop)
https://www.ledger.com/live
MIT License
954 stars 297 forks source link

Websocket Proxy passthrough #1073

Open kpiris opened 5 years ago

kpiris commented 5 years ago

Ledger Live Version and Operating System

When the manager is opened, ledger live checks Internet connectivity.

If I have a proxy (configured via environment variables), the program does not detect that connectivity, it shows a red message “Oops, internet seems down” and offers to retry; which never detects it (see attached screenshot ledger-live.proxy-netdown.png).

On my squid3 logs I have messages like this one: “TAG_NONE/400 4062 NONE error:invalid-request - HIER_NONE/- text/html”

If I unset proxy environment variables, then network detection, and the program, works fine.

I could attach application.log if you need it, I’m guessing you won't since I've been able to reproduce it on two different computers (one with debian sid, the other with debian stretch, both updated to date).

Thanks ledger-live proxy-netdown

gre commented 5 years ago

I guess because we use WebSocket here. Not sure if there is anything we can fix

lomax commented 5 years ago

https://stackoverflow.com/questions/38974731/websockets-not-connected-behind-proxy here is the suggestion how you could fix it. And even wikipedia describes these issues https://en.wikipedia.org/wiki/WebSocket#Proxy_traversal

meriadec commented 5 years ago

Problem comes from the proxy server itself (nb that we already use wss protocol) and I'm not sure we should prioritize special cases (for now), current solution works for the vast majority of users. @lomax feel free to create PR if you find solution / ways to test & reproduce in the app :+1:

lomax commented 5 years ago

@meriadec Have you tested it behind the proxy? It just can't detect internet connection behing the proxy which allow CONNECT only on 443 port and block all other ports except 80 and 443. @kpiris said he could provide any logs if needed as he manage the proxy himself. What additional info do you need?

meriadec commented 5 years ago

We can't test with your proxy :smile: As described before, it's not an issue with the app, but with some external infrastructure blocking app normal behaviour.

If you find a workaround in the app that works for you and doesn't bring any regression without proxy, you can totally make a pull request (if you do so, please provide any useful instructions for us to test). Thanks!

lomax commented 5 years ago

@meriadec Can you please name proxy and describe settings you've used to test the app connectivity through the proxy. Me and @kpiris reported that the app doesn't work behind the squid proxy. Could you elaborate if this is the problem with proxy in general why you are claiming proxy instance and not the app?

meriadec commented 5 years ago

Dude, like I said two times, we didn't tested any proxy configuration: it's not part of the app scope. As described in the issue decription: the app works fine without proxy. We can't do custom fixes for users custom configuration.

So repeating again: If you want to propose a fix yourself, it will be welcomely welcome.

Have a good day.

lomax commented 5 years ago

But old Chrome apps works behind the proxy. You've created the new standalone app that doesn't. I can give you a hint it is called regression and not "users custom configuration". Because proxies and firewalls is the common network infrastructure. You've just reduced connectivity options and saying that users must take care of it themselfs.

gre commented 5 years ago

the bug might be related to wss:// that is used in Ledger Live. the previous Chrome app was using ws:// . we have first to check all our API works with ws:// (including the new genuine check) , if it does maybe we could have an advanced option to use non secure websocket

gre commented 5 years ago

@lomax it's likely your Proxy supports ws:// but not wss://

would you mind checking on this?

https://www.websocket.org/echo.html

meriadec commented 5 years ago

you can also try setting the environment variable BASE_SOCKET_URL to ws://api.ledgerwallet.com/update

lomax commented 5 years ago

image The browser prevents me to initiate connection to unsecure socket ws://

echo.js:136 Mixed Content: The page at 'https://www.websocket.org/echo.html' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://echo.websocket.org/?encoding=text'. This request has been blocked; this endpoint must be available over WSS.
doConnect @ echo.js:136
echo.js:136 Uncaught DOMException: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
    at HTMLButtonElement.doConnect (https://www.websocket.org/js/echo.js:136:17)
gre commented 5 years ago

@lomax can you try to click on CONNECT, not the "Rock it" thing

capture d ecran 2018-07-13 a 11 48 20
lomax commented 5 years ago

you can also try setting the environment variable BASE_SOCKET_URL to ws://api.ledgerwallet.com/update

image

lomax commented 5 years ago

@gre I've got those errors after i click disconnect on wss://, changed it to ws:// and clicked connect. wss:// work just fine as you see from the screenshot. So I think that something wrong with the app and not the proxy as proxy pass wss://echo.websocket.org just fine. Could you place some test script on the Web that uses the same functions to open wss that in the app to test it from the browser?

lomax commented 5 years ago

I've tried http://www.websocket.org/echo.html to check ws:// and it indeed doesn't work image And for some reason i see request to wss:// from this page and to the different fqdn.

lomax commented 5 years ago

https:// wss:// session image

maciejbozemoj commented 5 years ago

any updates or plans to revert to Chrome ledger wallet app? Maybe someone found out workaround?

danuker commented 5 years ago

@maciejbozemoj I guess a workaround would be to run everything in a virtual machine, and configure the VM to use the proxy.

lomax commented 5 years ago

@danuker or even better inside VM which is inside another VM, so usb passthrough became you real problem and not this sophisticated web protocol tunneling.

gre commented 5 years ago

we might provide an option to set up the proxy parameters.

https://github.com/electron/electron/blob/master/docs/api/session.md#sessetproxyconfig-callback

gre commented 5 years ago

Please try again. We believe this issue is now fixed and was due to cloudfare.

lomax commented 5 years ago

Nope, it doesn't -> ledger-1.8.0-error.log

sargonpiraev commented 4 years ago

any updates?

cryptochrome commented 4 years ago

The guys at Ledger are such greenhorns who have next to zero clue. They call proxy servers "uncommon" and "non-standard". Half of the fucking world is accessing the internet through proxies, you idiots. Basically anyone accessing from company networks goes through proxies.

gre commented 4 years ago

It has been confirmed by many users that we improved the initial situation (we had cloudflare issues) so that's why I assumed the initial issue was fixed (specifically the one showing a live saying internet seems down), this issue has been created more than a year ago and there might be many reason of why you are experiencing network issues.

It can be good to have more detail because "it does not work" does not really help understanding the problem about what happens on your side (you can contact directly to the techsupport team). Alternatively if you are a developer you can investigate to give us precise detail on how we should reproduce the problem, no one at Ledger have this issue. Thanks

mac-b-71 commented 4 years ago

We are not connecting directly to the internet, so we also can't connect directly to your servers. If you will have isolated network with Proxy server set as an the only gateway to internet you will be able to reproduce this issue. Proxy

gre commented 4 years ago

ok, sorry i confonded this task with another one that was issuing the same manager error. So that's why this task is still opened, we can introduce this feature (and in fact, Ledger Live Desktop is open sourced so anyone wanting to take this is welcomed to 🙏) we're soon going to refactor our project / update some libraries and we'll keep this feature in mind.

NightProwler-dc commented 3 years ago

Any progress at all after two years?

gre commented 3 years ago

It's hard to understand exactly the needs and the constraints. What exactly are you looking for @NightProwler-dc ?

We are not aware of a lot of users actively asking for this feature so the best is probably to have OSS contribution on this. We are open source and we can take the time to review a Pull Request proposal of a solution.

dev note: In term of architecture, if it means a proxy on the HTTP, we have also to understand this need to be solved both on Electron side and in our internal node process side.

cvila84 commented 3 years ago

Hello all !

I have just bought a nano S and now I'm struggling as I'm behind a proxy (just like a lot of other people who are working from home on a corporate machine which requires a proxy). I just read the whole thread and I'm astonished by your arguments. This project is indeed OSS but since you are selling HW which work with this SW, we are no longer in a pure OSS context where you can just claim that you will wait for a PR coming outside from your company for a clearly standard use-case. If you have product owners, they should understand the business value of this request and ask your teams to work on it ASAP.

I should have checked this before buying your product, now I'm a bit disappointed here, especially because you are a french company and I should be proud of you as I am a french citizen.

Cheers

gre commented 3 years ago

@cvila84 Could you detail a bit more precisely what is your setup and your need? What kind of proxy? Is it using something like SOCKS?

I don't understand why you expect Ledger Live to solve this, as far as I'm seeing, at least on Mac, even Chrome don't have that settings available, instead they link you to the System configuration where you can set it up. It seems to be the same on Windows, it's a global system configuration, https://www.expressvpn.com/fr/support/troubleshooting/google-chrome-no-proxy/

cvila84 commented 3 years ago

@gre thanks for your answer !

Let me clarify a bit my situation which is probably the situation of a lot of other people that have to live with proxies. I know how to set/unset the proxy on my system and yes, the application is working very well when I'm unsetting the proxy.

The problem is I must use a HTTP proxy when I'm connected to my corporate network because of the VPN gateway firewall rules that force all the communication to go towards the VPN network through this HTTP proxy.

I made some tests with a simple squid proxy (as it is shipped with Ubuntu 20.04 LTS) and I think there is actually a problem on client side. When trying to access ledger API in HTTPS, instead of performing a HTTP CONNECT to the proxy and then perform the TLS session with the ledger servers, it directly asks the proxy to perform the GET/POST requests to API in HTTPS. This way of working should be reserved to unsecured HTTP requests. For the HTTPS requests, the TLS session shall be done by the client, not the proxy !

That said, the HTTPS requests done by the proxy should work even if this is not secured from a client perspective. I took a look to the tcpdump logs of squid and it appears the TLS handshake cannot be done because the server expects the SNI extension to be provided by the client. And because the SNI is only known by the client, the proxy will never be able to do the HTTPS requests by itself.

As a conclusion, the HTTP proxy client implementation in ledger live is faulty when HTTPS requests have to be done.

Hope it clarifies the situation !

eddieparker commented 3 years ago

FWIW I have the same issue and wish it was supported natively. That said, a work around I have is to set a custom route to avoid my proxy and go direct (may not work for whatever proxy you have), and this is windows syntax:

route add 104.0.0.0 MASK 255.0.0.0 192.168.1.254 metric 1

Basically I'm adding a route to 104.x.x.x through my gateway of 192.168.1.254 (yours may be different) and setting it to a high metric. This makes me go through a direct connection and bypass the proxy altogether. Again, may not be useful if you require a proxy, but posting it in case it helps someone.

cvila84 commented 3 years ago

@gre any updates ? I spent some time to provide you very detailed information about the issue, and now I believe it should not be that hard to fix it (or ask a fix if it is on 3rd party side). Thanks for your help :)

gre commented 3 years ago

Some core function in Ledger Live (manager) doesn't work behind a proxy environment. It has nothing to do with how proxy is set up via system or app settings!

Steps to produce:

  • Setup a http system proxy in OS (e.g. Tor uses http://127.0.0.1:9050). (Please google how to setup a proxy for Windows/Linux system)
  • Run Ledger Live.
  • Click on manager.
  • Connect a ledger device and unlock.
  • Manager shows ledger unlocked and a blank screen forever.

Unfortunately I'm not able to reproduce the problem. I'm using Tor on localhost:9050, set it up widely on my system (i can confirm my IP changes), and yet, I can use Ledger Live 2.20.0 (testing on Mac) and access the Manager, see and install apps without any issue (countervalues and blockchain services works as well).

Thanks @cvila84 for your explanation. If the issue is on client side, i'm not sure where it needs to be fixed because we are just using standard library (axios/axios) / Electron / Node.js here, so it might be a bug in these. I will discuss the topic internally and see if anyone reproduce on different environments.

cvila84 commented 3 years ago

Quick search on axios gives https://github.com/axios/axios/issues/925 and https://github.com/axios/axios/issues/3384

gre commented 3 years ago

Would you mind sharing your environment regarding proxy? printenv | grep -i proxy I have a potential fix in one of our library but it's still a blind fix from my side (from information I could find in these axios discussion) as I will need to have a reproductible environment (so far, i've tried both through Tor and Proxyman, and didn't reproduce any issue).

Thanks!

cvila84 commented 3 years ago

@gre not sure if the question is for me but just in case, I'm a Windows user and to test, I installed a squid proxy on my other machine under Linux. I'm then using HTTP_PROXY=http://unix-host:3128 and HTTPS_PROXY=http://unix-host:3128

cvila84 commented 3 years ago

@gre what is the next step ? do you plan to issue a new version so I can test ?

gre commented 3 years ago

Unfortunately the current attempt didn't work and we'll need more resources to continue on this Draft PR.

cc @juan-cortes let's chat tomorrow on this

ledgetest commented 3 years ago

@gre @cvila84

Unfortunately I'm not able to reproduce the problem.

I have also the proxy problem.

To reproduce the problem i would recommend you to create a Live Linux USB stick where the whole traffic runs automatically through a proxy. Not much to do here.

As example Tails OS with TOR:

https://tails.boum.org

After installation of Ledger Live in Tails the Ledger Live software stops finaly with an error: no internet.

Only Ledger Live doesn't find a internet connection through the proxy. Other software packages including Electrum have internet connection.

printenv: SOCKS5_SERVER=127.0.0.1:9050 SOCKS_SERVER=127.0.0.1:9050

gre commented 3 years ago

@juan-cortes in our team has been able to reproduce as well as identify where the issue was coming from. A work in progress is in https://github.com/LedgerHQ/ledger-live-desktop/pull/3545. however we still need to figure out how to handle properly http vs https proxies (need more precision from @juan-cortes)

ndreisg commented 3 years ago

A little hint for all the squid users here: http://lists.squid-cache.org/pipermail/squid-users/2018-July/018583.html Not sure if this post is still up2date but at least back in 2018 squid didn't support native websocket connections

DosPuppet commented 2 years ago

Same problem here, several person who need to use ledger live, but they are behind a proxy. It's a no go. I reproduce it easily on a local windows with a squid, and yes, the direct get doesn't work. Tried @gre build (https://github.com/juan-cortes/ledger-live-desktop/tree/proxy-fix-test) and this one works like a charm (http and https proxy vi squid), but it's an older version.

Any news for an evolution in the main branch ?

Thanks.

bormiopoli commented 2 years ago

Can you confirm your Cloudfare host accepts all sort of proxy connections? could you catch up with them for the specifications? Up to now sounds like your host may be forbidding proxyfied connections.