Hi,
Arturo and I have discussed a possible petname system for tor2web that would make it simple to remember hidden service names; it's not perfect, it's not secure and it requires comment from the community. The basic idea is to make it easy to deploy and see if anyone cares to use it.
Here's the proposal in url form: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-oni...
Here's the proposal as text: Filename: xxx-onion-nyms.txt Title: .onion nym system Author: Arturo Filastò, Jacob Appelbaum Created: 17 December 2011 Status: Draft
1. Intro and Motivation
The main issue that prohibits the wide scale adoption of .onion addressing is the fact that they are not human memorable. While Zooko's triangle says that you can only have at most two of "memorable", "secure" and "global" it is possible to build a simple nym mechanism that relies on the current .onion addressing system. We define a basic registration system generally and also it's particual application to the tor2web network. This is a very simple kind of petname system for applications such as tor2web.
2. Definitions
These are the definitions of the actors involved in the process.
Beppe - The owner of the Tor Hidden Service User - A random user of Tor/tor2web v2cbb2l4lsnpio4q.onion - The .onion address that Beppe is interested in registering antani - The nym Beppe is interested in associating to v2cbb2l4lsnpio4q.onion t2w - A tor2web node
3. Registration
This is the process through which Beppe is able to make a registration for his chosen nym.
3.1 General implementation
Beppe wishes to register "antani" to point to v2cbb2l4lsnpio4q.onion so he creates a a TCP service listening on his .onion will respond with the string "reg antani" when interrogated. The requester will make a lookup in his database to see if "antani" is already registered. If it is not registered the "antani" <-> v2cbb2l4lsnpio4q.onion mapping is created. A timestamp is added to the database.
3.2 Tor2web implementation
Beppe creates a file called "onion.txt" containing the string "reg antani" and uploads it to the root of his web server. When User visits v2cbb2l4lsnpio4q.tor2web.org the t2w checks if his database contains a mapping with v2cbb2l4lsnpio4q.onion, if it does not, it requests the http://v2cbb2l4lsnpio4q.onion/onion.txt file. If the file exists t2w reads it and extracts the "antani" string. A lookup is made in his database. If "antani" is not registered he creates a mapping between "antani" and v2cbb2l4lsnpio4q.onion. A timestamp is added to the database.
4. Expiration
A nym will expire if either the HS goes offline for longer than a given time threshold or if he explicitly requests removal of the association to that particualr nym. This allows dynamic reallocation of nyms and avoids nym squatting.
4.1 Time delay
We define the default tiem threshold to be 30 days since the last check. At the time of expiry or anytime before, another request is made to either the TCP service or for the "onion.txt" file. If the Hidden Service is offline or if the requested mapping has changed the mapping is removed or modified. If the onion.txt is unchanged, the nym remains valid and the database timestamp entry is updated.
4.2 Release
The HS can specify the "release" string to delete the entry from the nym database.
5. Synchronization
To keep the database of registered nyms up to date in for many t2w nodes, a synchronization mechanism is required but currently out of scope for this document.
All the best, Jacob
Hi Jacob
On 17 Dec 2011, at 01:14, Jacob Appelbaum wrote:
A nym will expire if either the HS goes offline for longer than a given time threshold or if he explicitly requests removal of the association to that particualr nym. This allows dynamic reallocation of nyms and avoids nym squatting.
This may be stating the obvious, but a problem here is someone could DoS the hidden service for sufficiently long they could steal the nym. If the attacker is smart, they will only do the DoS when the nym authority is checking (which suggests the nym authority should check at random intervals).
Alternatively, the attacker could hack the hidden service and publish a release request. It would be nice if it were easy to run a hidden service with no security vulnerabilities but that is not going to be the case any time soon.
One fix to the DoS problem is to permanently bind a nym to an onion address, but as you point out allows nym squatiting and other badness. This however does not help if the attacker has hacked the hidden service and obtained its private key.
A potential fix to the hacking vulnerability is to bind the nym to a key ID, where the private key can be kept offline. If the attacker hacks the hidden service and obtains the hidden service private key the legitimate nym owner can recover by publishing a new binding request with the same key ID, but signing the request with a higher serial number than before.
However, this massively complicates what was otherwise a relatively simple proposal, and gives marginal benefit in what I expect to be the common case: where the nym binding private key would be stored online and thus precisely as vulnerable to compromise as the hidden service key.
Steven.
hello, I'm new to the list (and to tor development), so I introduce myself. I mostly subscribed because I'm seriously considering to apply for google summer of code with torproject :) I'm especially interested to the "petname" problem, I'll write more below
Steven Murdoch wrote:
On 17 Dec 2011, at 01:14, Jacob Appelbaum wrote:
A nym will expire if either the HS goes offline for longer than a given time threshold or if he explicitly requests removal of the association to that particualr nym. This allows dynamic reallocation of nyms and avoids nym squatting.
This may be stating the obvious, but a problem here is someone could DoS the hidden service for sufficiently long they could steal the nym. If the attacker is smart, they will only do the DoS when the nym authority is checking (which suggests the nym authority should check at random intervals).
that's of course one of the biggest problem to face; the other is the single-point-of-failure issue. Why don't we make the other way around? That is, Beppe itself will periodically send a signed message to such an "authority" stating the petnames he wants to be associated to. This could also been sent by means that are not reachable for the attacker (for example, in case of a serious attack, Beppe could just sent this message manually with an email from a different computer)
Then I'd like to ask about the extent of such a project for GSoC. I'm really interested in doing this because I really like the concept of darknet and the "petnames" will really make them reasonably easy to use. However, it's easy to see the limits of this: single point of failure, which is both a problem for crashes AND censorship/security (what if the central authority start censor nyms? or worst, providing false associations). I suppose that a GSoC student can't solve all this problems alone :)
So, how much is "enough"? Of course, I really intend to continue my work/research about this, but when talking about jobs, allocating time is really important.
Greetings
On Fri, 16 Dec 2011 17:14:52 -0800, jacob at appelbaum.net (Jacob Appelbaum) said:
ioerror> Beppe wishes to register "antani" to point to ioerror> v2cbb2l4lsnpio4q.onion so he creates a a TCP service ioerror> listening on his .onion will respond with the string "reg ioerror> antani" when interrogated.
Ok, so far so good.
ioerror> 3.2 Tor2web implementation
ioerror> Beppe creates a file called "onion.txt" containing the ioerror> string "reg antani" and uploads it to the root of his web ioerror> server. When User visits v2cbb2l4lsnpio4q.tor2web.org the ioerror> t2w checks if his database contains a mapping with ioerror> v2cbb2l4lsnpio4q.onion, if it does not, it requests the ioerror> http://v2cbb2l4lsnpio4q.onion/onion.txt file.
This would appear to either introduce a single point of failure, the tor2web service, or a race condition leading to differing mappings if there is more than one such service.
What if instead, we used a similar mechanism as we already have for the hidden services and do say hash("antani").nym and push that out to the introduction hosts. The introduction hosts would check if they can resolve it, if they can, the request is rejected, if they cannot then they keep the mapping (careful implementation to avoid race conditions here). Have an cache+expiry mechanism from there so the mapping isn't trivially lost when the hidden host goes offline.
The requester just computes hash("antani").nym and goes to find that hidden service in the normal way.
The only difference from the existing hidden service is that in this case the secret behind the hash, "antani" is publicised.
An added benefit is that only the requestor and the operator of the hidden service can know the nym a priori, the introduction servers don't know what nyms they are providing introductions for.
Does this make any sense?
Cheers, -w -- William Waites wwaites@tardis.ed.ac.uk Visiting Researcher, Laboratory for Foundations of Computer Science School of Informatics, University of Edinburgh
On 02/01/12 10:59, William Waites wrote:
What if instead, we used a similar mechanism as we already have for the hidden services and do say hash("antani").nym and push that out to the introduction hosts. The introduction hosts would check if they can resolve it, if they can, the request is rejected, if they cannot then they keep the mapping (careful implementation to avoid race conditions here). Have an cache+expiry mechanism from there so the mapping isn't trivially lost when the hidden host goes offline.
If I'm understanding you correctly...
Let's say Mallory discovers a scripting error and exploits it to fork-bomb Alice's service. It has insufficient resources to keep the hidden service online but still responds to pings and even manages to serve an occasional static page on a non-hidden address, fooling Alice's home-grown monitoring solution. Alice of course notices the problem when she manually checks the service, but she attributes the failures to something else, leaving Mallory free to keep trying. Eventually Alice takes a vacation and Mallory is successful at keeping the service offline for $expiry_time. At this point the nym can be hijacked as no secret is needed to claim it.
Am I missing something?
Julian
On Tue, 03 Jan 2012 19:52:00 +0000, Julian Yon julian@yon.org.uk said:
jry> Eventually Alice takes a vacation and Mallory is jry> successful at keeping the service offline for $expiry_time. At jry> this point the nym can be hijacked as no secret is needed to jry> claim it.
Two things here.
Firstly, the advertisement of the nym with the introduction hosts would be signed with the hidden service's key, the pair (Hash("somenym"), Srv_PubKey) would be kept cached around the network allowing it to be reclaimed should the hidden service move around. Similarly, to flesh things out, a nym could be released or transferred with a similarly signed message.
Secondly, on the expiry, that idea was copied as I understood it from the original proposal, designed to mitigate nym squatting, and allowing nyms to be eventually recycled. I'm not necessarily convinced by it and haven't thought about this aspect very closely. A malicious nym squatter could trivially maintain lots of mappings directly anyways. And likewise a clever DOS designed to cause the registration to expire would make nym hijacking possible, and this is true, I think, wherever there is an expiry mechanism.
Cheers, -w -- William Waites wwaites@tardis.ed.ac.uk Visiting Researcher, Laboratory for Foundations of Computer Science School of Informatics, University of Edinburgh
-
boyska -
Jacob Appelbaum -
Julian Yon -
Steven Murdoch -
William Waites