--- On Tue, 6/30/09, Martin Fick <mogul...@yahoo.com> wrote: > --- On Tue, 6/30/09, Karsten Loesing <karsten.loes...@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