541567 - Flagfox leaks DNS requests

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect)

Description

[Eric Jung [:ericjung]]

See http://foxyproxy.mozdev.org/drupal/content/217-dns-leakage#comment-3420

Comment 1

[Dave Garrett]

Bugzilla is generally not the place for bugs in non-Mozilla extensions.

We have a forum set up for bug reporting and other feedback:
http://flagfox.servehttp.com/forum/viewforum.php?f=3
A sticky on the topic:
http://flagfox.servehttp.com/forum/viewtopic.php?f=3&t=20

As to the specific complaint, this particular issue has always been a headache. The current Flagfox behavior should be to refuse to make its DNS request in the event that the nsIProxyInfo object returned for the URL in question has TRANSPARENT_PROXY_RESOLVES_HOST set in its flags. This implies (a) network.proxy.socks_remote_dns=true and (b) a SOCKS proxy capable of doing this. Near as I can tell, this is what it should be doing.
https://developer.mozilla.org/en/nsIProxyInfo

If you know more about this than me, by all means please enlighten me and I'll look into it. The current detection function in 3.3.20 is:

detectDNSProxy : function()  // Returns true if the current URL is set to have its DNS lookup proxied via SOCKS
{
    var uri = this.ios.newURI(flagState.url, null, null);
    var proxyinfo = this.proxy.resolve(uri, 0);  // Finds proxy (shouldn't block thread; we already did this lookup to load the page)
    return (proxyinfo != null) && (proxyinfo.flags & proxyinfo.TRANSPARENT_PROXY_RESOLVES_HOST);
    // "network.proxy.socks_remote_dns" pref must be set to true for Firefox to set TRANSPARENT_PROXY_RESOLVES_HOST flag when applicable
},

The version in the current 3.4beta1 is essentially identical, except for naming and it takes the URL as a parameter instead.

Comment 2

[Dave Garrett]

Oh, and this.proxy in comment 1 is nsIProtocolProxyService.
https://developer.mozilla.org/en/nsIProtocolProxyService

In the event that this function returns true, you should get an info bar with a message and the flag icon should change to a generic globe (blue-green blob, really). The info bar has a "Don't show this again" checkbox to avoid seeing the info bar again, but there is no pref to disable automatic disabling when it's detected. (info bar prefs can be reset via the "Reset Messages" link in the Flagfox Options dialog) Last I tested this does work, but again, I'm no expert on the intricacies of proxy configurations.

Comment 3

[Eric Jung [:ericjung]]

(In reply to comment #1)
> Bugzilla is generally not the place for bugs in non-Mozilla extensions.

Yep, I know that. But seeing as you so kindly assigned bug 540984 to me instead of closing it, I thought I'd do you a similar favor by opening this bug :)

> detectDNSProxy : function()  // Returns true if the current URL is set to have
> its DNS lookup proxied via SOCKS
> {
>     var uri = this.ios.newURI(flagState.url, null, null);
>     var proxyinfo = this.proxy.resolve(uri, 0);  // Finds proxy (shouldn't
> block thread; we already did this lookup to load the page)
>     return (proxyinfo != null) && (proxyinfo.flags &
> proxyinfo.TRANSPARENT_PROXY_RESOLVES_HOST);
>     // "network.proxy.socks_remote_dns" pref must be set to true for Firefox to
> set TRANSPARENT_PROXY_RESOLVES_HOST flag when applicable

That comment isn't completely accurate, especially when it comes to extensions like FoxyProxy. Extensions can hook all URL loading and completely ignore the value of network.proxy.socks_remote_dns. With FoxyProxy installed, your call to this.proxy.resolve() will be answered by FoxyProxy, not Firefox. But since you don't actually use the value of the network.proxy.socks_remote_dn pref in your function, no harm done. Just don't change your code to:

return (proxyinfo != null) && (proxyinfo.flags & proxyinfo.TRANSPARENT_PROXY_RESOLVES_HOST) && (pref network.proxy.socks_remote_dns is false)

> If you know more about this than me, by all means please enlighten me and I'll
> look into it.

It looks good to me.

I fired up Wireshark and tried to get Flagfox to leak a DNS request. I could not reproduce the problem reported by the poster at http://foxyproxy.mozdev.org/drupal/content/217-dns-leakage#comment-3420. I set FoxyProxy use remote DNS lookups, pointed it to a SOCKS5 proxy, then used Flagfox. No leaks... but also no flags, just the generic globe.

Marking WORKSFORME.

Comment 4

[Dave Garrett]

(In reply to comment #3)
> > If you know more about this than me, by all means please enlighten me and I'll
> > look into it.
> 
> It looks good to me.
> 
> I fired up Wireshark and tried to get Flagfox to leak a DNS request. I could
> not reproduce the problem reported by the poster at
> http://foxyproxy.mozdev.org/drupal/content/217-dns-leakage#comment-3420. I set
> FoxyProxy use remote DNS lookups, pointed it to a SOCKS5 proxy, then used
> Flagfox. No leaks... but also no flags, just the generic globe.
> 
> Marking WORKSFORME.

That's good to hear. It's possible there's a misconfiguration on the initial reporter's end somewhere. One possibility I listed in the Proxy/DNS FAQ I linked to: "You must be using only a SOCKS proxy, and no HTTP proxy, for Firefox to correctly tell everything to not do local DNS lookups." However, I don't know if that still applies with FoxyProxy installed.

While the subject is up, I don't suppose you know of any way to look up an IP through a SOCKS proxy? (without needing any kind of external service) Would be nice if there was just a way to easily fetch the IP from behind a proxy instead. Near as I can tell there isn't, but you may be the best person to ask. ;)

Comment 5

[Dave Garrett]

Another possibility is that the initial reporter is using a really really old version of Flagfox. All of the following use the detection method above:
Flagfox 3.4beta1 - current beta version
Flagfox 3.3.20   - current stable version (last to support Firefox 2)
Flagfox 3.2.8    - last version to support Firefox 1.5

3.2.2 - 3.2.5 didn't check the proxyinfo flag and disabled too often. 3.2.1 and older had bad detection altogether. If you do find someone using one of these year and a half old versions, please tell them to update ASAP.

Comment 6

[Eric Jung [:ericjung]]

(In reply to comment #4)
> One possibility I listed in the Proxy/DNS FAQ I
> linked to: "You must be using only a SOCKS proxy, and no HTTP proxy, for
> Firefox to correctly tell everything to not do local DNS lookups." However, I
> don't know if that still applies with FoxyProxy installed.

You are correct that only SOCKS 4a and SOCKS5 proxies can perform DNS lookups. SOCKS 4 and HTTP proxies cannot. With FoxyProxy, the user can have both types of proxies in use at the same time, but it's not worth going into these details on your FAQ.

> While the subject is up, I don't suppose you know of any way to look up an IP
> through a SOCKS proxy? (without needing any kind of external service) Would be
> nice if there was just a way to easily fetch the IP from behind a proxy
> instead. Near as I can tell there isn't, but you may be the best person to ask.
> ;)


Not without implementing your own SOCKS 4a or 5 client within your extension (which is certainly possible as a C++ component). You might also play with the nsIDNSService interface. I'm not sure if its resolve() and asyncResolve() methods make use of the configured proxy, but it would be easy for me to determine. Let me know if you'd like me to do that.

Comment 7

[Dave Garrett]

(In reply to comment #6)
> > While the subject is up, I don't suppose you know of any way to look up an IP
> > through a SOCKS proxy? (without needing any kind of external service)
> 
> Not without implementing your own SOCKS 4a or 5 client within your extension
> (which is certainly possible as a C++ component).

I'm not really willing to resort to compiled components in Flagfox.

> You might also play with the nsIDNSService interface. I'm not sure if
> its resolve() and asyncResolve() methods make use of the configured proxy,

nsIDNSService.asyncResolve() is what I'm using right now, and unless I'm missing something it can't resolve through a proxy.

For now, I'm fine with just no flag in this instance. It should work fine with other proxies if you're also using DNS, and after version 3.4 there will be much more that works behind a proxy (just no flag).

If you have any more info or questions on the subject you can email me directly to discuss further.