[tor-dev] Proposal 274: A Name System API for Tor Onion Services

[David Fifield]

On Fri, Oct 07, 2016 at 04:06:51PM -0400, George Kadianakis wrote:
>    In particular, onion addresses are currently composed of 16 random base32
>    characters, and they look like this:
> 
>                       3g2upl4pq6kufc4m.onion
>                       vwakviie2ienjx7t.onion
>                       idnxcnkne4qt76tg.onion
>                       vwakviie2ienjx6t.onion

Is there any meaning intended by the near-collision in the 2nd and 4th
addresses?

>    If all plugins fail to successfuly perform the name resolution, Tor SHOULD
>    default to using the exit node for name resolution.
>    XXX or not?  because of leaks?

It would be really nice if it were possible for the browser to show some
kind of UI indication that a name I type into the URL bar is going to be
handled specially. Even now, the URL bar is magical: if you typo a DNS
name, the browser does a web search and leaks whatever you just typed. I
think in the protocol as proposed, there's no way for the browser to
predict whether a name will be looked up in a special way using a
plugin, or even to learn what the mapping was after it has occurred.

How do you think this will interact with attacker-controlled names in
HTML? Let's say someone has a local petname database where
"bank.petname" points to the onion site of their bank. What happens when
HTML says
	<img src="http://bank.petname/favicon.ico">
Will it show the icon of the user's bank, whatever bank it happens to
be? I guess my question is if attackers are allowed to query the user's
local naming setup, even in an indirect way, or does the magic only
happen for names that are typed directly into the URL bar? (Because the
mapping happens below the SOCKS layer, I guess it could not apply only
to the URL bar.)

>    Hence, the contribution of this proposal is a modular Name System API
>    (NSA)

This acronym might cause confusion :)

>        |                                    $~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~$
>        |  1.                                $          4. GNS magic!!              $
>        |  User: SOCKS CONNECT to            $ debian.zkey -> sejnfjrq6szgca7v.onion$
>        |        http://debian.zkey/         $~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~$~~~~~~~$
>        |                                                                   $
>  +-----|-----------------------------------------+                         $
>  |+----v-----+     2.                 +---------+|       3.                $
>  ||Tor       |     debian.zkey        |Tor      ||       debian.zkey     +-$-------+
>  ||Networking------------------------->Naming   ------------------------->         |
>  ||Submodule |                        |Submodule||  Tor Name System API  |  GNS    |
>  ||          <-------------------------         <-------------------------  wrapper|
>  ||          | 6.                     |         ||5.                     |         |
>  |+----|-----+ sejnfjrq6szgca7v.onion +---------+|sejnfjrq6szgca7v.onion +---------+
>  +-----|-----------------------------------------+
>        |  7.
>        |  Tor: Connect to
>        |       http://sejnfjrq6szgca7v.onion/
>        v

So here, the browser thinks it is connecting to debian.zkey (the URL bar
says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion
in the background. What name does the browser put in its Host header? It
can't be the onion name, because there's no feedback from the naming
module back to the user application layer. It must be "debian.zkey"
then. If that is a petname, then it just got leaked to the server. I can
imagine this might also cause a problem with some virtual hosting setups
(though I suppose those are not very common for onion services). If the
user uses HTTPS, e.g. https://facebook.zkey/, then they'll get a TLS
name mismatch error, even if https://facebookcorewwwi.onion/ exists and
has a valid certificate--so using the naming system is not a transparent
replacement for memorizing the onion address. Maybe non-HTTP protocols
will also have problems.

It would be nice if there were some standard external way to just do a
name→onion query. As specified, there's no easy way for e.g. the browser
to query how a name will be mapped, short of launching its own instance
of the GNS wrapper and communicating with the over the Name System API.
I wonder, perhaps there's a way to extend the Tor RESOLVE cell to
support this feature? So you could do, for example
	$ tor-resolve debian.zkey
	sejnfjrq6szgca7v.onion

>    When launching name plugins, Tor sets various environment variables to pass
>    data to the name plugin (e.g. NS API version, state directory, etc.). More
>    information on the environment variables at [INITENVVARS].
> 
>    After a name plugin initializes and parses all needed environment
>    variables, it communicates with Tor using its stdin/stdout.

I worry that repeating the envvar and stdin/stdout design of the PT spec
will cause problems for platforms that aren't Tor on the desktop.
Whenever I talk to anyone about the PT spec, these are their primary
complaints. Mobile platforms, for example, may not allow subprocesses,
and may not have equivalents to envvars and stdin/stdout. Maybe it's not
such a big problem, if, unlike the PT spec, the Name System API is not
intended to be adopted by non-Tor projects. But I'm curious about what
developers of Orbot and Tor for iOS will say about the feasibility of
implementing this protocol.

> 3.2. Name plugins handling all tlds '*'
> 
>    In [TORRC], we assigned a single tld to each name plugin.  Should we also
>    accept catch-all tlds using '*'? I'm afraid that this way a name system
>    could try to resolve even normal domains like reddit.com .

That might be a good feature. It would provide a way to implement an
"Onion Everywhere" system, where you have a local database of onion
names that correspond to ordinary DNS names.

On the other hand, maybe a better way to implement "Onion Everywhere" is
as a browser extension, like HTTPS Everywhere, because if the name
mapping happens at a low layer inside Tor, there's no way for the
browser to get feedback.