Opened 4 years ago

Closed 3 years ago

#18759 closed enhancement (wontfix)

Extend onion address to include authentication data

Reported by: twim Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords: authenticated, hs, rendclient, address needs-proposal
Cc: dgoulet Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

At the moment using authenticated onion services is really painful for a client. One need to find torrc somewhere, add a line to it and restart tor. These requirements are making them effectively usable.

I got an idea to append authentication data directly to hostname. In order to avoid mixing with upcoming prop224 service ids there should be a separator. According to RFC 952 is is possible to use hyphen (-) in a hostname as this separator. So we have the following scheme:

s2mdezeof64lrcft.onion - public onion
nf2kpynuymdd63wms6nkq5if4m-s2mdezeof64lrcft.onion - authenticated onion
As it is base32 there are only two bits left (instead of of 4 with base64) so we can encode two more auth types.

I've implemented this idea for the client code (you have to convert descriptor cookie from base64 yourself for now). Please have a look at the patch attached.

Noticable drawback:

  • Due to how client cache works for now, once intropoints are decrypted/not decrypted there will be cache entry that blocks auth data change.

This requires client cache rewrite to decrypt intropoints
at each request (make it stateless).

It would be nice to hear any thoughts and comments on this.

Child Tickets

Attachments (1)

extended-auth-onion-21d62462.patch (8.5 KB) - added by twim 4 years ago.
Patch for little-t-tor

Download all attachments as: .zip

Change History (4)

Changed 4 years ago by twim

Patch for little-t-tor

comment:1 Changed 4 years ago by arma

Once upon a time, we expected onion addresses to be of the form x.y.onion, where we indeed put other things like authentication info in them.

But we abandoned this design when we realized that client applications like browsers were sending the whole address along in their Host: header, so putting sensitive things there is going to cause surprises and bad results.

comment:2 Changed 4 years ago by twim

But we abandoned this design when we realized that client applications like browsers were sending the whole address along in their Host: header, so putting sensitive things there is going to cause surprises and bad results.

Yes they are.
But is this data sensitive at all? An onion service already knows this data (the service has generated these cookies). It's also not going to make these cookies playing role of selectors to track users. An onion service can do it by obseriving the set of IPs from which it was reached.

bad results

What do you mean?

comment:3 Changed 3 years ago by nickm

Keywords: needs-proposal added
Resolution: wontfix
Status: newclosed

Referer headers also make this a pretty risky idea.

I'm going to close this one as wontfix, but if you still think I'm wrong, please write a proposal for tor-dev about why this is worth the trouble and/or how to mitigate the security risks?

Note: See TracTickets for help on using tickets.