Is there any way to get ledger live working properly through tor and/or tails?
I can get the OS to read my ledger fine by downloading the Linux app image for ledger live, then changing the udev rules to allow for proper interaction with the device.
BUT I can't actually use ledger live. I just get an 'oops, Internet looks down. Try again later' error every time.
Why does ledger live not allow tor use?
Edit: Here's response from /u/Alex_LocalMonero.
> Wow, sosxc! Thanks for taking the time to write out such a detailed post about the evils of CloudFlare. I agree with /u/sosxc that CloudFlare should be phased out, and I've already made the promise on multiple occasions that it will be phased out.
> In the meantime, luckily for you and anyone else who's concerned about these issues, we have a Tor service and i2p! Those are not routed through CloudFlare precisely because we wanted to provide a gateway for the cypherpunks.
> Tor: http://lclmnroewgycudgz.onion/
> i2p: http://lm.i2p/
I write this post to publically shame Localmonero.co for using CloudFlare.
CloudFlare breaks SSL/TLS trust model, encourages companies to lie to their customers/users, and spits on Tor users that value privacy.
CF is a man-in-the-middle between your browser and LocalMonero.co.
The LocalMonero.co domain refers to IP address controlled by CF, not LocalMonero.
CF decrypts everything you send to LocalMonero.co. After that they forward your request to LocalMonero's server across internet and it might be TOTALLY UNENCRYPTED plaintext even though the url is https, and there is a lock icon in your browser with valid cert. It is an option for LocalMonero whether the request will be encrypted or plaintext... end user cannot know which.
Even if CF sends encrypted to LocalMonero, they already decrypted the data and can store or forward all of it to anyone. Or a rogue employee can collect it and sell it. CF has thousands of employees.
CF is the largest man in the middle attacker in the world. It is a giant honeypot for hackers, rogue employees looking to make a buck, or intelligence agencies.
CF can only do this because LocalMonero willingly cedes the LocalMonero.co domain to CF. So LocalMonero is ultimately the responsible party for selling out your data and dis-respecting your privacy.
CF protected sites are nearly unusable for Tor users ... ie people that care about privacy ... ie people that tend to like Monero. CF places captcha after captcha in front of Tor users before they can use a protected site, and sometimes after. edit: I just tried and it seems that CF does NOT place a captcha for tor visitors to localmonero.co. Perhaps that is an option that site owners can turn on off. Regardless every other CF prot
How unique is your hidden service?
... keep reading on reddit ➡
2206 Server: nginx 1011 Server: Apache 326 Server: nginx/1.6.2 142 Server: Apache/2.4.10 (Debian) 89 Server: Apache/2.2.22 (Debian) 88 Server: lighttpd/1.4.31 87 Server: Apache/2.4.18 (Ubuntu) 81 Server: Apache/2.4.7 (Ubuntu) 60 Server: i337-xfog 55 Server: nginx/1.4.6 (Ubuntu) 48 Server: lighttpd/1.4.35 43 Server: lighttpd/1.4.33 43 Server: globaleaks 42 Server: nginx/1.12.0 40 Server: nginx/1.2.1 39 Server: Apache/2.4.25 (Win32) OpenSSL/1.0.2j PHP/5.6.30 38 Server: nginx/1.10.3 35 Server: TwistedWeb/12.0.0 32 Server: nginx/1.10.2 31 Server: nginx/1.10.0 (Ubuntu) 30 Server: nginx/1.13.1 30 Server: cyclone/1.1 27 Server: Apache/2.2.15 (CentOS) 23 Server: nginx/1.10.1 21 Server: mini_httpd/1.19 19dec2003 19 Server: iTor Server ! 16 Server: Apache/2.4.6 (CentOS) PHP/5.4.16 15 Server: Apache/2.2.22 (Ubuntu) 14 Server: Microsoft-IIS/8.5 13 Server: Apache-Coyote/1.1 11 Server: sorrynotgivingthataway 11 Server: Microsoft-IIS/7.5 11 Server: Apache/2.4.10 (Raspbian) 10 Server: lighttpd/1.4.45 10 Server: lighttpd 8 Server: nginx/1.9.13 8 Server: nginx/1.8.0 8 Server: Microsoft-IIS/10.0 8 Server: Apache/2.4.25 (Debian) 7 Server: TorHosting 7 Server: Apache/1.3.29 (Unix) mod_perl/1.29 PHP/4.4.1 mod_ssl/2.8.16 OpenSSL/0.9.7g 6 Server: PopFiles (http://popfilesxuru7lsr.onion) 6 Server: nginx/1.7.4 6 Server: FobbaWeb/0.1 6 Server: Caddy 6 Server: Apache/2.4.25 (Unix) 6 Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.6.28 5 Server: OpenBSD httpd 5 Server: nginx/1.13.2 5 Server: Monkey/1.5.6 5 Server: lighttpd/1.4.28 5 Server: Apache/2.4.6 (Ubuntu) 5 Server: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-04 OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.4.16 5 Server: Apache/2.4.26 (FreeBSD) PHP/5.6.30 5 Server: Apache/2.4.18 (Win64) PHP/5.5.0RC3 5 Server: Apache/2.4.10 5 Server: Apache/2.2.31 (Amazon) 5 Server: Apache/2 4 Server: tor_httpd 4 Server: nginx-1.8.1 4 Server: nginx/1.6.3 4 Server: nginx/1.10.1 (Ubuntu) 4 Server: mini_httpd/1.23 28Dec2015 4 Server: Microsoft-IIS/6.0 4 Server: lunarhttpd.china 4 Server: Apache/2.4.6 (CentOS)
I saw a post in /r/onions the other day where someone was asking what's the most important thing that's needed for the TOR network, and one reply was that a way of dealing with DDOS attacks is huge.
That got me thinking about Cloudflare.
Normally, a site configures their name servers to point to Cloudflare for DNS management and then in the Cloudflare interface, enters their web server(s). Cloudflare then publishes a multicast IP address of a Cloudflare load balancer as the A record for that website. So, even if there are 10 servers providing the webpage generation, if you examine the domains DNS records, it just shows that domain.com has one IP address. On the backend, Cloudflare just hits each server in a round-robin fashion.
So, my thought is to look into the feasibility of setting up an Onion CDN provider. The easy, but not secure, route is that sites would upload their private key for their original onion address to the system and then set up multiple web servers at a new onion addresses. They would then input the addresses into the control panel, and when a user requests the original onion address, the CDN would hit each of the new secret onion addresses, round robin, to get the data. Static assets would be cached.
Recently, Cloudflare offered the ability to let a site use their own SSL certificate while not actually uploading the private key to the Cloudflare system. Info: https://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudflare-without-having-to-turn-over-your-private-ssl-keys/ Infographic: https://blog.cloudflare.com/content/images/2014/Sep/illustration-keyless-ssl-explained-01.png
With it being possible to keep a private key on an offsite server with Cloudflare, I wonder if the same basic principal could be used to make it so that an Onion CDN provider could function with the offloading of the private key to a key server that the customer controls. This would allow the CDN provider to do load balancing and not have the private key in their possession.
One downside is that there is no way to do multicasting with Hidden Services. Even if you have multiple servers with the same private key, it's the one that's the most recent that gets hit. So, the best that a CDN can do is be in a good data center with a lot of bandwidth.
Another possibility is simply that the original onion address could just be a redirect service that redirects the user to the web server with the least load. It's not as elegant, but it might... keep reading on reddit ➡