Implement RFC 7686 (fail dns for .onion)

RESOLVED FIXED in Firefox 45

Status

()

--
enhancement
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: mnot, Assigned: mcmanus)

Tracking

({dev-doc-complete})

Trunk
mozilla45
dev-doc-complete
Points:
---

Firefox Tracking Flags

(firefox45 fixed, relnote-firefox 45+)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.2.7 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.7

Steps to reproduce:

Firefox sends DNS requests for hostnames with a .onion TLD. This leaks information about what the user is attempting to access, and violates this requirement of RFC7686:

"Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup."

I'd suggest a configuration flag for "look up .onion addresses" that defaults to "false", with an accompanying error page. You could tie it into SOCKS configuration, etc. but that's probably overkill for now.

Updated

3 years ago
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
Product: Firefox → Core
(Assignee)

Comment 1

3 years ago
its clear to me, but not clear to some other readers yet, that this is a RFE to support rfc 7686 - not a report of a defect in standards we do implement. 

It might be enough to just implement this at the DNS layer with nxdomain-equivalency, I'm not sure it needs a fully localized error page and advertisement for tor. patches welcome.
Severity: normal → enhancement
Component: Networking → Networking: DNS
Summary: Firefox leaks .onion hostnames in DNS → Implement RFC 7686 (fail dns for .onion)

Comment 2

3 years ago
(In reply to Patrick McManus [:mcmanus] from comment #1)
> its clear to me, but not clear to some other readers yet, that this is a RFE
> to support rfc 7686 - not a report of a defect in standards we do implement. 
> 
> It might be enough to just implement this at the DNS layer with
> nxdomain-equivalency, I'm not sure it needs a fully localized error page and
> advertisement for tor. patches welcome.

Hello there,

Tor developer here and heavily interested in this ticket! Let me know how we can help on our part :)

Implementing the DNS lookup blocking as part of the DNS code seems like a reasonable and engineer-friendly idea.

In the future, it would also be rad if users could be pointed to Tor so that they can view these links.
However, I understand that this is a non-trivial decision because of localization overhead and because it might look like an "advertisement" to Tor.

I will try to be monitoring this ticket :)

[BTW, we recently started a small thread in [tor-dev] discussing the ideal behavior for browsers like Firefox:
https://lists.torproject.org/pipermail/tor-dev/2015-November/009844.html
I don't think a conclusion was ever reached, but feel free to participate if you want. Or you can just reply here!]
(Assignee)

Comment 4

3 years ago
Attachment #8696664 - Flags: review?(valentin.gosu)
(Assignee)

Updated

3 years ago
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Comment on attachment 8696664 [details] [diff] [review]
create pref to allow blocking .onion at dns level rfc 7687

Review of attachment 8696664 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/dns/nsDNSService2.cpp
@@ +626,4 @@
>  
>          // Disable prefetching either by explicit preference or if a manual proxy is configured 
>          mDisablePrefetch = disablePrefetch || (proxyType == nsIProtocolProxyService::PROXYCONFIG_MANUAL);
> +        

nit: whitespace.

@@ +775,5 @@
>          return NS_ERROR_OFFLINE;
>  
>      nsCString hostname;
> +    nsresult rv = PreprocessHostname(localDomain, aHostname, idn, hostname);
> +    NS_ENSURE_SUCCESS(rv, rv);

nit: macro hides return statement

::: netwerk/test/unit/test_dns_service.js
@@ +65,5 @@
> +  } catch (e) {
> +    // it is ok for this negative test to fail fast
> +    do_check_true(true);
> +    do_test_3();
> +  }  

nit: trailing whitespace

@@ +77,2 @@
>    do_test_pending();
>  }

nit: Maybe register a cleanup function which resets the prefs, in case we change the defaults in the future.
Attachment #8696664 - Flags: review?(valentin.gosu) → review+
(Assignee)

Comment 6

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/625248e1115c3a8423d008e87e6f63728586234f
Bug 1228457 create pref to allow blocking .onion at dns level rfc 7687 r=valentin.gosu
(Assignee)

Comment 7

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/91c339686ee5a2eca5afcd30ee7363e89ccba923
Bug 1228457 - backout 625248e1115c broke e10s xpcshell test CLOSED TREE r=backout
(Assignee)

Comment 8

3 years ago
that was totally my bad push - read the tbpl in the wrong tab :( sorry.
(Assignee)

Updated

3 years ago
Attachment #8697665 - Flags: review+
(Assignee)

Updated

3 years ago
Attachment #8696664 - Attachment is obsolete: true
(Assignee)

Comment 11

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/cb59c073476446b2ebf006b450d9a17d1055315e
Bug 1228457 create pref to allow blocking .onion at dns level rfc 7687 r=valentin.gosu

Comment 12

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/cb59c0734764
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Added to the release notes using "Introduce a new preference (network.dns.blockDotOnion) to allow blocking .onion at the DNS level" as wording.
Some doc (dev or user) would be appreciated
relnote-firefox: --- → 45+
Keywords: dev-doc-needed
Doc added:
https://developer.mozilla.org/en-US/Firefox/Releases/46#Networking
Keywords: dev-doc-needed → dev-doc-complete
Is there a reason this was implemented as a preference? Is there any valid circumstance when a user would need .onion requests to resolve through DNS? (Tor itself doesn't work that way, does it?)
Flags: needinfo?(mcmanus)
(Assignee)

Comment 16

3 years ago
tor resolves names via socks so it isn't related.

this patch would break the lookup of "bacon.onion" for someone who had a nameserver configuration with a localdomain of cheeseburger.com and they might want the pref when trying to access bacon.onion.cheeseburger.com via the short name. due to the abstractions involved, we can't really tell what is fully qualified and what is not beyond the presence of a dot- though it would be a very extreme corner case (requiring a >= two level short name ending in .onion)

And in general, I think prefs that can disable new features is train friendly development style.
Flags: needinfo?(mcmanus)
(In reply to Sylvestre Ledru [:sylvestre] from comment #13)
> Added to the release notes using "Introduce a new preference
> (network.dns.blockDotOnion) to allow blocking .onion at the DNS level" as
> wording.

Please avoid using imperative language. You should rather start the note with "Introduced ...".

Sebastian

Comment 18

3 years ago
(In reply to Justin Dolske [:Dolske] from comment #15)
> Is there a reason this was implemented as a preference? Is there any valid
> circumstance when a user would need .onion requests to resolve through DNS?
> (Tor itself doesn't work that way, does it?)

You can use configure Tor to act as a transparent proxy for Hidden Services ( https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy ), although there are plenty of warnings against do so.

Updated

3 years ago
Depends on: 1294402
You need to log in before you can comment on or make changes to this bug.