Proposal: Hidden Service Authentication

Karsten Loesing karsten.loesing at gmx.net
Thu Sep 27 16:08:30 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Robert,

> I think I can see how tor might manage all this stuff in a fairly
> transparent way but it would be useful to be explicit about what
> input tor needs from the user during the authentication and when/how
> it should be gathered.
> 
> For example, it's not clear to me how (or even if) the tor client
> gathers the password  from the user when connecting to a specific
> hidden service. Does the user specify it in their torrc for that
> hidden service?

Thank you for your comment! You mention an important point with regard
to usability!

But there are two reasons why we did not include that into our proposal:

1. It is not part of the Tor protocol, but an implementation issue of
the Tor software. Thus, it should be left to the programmer of a Tor
node to decide how keys and configurations are stored.

2. We did not make a final decision on how to include it in the Tor
software.

We wrote down a draft version of the necessary configuration files on
both, hidden service and client side. But these formats have not been
implemented and are subject to change!

On hidden-service side there is a single file (e.g. "authentication") in
the hidden service directory, containing:

  SecretCookieName [unique cookie name]
  SecretCookieKey [password]

  User [user name]
  IntroductionPointAuthentication [password]
  HiddenServiceAuthentication [password]
  PublicKeyAuthentication
  -----BEGIN RSA PUBLIC KEY-----
  [base64 encoded public RSA key]
  -----END RSA PUBLIC KEY-----

The names for secret cookies and users are merely used for display
purposes in a GUI. There may be one or more secret cookie blocks, each
followed by one or more user blocks. For each user there needs to be
specified at least one password or public key.

On client side there is a single file for each hidden service to be
accessed. Its file name is a user-defined alias of 1 to 15 characters,
e.g. "bobsservice", that the user later provides as onion URL, e.g.
"bobsservice.onion". It is stored in a subdirectory of Tor's working
directory. It contains:

  HiddenServiceID [service id]
  SecretCookieKey [password]
  IntroductionPointAuthentication [password]
  HiddenServiceAuthentication [password]
  PublicKeyAuthentication
  -----BEGIN RSA PRIVATE KEY-----
  [base64 encoded private RSA key]
  -----END RSA PRIVATE KEY-----

When accessing an onion address using such an alias, Tor looks up, if
there is a file containing authentication data and performs
authentication instead of directly trying to connect to the hidden service.

As an alternative we discussed to write all authentication data to the
onion address, like:

<intro-auth>.<hid-serv-auth>.<secret-cookie>.<hid-serv-id>.onion

This is just a first draft. If you have any suggestions on how to
improve it, please tell us! We are not _using_ hidden services regularly
(shame on us...), so we don't know exactly what would be best from a
usability perspective!

Thanks!
- --Tobias, Thomas, Karsten, Ferdinand, and Christoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+9V+0M+WPffBEmURAm2RAJ9TweGibY5I99H8A/y8YrAClVJwJwCfXaAq
5qCAeqv+HDdQ8eTAmwww5Ao=
=vyvB
-----END PGP SIGNATURE-----



More information about the tor-dev mailing list