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

Comments

Projects
None yet
7 participants
@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

This comment has been minimized.

Member

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

This comment has been minimized.

mnot commented Nov 27, 2015

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

@bagder

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

patrikhson commented Nov 27, 2015

@MoSal

This comment has been minimized.

Contributor

MoSal commented Nov 27, 2015

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

@jay

This comment has been minimized.

Member

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

This comment has been minimized.

Member

bagder commented Dec 8, 2015

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

@bagder

This comment has been minimized.

Member

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

This comment has been minimized.

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.