Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Curl leaks .onion hostnames in DNS #543

Closed
mnot opened this issue Nov 27, 2015 · 12 comments
Closed

Curl leaks .onion hostnames in DNS #543

mnot opened this issue Nov 27, 2015 · 12 comments

Comments

@mnot
Copy link

@mnot mnot commented Nov 27, 2015

Curl 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 message. You could tie it into SOCKS configuration, etc. but that's probably overkill for now.

screen shot 2015-11-27 at 11 13 56 am

@jay
Copy link
Member

@jay jay commented Nov 27, 2015

It looks like you are referring specifically to section 2.2 from RFC7686.

   2.  Application Software: Applications (including proxies) that
       implement the Tor protocol MUST recognize .onion names as special
       by either accessing them directly or using a proxy (e.g., SOCKS
       [RFC1928]) to do so.  Applications that do not implement the Tor
       protocol SHOULD generate an error upon the use of .onion and
       SHOULD NOT perform a DNS lookup.

SHOULD NOT, so it's not a requirement but it's recommended. If any application that does not implement the Tor protocol does not perform .onion DNS lookups then wouldn't there be a break in the usage of Tor's transparent proxy mode?

@mnot
Copy link
Author

@mnot mnot commented Nov 27, 2015

SHOULD NOT is still a requirement; please have a read of RFC2119.

@bagder
Copy link
Member

@bagder bagder commented Nov 27, 2015

I find it peculiar that a new standard imposes restrictions on existing implementations that never claimed nor intended to support RFC7686. Tor users who're using curl are probably quite used to use the necessary SOCKS proxy anyway since curl doesn't support the Tor protocol natively, and when using the correct SOCKS type curl will not attempt to resolve the host name locally but will instead pass it on to the proxy.

I wouldn't mind adding support for RFC7686 in the sense that we can offer blocking of ".onion" names - probably even by default, but I don't think we should do it unconditionally since:

  1. it risks breaking existing applications that could could be using .onion in private environments
  2. we can't easily control when a DNS resolve is done as opposed to a local /etc/hosts lookup (and similar), and the spec doesn't forbid a local name lookup
  3. we don't know if the given name is a partial as opposed to a FQDN
@Lukasa
Copy link
Contributor

@Lukasa Lukasa commented Nov 27, 2015

Given the list of things @bagder just mentioned, shouldn't this bug actually be opened against the resolver? The resolver knows whether or not it's going to emit a DNS packet, and that's the point at which this lookup should fail. I don't see why this is curl's problem at all.

@bagder
Copy link
Member

@bagder bagder commented Nov 27, 2015

That's my gut reaction too, but the RFC clearly spells out "Application Software" separate from "Name Resolution APIs and Libraries" in section 2.

@Lukasa
Copy link
Contributor

@Lukasa Lukasa commented Nov 27, 2015

Hmm.

In that case, perhaps we should propose an erratum to the RFC? Because the number of applications using DNS has got to be in the millions, while the number of actual resolvers being used is far fewer. Seems like it's got to be easier to fix it both in the right place and in the place with fewer implementations, right?

@patrikhson
Copy link

@patrikhson patrikhson commented Nov 27, 2015

@MoSal
Copy link
Contributor

@MoSal MoSal commented Nov 27, 2015

Wouldn't this break socksify (and maybe torsocks) usage if this is implemented in the client?

@jay
Copy link
Member

@jay jay commented Nov 27, 2015

SHOULD NOT is still a requirement; please have a read of RFC2119.

Seems like semantics; if you are referring to it as a requirement level then by that measure they're all requirements. I meant it's not "REQUIRED" as in "SHOULD NOT" == "NOT RECOMMENDED".

@bagder
Copy link
Member

@bagder bagder commented Dec 8, 2015

".onion"-ignoring is being implemented for Firefox in bug 1228457

@bagder
Copy link
Member

@bagder bagder commented Jan 7, 2016

This is docs for Firefox's handling of this: https://developer.mozilla.org/en-US/Firefox/Releases/46#Networking

@0xBADCODE
Copy link

@0xBADCODE 0xBADCODE commented Sep 14, 2016

Isn't this fixed by using the --dns-server and --socks5 flags with curl? Compile curl with those options and point --dns-server at your Tor DNSPort (configure this in torrc file).

@lock lock bot locked as resolved and limited conversation to collaborators May 7, 2018
emilengler added a commit to emilengler/curl that referenced this issue Mar 28, 2020
DNS requests over such domains are not recommended,
currently it is possible to find out which onion domain
the user requested if he didn't used a proxy.

Fixes curl#543
emilengler added a commit to emilengler/curl that referenced this issue Mar 28, 2020
DNS requests over such domains are not recommended,
currently it is possible to find out which onion domain
the user requested if he didn't used a proxy.

Fixes curl#543
emilengler added a commit to emilengler/curl that referenced this issue Apr 6, 2020
DNS requests over such domains are not recommended,
currently it is possible to find out which onion domain
the user requested if he didn't used a proxy.

Fixes curl#543
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants
You can’t perform that action at this time.