[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] x.509 for hidden services



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@xxxxxxxxxxxxxx>
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

Attachment: pgpMX1I1MoJMo.pgp
Description: PGP signature

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk