Obfuscated URLs?

[mogulguy at yahoo.com]

--- On Tue, 6/30/09, Martin Fick <mogulguy at yahoo.com> wrote:
 
> --- On Tue, 6/30/09, Karsten Loesing <karsten.loesing at gmx.net>
> wrote:
> > 
> > On 06/30/2009 08:47 PM, Martin Fick wrote:
> > > Would it be possible to create a URL or some longer
> > > string that describes a hidden path through the tor 
> > > network to a specific hidden URL and to implement a 
> > > routing mechanism to access documents (files) using 
> > > this "Obfuscated URL"?
...
> > - - What you describe as obfuscated URLs sounds a lot like
> > precursor designs of hidden services. For example, encoding 
> > a path into the locator works only as long all nodes in 
> > that path are functional. Hidden services (and other 
> > designs) have directory services to overcome that
> > problem. Why make a step backwards?
> 
...
> Agreed, a single path encoding is a weak point, but this
> may be acceptable in some cases.  Also, other mechanisms
> could eventually be built on top of this mechanism to 
> replicate a document to several places and provide 
> several obfuscated URLs to the same content.  This 
> suddenly makes this content much less vulnerable to 
> single points of failure than a hidden service, 
> hopefully. :)


Mappings:
---------

It is not inconceivable that an .onion to Obfuscated 
URL mapping mechanism similar to hidden services 
could be managed within directory servers also.  
Granted, this may cause a scalability problem in the 
directory servers much earlier than the hidden 
service mechanism will since we are talking about 
separate mappings for each URL instead of an entire 
host.  

Nevertheless, an application run by the publisher 
could conceivably register several Obfuscated URLs 
to a single .onion URL address (each mapping 
potentially to different real URLs).  These .onion 
URL addresses would be shorter URLs and since they 
would map to multiple obfuscated URLs, they would 
automatically provide a form of redundancy.

A ".onion URL address" to "obfuscated URL" mapping 
would also provide an update mechanism for the 
publisher.  The update might be used to simply 
move the content.  It might be used to layer a 
dynamic content system on top of the static one 
by updating to a new URL upon writing.  And, of 
course, it might also be used to react to downed 
(dependent) tor relays.  

This last feature should make the availability of 
a document just as good (likely better) than that 
of a hidden service since now the publisher only 
needs to monitor the availability of his 
documents (and provide potentially new paths to 
them) instead of serving them.  This 
"availability" monitoring is much less risky and 
demanding than hosting a hidden service, since it 
only requires polling periodically as opposed to 
maintaining a permanent net connection.


Obsolete Mappings:
------------------

One risk of such a mapping scheme is the filing 
of the directories with obsolete mapping 
entries.  Hidden services should not suffer 
from this since once a service goes off line, 
its entries will eventually be removed.  

Some automated internal tor mechanisms could 
be setup to maintain currency of these mappings, 
to weed out obsolete URLs.  If an obfuscated 
URL becomes no longer accessible after certain 
TTLs, it could be wiped form the list to deal 
with permanently downed relays or endpoints.  
Borrowing an idea from freenet, addresses 
themselves should have a TTL any if no one 
accesses them after a certain period of time, 
they could also be removed.  If the publisher 
drops off the face of the earth and no one 
cares to access the content, it will be 
obsoleted.

Updating Mappings:
------------------

In order for it to be possible to update .onion
URL addresses to new obfuscated URLs, some 
protection mechanisms would be required to 
prevent others from falsely updating the 
address.  

Two ideas spring to mind, both likely useful to 
implement: 

1) Allow a hash of the content of the address 
   to be specified by the publisher, and 

2) Allow the obfuscated URLs to be signed by 
   the publisher.

With the addition of a hashing verification 
mechanism for .onion addresses, the tor network
could assure to users that an obfuscated URL 
does indeed return the content represented by 
the .onion URL address.  Such a verification 
mechanism would in fact allow friendly users
to help mirror and maintain the obfuscated links
to the content since they could submit new
obfuscated links to the mapping and as long as
the content matches the hash, the mapping should
be accepted regardless of who submits it!
This is now a much bigger availability 
maintenance leap ahead of hidden services for 
static content since it potentially enlists
others.


The mapping signing would be more useful when
the content is expected to change and updates
to the tor network itself are not desired. 
This way, the content can be updated externally,
but path/obfuscated URL maintenance could 
still be done securely by the original 
publisher.


Many ideas here, some probably better than
others.  However, I hope that this helps 
illustrate what might eventually be possible 
with the obfuscated URL idea.

Cheerio,

-Martin