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.