Add proxy DNS option

[ww-9]

There is no "Send DNS through proxy" option, this way there is a DNS leak. Please consider adding it asap.

[bekh6ex]

It is enabled by default for Socks 4 and 5. Other types of proxies cannot do it. See proxyDNS parameter in JavaScript API.

[bekh6ex]

Code reference: https://github.com/bekh6ex/firefox-container-proxy/blob/master/src/store/Store.js#L38-L45

[nobody43]

Should be mentioned in the interface then.

[ww-9]

It is enabled by default for Socks 4 and 5.

May be it's enabled but it leaks, I see both my providers and proxy dns. You can verify this at any dns leak checker. It doesn't leak with foxyproxy but it leaks with this extension.

[bekh6ex]

@ww-9 I cannot reproduce it reliably. Can you describe how exactly do you test and which checker do you use?

When I do a clean test, I get no leak. Used many DNS leak checkers.

[bekh6ex]

Since when are you using Container Proxy? Maybe there was a bug in the code some time ago and you have proxyDNS: false in the extension storage.

Can you try go to the proxy settings and save them again?

[bekh6ex]

@nobodysu The idea was to not bother users with technical details. Personally, I wouldn't care if there is a problem could have been present but solved. Although, if problem exists and user needs to take an action to solve it, notification is a MUST. (Hope you get my point 😄 )

Do you disagree?

BTW, can you also check if you have a DNS leak?

[bekh6ex]

Hm... I get DNS leak on my Linux machine, but not on Mac. FF version 75 on both.

[ww-9]

Finally I've found the cause. When uBlock Origin is enabled it leaks, when it's not - no leak.

[bekh6ex]

@ww-9 It is kind of true. I also notice occasional DNS leak, but cannot reproduce it with clean install.

[bug-repport]

On Win I do not observe leaks, everything is correct! Great addons! Thanks dude!

[ww-9]

will there be a fix?

[bekh6ex]

Sorry didn't have time lately to get back to this issue due to some COVID related things going on.

Although, I forgot to share some findings that I have:

1. Stil cannot reproduce the leak from a clean state, but figured out that it is not a simple bug in the code. Each time the request is made from the checker page in container proxy settings provided by the extension are corect (i.e. proxy DNS flag is set to true).
2. Disabling uBlock doesn't help the leak. Sometimes, when the leak is already present disabling uBlock on the page will refresh it and the leak will disappear. (Didn't try to uninstall uBlock so far, might be still relevant).
3. Sometimes, after cleaning cookies and local storage the leak disappears (but not always).
4. Changing the proxy for leaking container might fix the leak as well. (tried this once only and it helped)

NOTE: Used https://dnsleak.com

@ww-9 If you can share some results of your experiments that would be really helpful, because my curent assumption that it's either related to some other extension or there might be some tricky/unobvious Firefox behaviour that I'm not aware of which makes approach of Continer Proxy not robust enough to protect against it. Or maybe there is a bug in Firefox...

[ww-9]

@bekh6ex I confirm that it is not an obvious bug, and it’s quite difficult to figure out a pattern, however my steps to reproduce:

1. Install uBlock and this extension
2. Pin 2 tabs in firefox (ex. youtube and amazon)
3. Restart the browser

When either there are no pinned tabs after the restart or uBlock is disabled there is no leak.

[bekh6ex]

Cannot reproduce it on macOS 10.15.4 (Firefox version 76.0.1).

@ww-9 Which OS and Firefox do you have?

Also, how do you open these tabs? In container with proxy set up or in the default one?

[ww-9]

Windows 10, the same Firefox version. These pinned tabs in the default one.

Have you tried https://browserleaks.com/dns ?

[bekh6ex]

I still cannot reproduce DNS leak from a clean state, but I get it from time to time (checked it several times while working during the day).

Thinking about the cause, there is a core problem with the approach: Extensions consist of different types of scripts (e.g. background script, popup script) that are being executed in the default container. If they send requests they will inherit Firefox Container Proxy settings for default container which is probably be set to Directly (i.e. without proxying). 3rd party extension can decide to extract some links to resources from the open page and "explore" them for whatever reason. In this case DNS leak might happen.

The only way to mitigate such issues is to set up proxy in Firefox settings so that EVERY request is proxied. Using extensions that let user to match proxy by domain name has the same problem because when proxy will get matched for matching-domain.com it won't get matched for xxx.dns-leak-service.net which might be added to the page in order to find out real user IP.

[sellibitze]

I have the same problem. A DNS leak test fails. Somehow, when I globally configure a SOCKS5 proxy, using Firefox' network settings with the "pass DNS requests through the proxy" option checked, I see no DNS leak. But when I'm on a containered tab with proxy settings controlled by this extension the DNS leak test fails (in that I see requests coming from my IP instead as well as the SOCKS proxy).

I just checked, about:config still shows network.proxy.socks_remote_dns is set as true.

When I disable all extensions (all but multi-account containers + container proxy), the DNS leak test succeeds. So, it appears as if the proxy settings made by the container proxy extension don't apply to requests made by other extensions even though they "belong" to the same containered tab.

I was able to reenable all but the uBlock Origin extension and it still workd. Then, reenabling uBlock will make the DNS test fail again.

According to a uBO developer (see old reddit thread) uBO uses the dns.resolve() API which makes Firefox perform some kind of DNS request that isn't even linked to any TCP connection. So, it's not surprizing that this would leak. This may be related to this uBO feature. So, in order to get rid of some DNS-related trackers, uBO checks whether some innocent-looking domain name is actually an alias (CNAME) for some tracker company's owned domain.

BTW: It's possible to disable this uBO feature. It's called cnameUncloak and can be set to false in the expert settings of the extension. Personally, I find this acceptable as a temporary solution.

But what I find puzzling is that if the proxy settings are done manually in Firefox' settings I don't see any leak. So, somehow, it's possible for uBO to do a dns.resolve and still have no leak show up via Mullvad's leak test.

Weird.

[bekh6ex]

Thanks for the research! Regarding the puzzling part: I see it as expected. When you set up proxy in Firefox settings it is being used for all requests comming from Firefox (TCP, DNS, extensions, etc). When it is not set up, then the requests comming from the default container are not proxied and are sent directly, hence the leak.

[nobody43]

Please bring up the setting to choose whether proxy DNS or not. Not all socks have DNS-server capability.

[bekh6ex]

I expect to add this feature in the next days.

Regarding the DNS leak, I think it can be solved by using DNS over HTTPS.

[bekh6ex]

The feature is released. Update to 0.1.22

[xuhcc]

BTW: It's possible to disable this uBO feature. It's called cnameUncloak and can be set to false in the expert settings of the extension.

cnameUncloak setting is now located on a basic settings screen where it is called "Uncloak canonical names"