I guess because having HTTP proxies specified _only_ remote DNS resolution is done. There is no point in having a flag then. See: http://mxr.mozilla.org/mozilla-central/ ... ervice.cpp and the instances where TRANSPARENT_PROXY_RESOLVES_HOST is consulted. That happens only if SOCKS proxies are used/about to get used.DaveG wrote:Thank you both for clarifying. Ok, so both SOCKS and HTTP proxies can do remote DNS lookups. The question is then: why is Firefox not giving me TRANSPARENT_PROXY_RESOLVES_HOST if this is the case?
DNS leak problem? [OBSOLETE]
Re: DNS leak problem?
Re: DNS leak problem?
Well, I would think the browser could still do a local DNS look up and give the IP to the proxy, but I have no idea what it actually does. Are you saying that Firefox will never do this? Once upon a time in Flagfox 3.something I just checked if any proxy was enabled and disabled entirely, but that ticked off someone who did have local DNS and wanted things to work.gkoppen wrote:I guess because having HTTP proxies specified _only_ remote DNS resolution is done.
https://developer.mozilla.org/en-US/doc ... #Constants
According to the doc this is not specific to any proxy type. It's just supposed to be the flag to check. Sifting through what type(s) of proxies are enabled through the prefs is exactly what I'm not supposed to be doing (it wouldn't work with FoxyProxy or anything similar), so as far as I'm concerned this is a Mozilla bug. Either they're broken or their docs are junk. I'll file a bug with them in a bit.This flag is set if the proxy is to perform name resolution itself. If this is the case, the hostname is used in some fashion, and we shouldn't do any form of DNS lookup ourselves.
In the meantime, just don't use Flagfox behind a proxy if you don't want DNS to be used. It doesn't work without it anyway as is said in many places.
Re: DNS leak problem?
Is there even any way to tell if an HTTP proxy is only doing remote DNS and local DNS is not allowed? I'm thinking I don't even have enough to file a bug with here.
It's entirely possible that HTTP proxy + no DNS is just not a use case Mozilla cares about. If this is a normal use case from a FoxyProxy point of view, then what is the way I'm supposed to proceed? As I said previously, I was already told by Eric that this was correct, so if I'm doing the "right thing" which is somehow wrong, then please just give me a patch to change it to whatever someone who actually knows anything about the messy intricacies of proxy configuration would want here.
Also, side question: Why is more than one type of proxy still supported at all? Is there a legitimate reason to not just use the latest version of SOCKS for everything, or is this just a problem of people not bothering to switch to a single standard? The more I learn about this, the sloppier it looks to me.
It's entirely possible that HTTP proxy + no DNS is just not a use case Mozilla cares about. If this is a normal use case from a FoxyProxy point of view, then what is the way I'm supposed to proceed? As I said previously, I was already told by Eric that this was correct, so if I'm doing the "right thing" which is somehow wrong, then please just give me a patch to change it to whatever someone who actually knows anything about the messy intricacies of proxy configuration would want here.
Also, side question: Why is more than one type of proxy still supported at all? Is there a legitimate reason to not just use the latest version of SOCKS for everything, or is this just a problem of people not bothering to switch to a single standard? The more I learn about this, the sloppier it looks to me.
Re: DNS leak problem?
Well, I have the same problem, and I'm pretty sure it's Firefox's fault.
Basically, Firefox sets TRANSPARENT_PROXY_RESOLVES_HOST flag according to network.proxy.socks_remote_dns.
But as the name implies, network.proxy.socks_remote_dns is only consulted when a SOCKS proxy is in use.
When an HTTP proxy is used, host names are NOT resolved locally, and that's the case with all modern browsers that I know of.
This is how IE uses an HTTP proxy: When a TCP connection is established, the first thing the browser sends is an ASCII string "GET http://www.google.com/ HTTP/1.1\r\n"
This is FF using the same proxy to access an SSL URL: "CONNECT www.google.com:443 HTTP/1.1\r\n" in this case.
Of course you can replace www.google.com with, for example, 173.194.113.80 -- but the browsers never do, and I don't know exactly why.
As for the DNS leak problem, here's what I've been doing for the past months:
Turn off autoupdate for Flagfox
When a new version is available, manually download the .xpi file
Open it with 7-Zip, browse to the file chrome\flagfox\modules\flagfox.jsm, press F4 to edit
Find the line
Change it to
Save the change and install the .xpi file
But I do hope Dave or the Firefox guys could finally find a way to solve this problem.
Basically, Firefox sets TRANSPARENT_PROXY_RESOLVES_HOST flag according to network.proxy.socks_remote_dns.
But as the name implies, network.proxy.socks_remote_dns is only consulted when a SOCKS proxy is in use.
When an HTTP proxy is used, host names are NOT resolved locally, and that's the case with all modern browsers that I know of.
This is how IE uses an HTTP proxy: When a TCP connection is established, the first thing the browser sends is an ASCII string "GET http://www.google.com/ HTTP/1.1\r\n"
This is FF using the same proxy to access an SSL URL: "CONNECT www.google.com:443 HTTP/1.1\r\n" in this case.
Of course you can replace www.google.com with, for example, 173.194.113.80 -- but the browsers never do, and I don't know exactly why.
As for the DNS leak problem, here's what I've been doing for the past months:
Turn off autoupdate for Flagfox
When a new version is available, manually download the .xpi file
Open it with 7-Zip, browse to the file chrome\flagfox\modules\flagfox.jsm, press F4 to edit
Find the line
Code: Select all
if ( (proxyinfo != null) && (proxyinfo.flags & proxyinfo.TRANSPARENT_PROXY_RESOLVES_HOST) )
Code: Select all
if ( (proxyinfo != null) && (proxyinfo.flags & proxyinfo.TRANSPARENT_PROXY_RESOLVES_HOST || proxyinfo.type == "http") )
But I do hope Dave or the Firefox guys could finally find a way to solve this problem.