User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20170419042421 Steps to reproduce: first tried with a clean profile of the Firefox and used remotedns with tor and privoxy on debian Linux. After that I saw connections trying to be established via an app called opensnitch installed self-destructing cookies and user agent spoffer to quicker toggle the settings for the safe browsing link prefetching and dns prefetching. disabled all that and the issue still appears. Firefox-esr wants to connect to my dns servers setup in the /etc/resolve.conf and do not respect remote resolution. however if I deny those connections it still do work perfectly fine with the remote dns resolving. The problem is that initially it tries to make a connection to local dns servers and only then to the remotedns servers which is not expected behavior. However the same issue do not exist in 53.0 beta edition. Actual results: attempt of dns leaks that shouldn't be possible with the network.proxy.socks_remote_dns set as true Expected results: no leaks should be expected as this is so called Extended Support Release so many people on different distributions including debian or kali linux do relay on that package to be their default web browser package. If the leaks still happen there is no point in using TOR with firefox-esr releases.

Jason, this is TOR related and I'm not sure who of the team is responsible for either TOR related stuff or DNS, can you please find someone?

Does this issue exist in Firefox ESR 52? As I know, ESR 52 has a couple of enhancements for TOR.

cc Ethan who knows more about TOR related things for Firefox ESR 52.

According to bug 134105, the issue still happens in Firefox 46.0.1, and works well on below versions: - Firefox 47.0.1, 48.0.2 on Windows 10 x64 - Firefox 51.0a1 on OS X El Capitan

Arthur, you are working on Tor patches for 52 ESR. Could you help to investigate and verify this is not an issue in 52 ESR?

We have a patch to prevent that kind of thing happening as we got bitten by this kind of issue in the past. So, this is not a problem for Tor Browser based on ESR52. Alas, this patch is still needed. See, e.g.: https://trac.torproject.org/projects/tor/ticket/21611.

(In reply to Georg Koppen from comment #6) > We have a patch to prevent that kind of thing happening as we got bitten by > this kind of issue in the past. So, this is not a problem for Tor Browser > based on ESR52. Alas, this patch is still needed. See, e.g.: > https://trac.torproject.org/projects/tor/ticket/21611. Georg, thanks for your response. For the record, the real Tor patch is in https://trac.torproject.org/projects/tor/ticket/5741. It is being tracked on the Tor Uplift Tracker list, so we will implement that patch in Firefox in the near future.

Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Tor's patch ( https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=177e78923b3252a7442160486ec48252a6adb77a ) disallowing loading domains defined in `network.proxy.no_proxies_on` when `network.proxy.socks_remote_dns` is true. Will you fix this?

e.g. allow using non-socks DNS (torbrowser allows only remote dns when remote_dns option is true) on whitelisted in `network.proxy.no_proxies_on` domains.