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

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



On Sun, Oct 27, 2013 at 1:08 PM, Andrea Shepard <andrea@xxxxxxxxxxxxxx> wrote:
> 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.

Fantastic point, and just as easily done. As obvious as it is, I'd
forgotten about people keeping the HS keys on separate hosts.

It also raises the point that perhaps future Tor HS should also
support delegation
so that the HS master identity key could be kept offline.  E.g. you
have a HS identity
key, and it delegates to a short term HS key which has a lifetime of
only 1 month,
and perhaps has some kind of priority scheme such that a key with a higher
sequence number takes precedence. E.g. if someone compromises your key you can
instantly throw up a new service which people will connect to instead...

If your HS (bastion) host is compromised you wouldn't completely lose
control of your HS identity.

Might even be useful to pre-define a maximum sequence number such that
an announcement with
that sequence number blocks access.  So if your site is compromised
you can announce a pre-signed HS revocation which forever kills the
address so long as someone keeps periodically rebroadcasting it to
RPs.

> 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.

Yea, I'm not too worried about that. If the Tor usage becomes very
common we could simply extend the protocol with a tor-specific
extension that supports them.  My thinking here is that at least for
today I can do something to make existing HS identities work with very
little effort.
-- 
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