Re: Browsers and .onion names

On 25 Nov 2015, at 21:29, Mark Nottingham <mnot@mnot.net> wrote:

> Now that we have RFC7686, there's a new requirement applicable to HTTP clients:
> 
> 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.
> 
> Is anyone aware of a browser that does this or plans to do so? 

I think this is a seriously ill-conceived RFC. It almost seems like it was written intentionally to sabotage Tor.

Right now today, without waiting for anyone else to do anything for you, you could write an nsswitch plugin for Linux (or equivalent on other platforms) and divert all .onion names to your name resolution plugin code, which would then implement the desired Tor name resolution. That way, at a stroke, virtually every app on the platform (apart from specialized diagnostic tools like ‘dig’) instantly gets .onion name capability.

This is exactly what we did in Bonjour for Windows in 2004. We didn’t write a doc telling every Windows application developer to change their code to support Multicast DNS, and then sit back and wait for that to happen. (We’d still be waiting.) We wrote a Windows NSP plugin to implement Multicast DNS, and at a stroke every Windows app then instantly had ‘.local’ name capability. And it worked for all apps -- ssh, file transfer, screen sharing, etc. -- not just web browsing. And you didn’t even have to install a different web browser to use it -- it worked with whatever web browser you were already using. And product instructions like the one below don’t tell customers to install some special app to use their product; you just make sure you have mDNS installed, and then continue using whatever web browser you were already using:

<http://rainforestautomation.com/wp-content/uploads/2015/06/EAGLE%20User%20Manual%202.2.2.pdf>

All of this happened without any app having to change. In fact, it was essential that apps did *not* change their name resolution code. That’s why the rules for ‘.local’ specifically say that apps should *not* treat them any differently from other names. If apps started treating ‘.local’ as different that would actually have broken the functionality we were trying to provide.

People in this discussion seem to be conflating DNS APIs with name resolution APIs. Typical general-purpose apps don’t use DNS APIs. They use name resolution APIs, like getaddrinfo(). When an app calls those APIs, the library code looks up names using Unicast DNS, Multicast DNS, the /etc/hosts file, YP, NIS+, NetInfo, and even NetBios, as appropriate, and returns the answer to the app. These APIs have *never* been DNS APIs. They are name resolution APIs. The gethostbyname routine got its answers from the /etc/hosts file before there even was a DNS. So, in a way, you could consider the DNS as one of the first interlopers on this API originally intended for accessing the /etc/hosts file, not the other way around.

By asking all apps to recognise and black-hole all ‘.onion’ names, the Tor people are shooting themselves in the foot and cutting off their ability to make a nsswitch plugin in the future that could make ‘.onion’ names more broadly useful.

I predict that in a year or two the Tor community will be back, saying, “Um... We broke ‘.onion’. We asked apps to treat it differently, and they did, and because of that, ‘.onion’ names don’t work any more. Can we have ‘.another-onion’ please?”

Stuart Cheshire

Received on Monday, 7 December 2015 21:20:42 UTC