[tor-talk] x.509 for hidden services

[Andrea Shepard]

On Fri, Oct 25, 2013 at 09:26:21PM -0700, Gregory Maxwell wrote:
> ==Where Tor comes in==
> 
> One of the downsides if using x.509 certs to non-repudiate here is
> that sites hosted as tor hidden services can't participate.
> 
> It occurred to me that this could be fixed with very little code:
> 
> Take the HS pubkey, pack it into a self-signed x.509 cert with the
> cn=pubkeybase32.onion.  And specify that .onion certs have a special
> hostname validation rule that hashes and encodes the key.
> 
> Then the whole process would work for .onion, we'd have a non-CA
> option available and working, etc.
> 
> I'm aware that HS pubkeys have been used for application level
> authentication in Tor elsewhere (e.g. I believe torchat does this) so
> it's not entirely unprecedented. I'm not aware of anyone packing them
> in x.509 certificates. If anyone has, I'd like to use the same
> encoding style for greater compatibility.
> 
> The biggest reason I can see not to do this is that it will not be
> compatible with future editions of hidden services which aren't based
> on RSA keys. (e.g. the EC point addition stuff to protect against
> enumeration attacks wouldn't fit into this model). I don't think this
> is a serious concern: if HS x.509s do become widely used we could add
> a new authentication type for the new onion addresses when those are
> introduced.
> 
> Does anyone else see any other reasons not to do this?
> 
> Are there other applications which would benefit from having x.509
> certs for onion names?

For defense in depth on the HS side, it's best to run the HS Tor on a
different machine, or at least a different VM, than the HS server, so
that if the HS server software is owned, the HS private key isn't
compromised.  The setup you describe would prevent that configuration;
consider allowing, in addition to self-signed certs, a certificate chain
where the root is a CA certificate matching the HS key in the manner you
describe and signing a certificate using a different key for the service
to use.

As for the migration to elliptic curves, I think the most serious problem
you'll encounter is that the curve we end up using may not be one that has
a standardized OID or is widely supported in X.509 implementations - e.g.,
Curve25519.

-- 
Andrea Shepard
<andrea at torproject.org>
PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF  DE79 A4FF BC34 F01D D536
PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5  DF7E 4191 13D9 D0CF BDA5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 328 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20131027/64d84e2f/attachment.sig>