Closed Bug 1741375 Opened 3 years ago Closed 2 months ago

Proxy DNS by default when using SOCKS v5

Categories

(Core :: Networking: Proxy, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
128 Branch
Tracking Status
relnote-firefox --- 128+
firefox123 --- wontfix
firefox128 --- fixed

People

(Reporter: Tom25519, Assigned: manuel)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, Whiteboard: [necko-triaged][necko-monitor])

Attachments

(5 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

I use a SOCKS5 proxy, but in https://browserleaks.com/dns , "Your DNS Servers" are located in my city, belongs to my ISP, and I found "Proxy DNS when using SOCKS v5" is not selected.

Actual results:

DNS traffic leaks when I using a SOCKS5 proxy.

Expected results:

Proxy DNS by default when using SOCKS v5 to prevent DNS traffic leaking.

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Networking: DNS
Product: Firefox → Core

I think someone from product team needs to take look at this feature request.
Greg, could you help to find the right one to ask? Thanks.

Flags: needinfo?(ghess)

We'll revisit this when updating networking preference page.

Severity: -- → N/A
Type: defect → enhancement
Flags: needinfo?(ghess)
Priority: -- → P3
Whiteboard: [necko-triaged]

In fact, we can simply set network.proxy.socks_remote_dns = true by default to achieving this.

Version: Firefox 91 → unspecified
Whiteboard: [necko-triaged] → [necko-triaged][necko-priority-review]

Greg, can you elaborate on why this was added to priority review? Thanks!

Flags: needinfo?(ghess)

We have verified that TOR sets network.proxy.socks_remote_dns = true by default. We feel this is the right way to go and will update Firefox to enable this by default when using SocksV5 proxy. Moving to necko-priority-next.

Flags: needinfo?(ghess)
Whiteboard: [necko-triaged][necko-priority-review] → [necko-triaged][necko-next]
Whiteboard: [necko-triaged][necko-next] → [necko-triaged][necko-priority-next]

For the common use case of SOCKSv5 for VPNs, Firefox should proxy DNS
request via SOCKs to not leak visited sites to the DNS server and also
reduce fingerprinting on which DNS resolvers was used to websites.

Mullvad also tells their users to enable proxying DNS in their
instructions on how to use SOCKS proxy.1

The DNS resolver gets to know which website we are connecting anyway. We
could use DNS over HTTPS on SOCKS proxies in the future to be able to
encrypt the hostname with ECH, but that is a project for the future. For
now we want to reduce leaks and therefore also use the SOCKS proxy when
available.

Assignee: nobody → manuel
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Just seeing now, that this is actually a duplicate of Bug 610896 and that there is an (already better patch) attached there. Depending whether it is still mergable, we could reuse that patch or I will update the test cases in my patch later.

See Also: → 610896
Attachment #9368649 - Attachment description: Bug 1741375 - Put SOCKSv5 proxy in charge of DNS resolution r=#necko → Bug 1741375 - Put SOCKSv5 proxy in charge of DNS resolution by default r=#necko
Attachment #9368649 - Attachment description: Bug 1741375 - Put SOCKSv5 proxy in charge of DNS resolution by default r=#necko → Bug 1741375 - Proxy DNS by default when using SOCKS v5 r=#necko
Whiteboard: [necko-triaged][necko-priority-next] → [necko-triaged][necko-priority-queue]
Pushed by mbucher@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/be64555d77f8
Proxy DNS by default when using SOCKS v5 r=necko-reviewers,valentin
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch
Duplicate of this bug: 610896

Could this patch uplift to ESR channel?

Could this patch uplift to ESR channel?

With this change, we default to SOCKSv4a instead of SOCKSv4. Therefore, we potentially break users of SOCKSv4 proxies by that don't support the SOCKSv4a extension. Existing users of SOCKSv4 proxies, that don't support SOCKS4a would need to disable the pref to continue having a working setup: 610896 comment 11 summarizes it quite good. I think we need to let it ride the release train and consider after February 20, 2024 when this gets released.

I'm not sure if we want to accept potential silent breakage of SOCKSv4 proxies that don't support 4a in an ESR dot release. I don't know how common SOCKSv4 is nowadays.

Due to the potential silent breakage & better defaults that were long requested, this might be good release notes candidate.

New plan is to create a new config option for dns over SOCKSv5. I'm going to back out the patch and reland without potentially breaking SOCKSv4 users. I only learned about the potential breakage when reading through Bug 610896 for closing as duplicate and discussed with the team on how to handle this best. This bugs continues to be about SOCKSv5, SOCKSv4 will be handled in another bug.

Status: RESOLVED → REOPENED
Keywords: leave-open
Resolution: FIXED → ---
Pushed by mbucher@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5661bc223a51
Backout "Proxy DNS by default when using SOCKS v5" due to potential breakage of SOCKSv4 proxy users r=jesup,necko-reviewers

Just for information, although uncommon, a use-case has been reported that has a conflict with "Proxy DNS by default when using SOCKS v5".

Per-proxy DNS Proxying

Yes. In my case I need to access specific hosts whose DNS entries are not public and only resolvable through a proxy. Then I happen to also have the inverse case where the DNS entries are public (but not published on the the "private DNS") and the URLs can only be accessed through the proxy. (It's weird, I know...).

Thanks for the info. This is a really weird use case 😅. I don't understand that setup completely yet. This patch is only about changing the defaults to make the proxy settings work more like users expect them to. It will still be possible to disable tunneling DNS requests via the proxy. Although, your addon code might need to adapt?

Although, your addon code might need to adapt?

That all depends on how proxy.onRequest behaves with the changes.

ATM, above API is fairly independent and Proxy DNS is set per-connection. Unless this behaviour is changed, there should not be any problems for the extension and the API.

See Also: 610896

Note to self: Noticing right now that this is also the intended behavior from the beginning: Proxy DNS over SOCKS5 and also enable it in SOCKS4 if enabled via pref.

https://searchfox.org/mozilla-central/rev/24ea2579c4a94d5da8db4bb529cbefe5e5e3c2d3/netwerk/base/nsProtocolProxyService.cpp#1253-1258

// If it's a SOCKS5 proxy, do name resolution on the server side.
// We could use this with SOCKS4a servers too, but they might not
// support it.
if (type == kProxyType_SOCKS || mSOCKSProxyRemoteDNS) {
  flags |= nsIProxyInfo::TRANSPARENT_PROXY_RESOLVES_HOST;
}

(In reply to Manuel Bucher [:manuel] from comment #21)

Note to self: Noticing right now that this is also the intended behavior from the beginning: Proxy DNS over SOCKS5 and also enable it in SOCKS4 if enabled via pref.

https://searchfox.org/mozilla-central/rev/24ea2579c4a94d5da8db4bb529cbefe5e5e3c2d3/netwerk/base/nsProtocolProxyService.cpp#1253-1258

// If it's a SOCKS5 proxy, do name resolution on the server side.
// We could use this with SOCKS4a servers too, but they might not
// support it.
if (type == kProxyType_SOCKS || mSOCKSProxyRemoteDNS) {
  flags |= nsIProxyInfo::TRANSPARENT_PROXY_RESOLVES_HOST;
}

It is only for PAC-configured proxy.
https://searchfox.org/mozilla-central/rev/24ea2579c4a94d5da8db4bb529cbefe5e5e3c2d3/netwerk/base/nsProtocolProxyService.cpp#2219-2220

    if (mSOCKSProxyRemoteDNS) {
      proxyFlags |= nsIProxyInfo::TRANSPARENT_PROXY_RESOLVES_HOST;

https://searchfox.org/mozilla-central/rev/24ea2579c4a94d5da8db4bb529cbefe5e5e3c2d3/netwerk/base/nsProtocolProxyService.cpp#2249

    if (mSOCKSProxyRemoteDNS) {
      proxyFlags |= nsIProxyInfo::TRANSPARENT_PROXY_RESOLVES_HOST;

The necko owner at that time decided that the local pref (network.proxy.socks_remote_dns) should not affect the PAC behavior. The decision is partially overturned thereafter. See bug 134105 comment 52 and following comments and bug 562289 for context.

Thanks for clearing that up. That is quite some reading material :). I understand the decision to not let the config affect PAC files, if there is the possibility in pac files to configure transparent name resolution.

What I don't understand currently is that we only disable speculative prefetch and dns-prefetch if the "network.proxy.socks_remote_dns" config is set. That seems to create inconsistent behavior depending on how the proxy was configured: netwerk/dns/DNSServiceBase.cpp#40-43,52-55

  • configured with pac -> speculative prefetch is allowed
  • configured with about:preferences -> speculative prefetch is not allowed.

Instead, we should look into the ProxyInfo flags to determine whether prefetch/dns-prefetch is allowed: like in netwerk/protocol/http/DnsAndConnectSocket.cpp#155

if (proxyInfo->Flags() & nsIProxyInfo::TRANSPARENT_PROXY_RESOLVES_HOST) {

That probably needs to be addressed in a separate bug. But that also affects my patch, because I want to split the config options into network.proxy.socks_remote_dns and network.proxy.socks_v5_remote_dns.

I think that for this bug, I'll ignore the inconsistency problem and will file another bug.

See Also: → 1879848

Landed telemetry. Will monitor and use for decision on landing the pref flip. My target to flip the pref is Nightly 126 (so one release after the telemetry landed).

Whiteboard: [necko-triaged][necko-priority-queue] → [necko-triaged][necko-monitor][reminder-pref 2024-03-18]

Moving bug to Core/Networking: Proxy.

Assignee: manuel → nobody
Component: Networking: DNS → Networking: Proxy
Blocks: 1882276

26 days ago, manuel placed a reminder on the bug using the whiteboard tag [reminder-pref 2024-03-18] .

kershaw, please refer to the original comment to better understand the reason for the reminder.

Flags: needinfo?(kershaw)
Whiteboard: [necko-triaged][necko-monitor][reminder-pref 2024-03-18] → [necko-triaged][necko-monitor]
Status: REOPENED → NEW
Flags: needinfo?(kershaw)

With the networking.proxy_info_type telemetry from Bug 1879848 I gather that we do have more socks4 usage than I expected. I expected basicly zero usage, but it's 0.66% (sock4 + socks4a) of total proxy usage in nightly+beta:

direct http https socks4 socks4a socks5 socks5h other
0.28% 62.60% 17.11% 0.53% 0.13% 3.34% 16.00 %
2024-04-04 736,539 164,131,633 37,198,737 1,200,279 210,474 7,729,615 33,327,049 0
2024-04-03 578,056 176,170,367 38,003,365 1,505,427 504,877 8,619,145 41,749,605 0
2024-04-02 608,137 157,363,580 43,610,731 2,147,936 325,876 8,294,888 39,399,846 0
2024-04-01 617,093 150,755,471 39,941,390 744,081 290,550 8,938,109 37,378,705 0
2024-03-31 589,889 95,058,040 33,353,420 1,133,902 259,874 5,924,287 27,800,352 0
2024-03-30 601,834 91,112,160 36,270,959 897,036 191,317 5,631,675 28,311,938 0
2024-03-29 599,895 128,362,639 36,120,180 938,712 142,368 6,683,240 38,045,565 0
2024-03-28 778,078 152,836,547 36,661,639 1,103,638 333,421 6,984,236 34,744,438 0
2024-03-27 918,814 147,175,253 31,760,139 1,295,381 248,634 8,630,765 37,892,892 0
2024-03-26 474,849 142,042,030 31,478,968 1,094,026 315,007 6,719,722 28,881,000 0
2024-03-25 389,146 115,584,449 36,044,777 1,146,690 299,714 6,046,438 29,658,012 0
2024-03-24 256,224 74,789,077 28,531,293 521,764 235,193 3,890,991 24,176,465 0
2024-03-23 307,625 64,783,921 24,861,834 448,912 167,892 4,615,269 22,940,612 0

Therefore, I'm continuing with the patch that only changes socks5 behavior, not socks4.

Attached image proxy-type-log.png
Attached image proxy-type-linear.png

Please note that as already mentioned in #necko:mozilla.org, resolving other issues related to the proxying, may (should) make Proxy DNS redundant.

When a proxy is involved in a connection, all target DNS queries must be left to the proxy server under all circumstances.

Initially reported and discussed in Bug 610896.

The simple solution of just flipping the pref network.proxy.socks_remote_dns
is risky due to potentially breaking SOCKS4 proxy users. Proxying
DNS on SOCKS4 isn't supported. Therefore when socks_remote_dns is
currently enabled we speak the incompatible SOCKS4a protocol potentially
breaking users setup.

To keep backwards compatibility on SOCKS4 proxies, the pref
network.proxy.socks_remote_dns is split into two prefs:

  • network.proxy.socks_remote_dns: remote DNS for SOCKS4
  • network.proxy.socks5_remote_dns: remote DNS for SOCKS5.

This way we proxy DNS by default on SOCKS5 while keeping user settings
on SOCKS4. This is a similar approach to the one described in
Bug 610896 comment 17.

Proxying DNS in SOCKS4 by default is desireable (See Bug 610896 comment 11),
but out of scope for this Patch. Telemetry on proxy usage by socks
version indicated that chaning the default for SOCKS4 is likely break
some users setup and needs to be taken with more care.

The default values of proxyDNS now defaults to true instead of false.
Setting proxyDNS still affects both SOCKS4 and SOCKS5 proxy by modifying
both socks_remote_dns and socks5_remote_dns. Therefore no extension
breakage is expected.

The enterprise policy can also modify the new pref
network.proxy.socks5_remote_dns.

Follow up bugs found while implementing:

  • Bug 1890542 - Also disable Prefetch non-manual configurations of socks
    proxy
  • Bug 1890554 - Use ProxyInfo::TRANSPARENT_PROXY_RESOLVES_HOST flag in
    nsHttpChannel::GetProxyDNSStrategy
  • Bug 1890549 - nsHttpChannel implementation DNS resolve strategy for
    proxies incomplete
Assignee: nobody → manuel
Status: NEW → ASSIGNED
See Also: → 1893670

I'm intending to land later today (Edit: next week. Will need to address conflict with D209875, will rebase after it is in m-c). Will need documentation change at proxyDNS https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/proxy/settings#proxydns

Current string: "Proxy DNS when using SOCKS5. Defaults to false."
This is wrong, correct would be "Proxy DNS when using SOCKS4 or SOCKS5. Defaults to false."

With this patch it needs to change further. Suggested documentation: "Proxy DNS when using a SOCKS proxy. Defaults to true when using SOCKS5, defaults to false when using SOCKS4."

Keywords: dev-doc-needed

(In reply to erosman from comment #30)

Please note that as already mentioned in #necko:mozilla.org, resolving other issues related to the proxying, may (should) make Proxy DNS redundant.

When a proxy is involved in a connection, all target DNS queries must be left to the proxy server under all circumstances.

I completely agree. I see what I can do in my spare cycles. I still see this as a good first step. Sorry for taking so long.

Pushed by mbucher@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8e1b6cb3fefb
Proxy DNS by default when using SOCKS v5 r=necko-reviewers,extension-reviewers,kershaw,perftest-reviewers,robwu,sparky

Not sure when dev-doc should be added. Needinfo for awareness due to this bug not being in WebExtensions component. See comment 32 for necessary doc changes.

Flags: needinfo?(rbloor)
Keywords: leave-open
Status: ASSIGNED → RESOLVED
Closed: 7 months ago2 months ago
Resolution: --- → FIXED

Thanks for the heads up, MDN content changes are ready for review in # Proxy DNS SOCKS defaults #33708

Flags: needinfo?(rbloor) → needinfo?(manuel)
Target Milestone: 123 Branch → 128 Branch

Release Note Request
[Why is this notable]: This is a long anticipated change of us having bad defaults leaking DNS requests to network when using a SOCKS5 proxy.

[Affects Firefox for Android]: Technically yes, but not really. VPNs are configured differently there.
[Suggested wording (feel free to improve)]: Firefox now proxies DNS by default when using SOCKS v5 avoiding leaking DNS queries to the network when using SOCKS v5 proxies.
[Links (documentation, blog post, etc)]:

relnote-firefox: --- → ?
Flags: needinfo?(manuel)

Added to the Fx128 relnotes. I also added a reminder to our internal relnotes doc to call this out in the ESR128 relnotes per comment 13.

Note that the approach from comment 13 was backed out. The patch that landed now took a more careful approach (see comment 14) to not break any users setup.

Out of curiosity, how does the change affect the UI in Settings -> Network Settings?

It now configures only SOCKS v5 by toggling the preference network.proxy.socks5_remote_dns (like the labels says: "Proxy DNS when using SOCKS v5"). I have a patch in Bug 1454850 that adds a checkbox with the label "Proxy DNS when using SOCKS v4". It's not the most user friendly, but it at least exposes the option again.

MDN content changes have been merged (Proxy DNS SOCKS defaults #33708)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: