Curl leaks .onion hostnames in DNS

[mnot]

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.

[jay]

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]

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

[bagder]

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]

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]

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]

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]

The big camel in the tent is the ugly search path issue in resolvers. We should have killed that feature in the DNS resolution algorithm tens of years ago. Patrik

[MoSal]

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

[jay]

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]

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

[bagder]

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

[0xBADCODE]

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).