Closed Bug 1228457 Opened 9 years ago Closed 8 years ago

Implement RFC 7686 (fail dns for .onion)

Categories

(Core :: Networking: DNS, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox45 --- fixed
relnote-firefox --- 45+

People

(Reporter: mnot, Assigned: mcmanus)

References

Details

(Keywords: dev-doc-complete)

Attachments

(2 files, 1 obsolete file)

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.
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
Product: Firefox → Core
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)
(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!]
Attachment #8696664 - Flags: review?(valentin.gosu)
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+
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
https://hg.mozilla.org/integration/mozilla-inbound/rev/91c339686ee5a2eca5afcd30ee7363e89ccba923
Bug 1228457 - backout 625248e1115c broke e10s xpcshell test CLOSED TREE r=backout
that was totally my bad push - read the tbpl in the wrong tab :( sorry.
Attachment #8697665 - Flags: review+
Attachment #8696664 - Attachment is obsolete: true
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
https://hg.mozilla.org/mozilla-central/rev/cb59c0734764
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
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
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)
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
(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.
Depends on: 1294402
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: