Linux .deb version can't use proxy

[GoogleCodeExporter]

Google Earth doesn't has means to configure a proxy server through its GUI.

So, I use an environment variable to set the proxy server.

With version 6.0.3.2197 this methos worked OK, but after installing version 
7.1.2.2041-r0 this no longer works.

What steps will reproduce the problem?
1. Download .deb package from Google Earth web site
2. Install in Debian based system (tried with Debian Wheezy i386 and amd64)
3. Set environment variable http_proxy=http://proxy.server:port AND 
HTTP_PROXY=http://proxy.server:port  
4. Run google-earth

Expected behavior (observed in version 6.0.3.2197): Connect to Google Earth 
servers and "just work normally"

Observed behavior: After a little time with a black screen (where I should see 
the Earth Globe), a notification appears statiung that "Google Earth can't 
connect the login server to activate your account... (error code c000000c)", 
and then another: "Google Earth failed connect to database. The URL 
http://kh.google.com:80/ does not appear to be valid, or the server may be 
temporarily down."

Original issue reported on code.google.com by nigles...@gmail.com on 21 Feb 2014 at 2:41

[GoogleCodeExporter]

rpm version is same.  Using basic auth proxy here with 
http_proxy="http://username:password@proxy.host.com:8000" style settings that 
work for everything else like wget etc.

Original comment by donhoo...@gmail.com on 30 Apr 2014 at 2:53

[GoogleCodeExporter]

same here. 7.0 works fine with ubuntu, but 7.1 doesn't

Original comment by mathieu....@gmail.com on 5 May 2014 at 1:48

[GoogleCodeExporter]

same here with version 7.1.4 (rpm on a Fedora 20)

a tcpdump for outgoing traffic shows that the http_proxy variable seems to be 
ignored

Original comment by branco...@gmail.com on 14 Apr 2015 at 10:58

[GoogleCodeExporter]

Same issue experienced here with Debian 8 64-bit and Google Earth 7.1.4.1529

http_proxy, https_proxy and ftp_proxy all set with proxy authentication.
wget, apt-get and other tools work fine but NOT Google Earth.

Original comment by stevekam...@gmail.com on 2 May 2015 at 11:31

[GoogleCodeExporter]

Same problem - Debian 7 64bit - in addition the link for 7.0 on the download 
page takes you to a 5.something bin installer which fails due to numerous 
dependencies

Original comment by tim.atki...@cgg.com on 2 Jun 2015 at 11:27

[GoogleCodeExporter]

Same problem here. No one knows how to solve this on Ubuntu?
Thanks

Original comment by tam...@gmail.com on 2 Jul 2015 at 4:47

[GoogleCodeExporter]

Same here

Original comment by andrei.b...@gmail.com on 6 Jul 2015 at 12:56

[GoogleCodeExporter]

I'm starting to wonder if this is the right place for this bug report.
Anyway, I'm also starting to work on ugly workarounds.
I'll repeat: this is ugly, maybe it can help somebody but use at your own risk.

Now, assuming your network interface is "eth0":

0) check that google earth is the only thing trying to reach a port 80 on a 
public ip:

tcpdump -i eth0 -n 'tcp and not ip6 and not (src net (10 or 172.16/12 or 
192.168/16) and dst net (10 or 172.16/12 or 192.168/16))'

(it should log a ton of things, but only when google earth is running)

(thanks to 
http://serverfault.com/questions/123540/tcpdump-filter-that-excludes-private-ip-
traffic)

1) http://ntlmaps.sourceforge.net/
If your proxy uses NTLM, This can create a local proxy (without authorization) 
that authenticates on an existing NTLM proxy.
Let's stay you manage to start it on port 3128

2) (still working on it) iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 
80 -j REDIRECT --to-port 3128

This redirect all tcp traffic trying to reach a port 80 (presumably things that 
doesn't understand http_proxy variable) to your local port 3128, hopefully 
passing from ntlmaps. You'll probably need to ad a rule for port 443 too.
This has a couple of issues, because it redirects ALL traffic including the one 
going to private ips (let's say, internal websites that normally doesn't go 
through proxy)

(still, this is like killing a fly with an hand granade and then a cannon and 
then a nuke)

Original comment by branco...@gmail.com on 8 Jul 2015 at 10:31