Hi Donncha,
Thanks for the feedback! This is an issue I'm passionate about and
would really like to help
implement. Since the CA/Browser Forum recently adopted rules
letting anyone who has the
master secret key get an EV SSL certificate for a .onion domain, a
hijacker can even present
itself as a 'secure version' of the real service, with the
https://, the padlock, the green bar,
and everything.
You make a good point, a local cache of previously encountered
revoked services is a privacy
risk. I'll remove references to this in the next draft.
I'm very glad to hear that current hidden service directories
would accept a descriptor with
a 'revoked' line! If a revocation is defined as a descriptor with
zero introductory points and
a 'revoked' line, then there is no danger of accidental
revocations in the current code and
no need for the modification in step 1 or the waiting period in
step 2 of the timeline I
outlined. We could skip straight to step 3, modifying hidden
service directories to block
'un-revocation' attempts.
The reason I suggested hijacking detection would be part of the
hidden service node itself
is because I can't see any way for hijacking to be detected with
certainty unless the
detector knows for sure which descriptors were published by the
legitimate service
and which may have been published by someone else. I think you're
right that architecturally
a detector should be a separate piece of software, but tor would
need to have an local
interface which exposes this information.
Yes, it's too bad the hidden service directories are currently
vulnerable to attackers intentionally
positioning themselves so that they hold the descriptors for a
targeted hidden service. This is
already noted as making .onions vulnerable to DOS attacks in some
of the specifications I've read,
but vulnerability to un-revocation is also serious, especially if
clients do not retain a local cache
of previously-known-to-be-revoked sites.
It was my pleasure putting to this together, and I agree, it would
be nice if it weren't needed! But
most services run their web server on the same machine as their
tor node, so compromises are
inevitable. I can't wait for the added protection next generation
hidden services look like they're
going to bring!
Cheers,
Adrien Johnson
On 2015-03-07 9:43 PM, Donncha O'Cearbhaill wrote:
Hi Adrien,
Good job on writing up a draft for this proposal! It looks good!
On 07/03/15 21:33, Adrien Johnson wrote:
Filename: xxx-rend-revoke.txt
Title: Hidden Service Revocation
Author: Adrien Johnson
Created: 2015-03-04
Status: Draft
Hidden service operators need to be able to revoke trust in their hidden
service
if they know or suspect their hidden service secret key has been
compromised.
-- snip --
4.1 Basic Support
For the Tor network to support hidden service revocations at a
basic
level, a large proportion of hidden service directories must
recognize
that a hidden service descriptor with zero introductory points
has the
special meaning of being a revocation. These hidden service
directories
must not allow a current unexpired revocation descriptor to be
replaced
by a non-revocation descriptor (so called 'un-revocation'). In
all other
ways, treatment of a revocation descriptor is identical to
treatment of
a non-revocation descriptor for a hidden service.
[NOTE: Maybe we want a more explicitly requested revocation?
Using a
zero introductory point descriptor as a revocation has the
advantage of being backward-compatible with older directory
software,
which will be able to accept and propagate the revocation to
other more
up-to-date directories, even though the older directories will not
provide protection against un-revoking a hidden service if the
attacker
delivers an un-revocation descriptor to them directly.
Is there a need for zero introductory point descriptors in any
other
case? If a hidden service previously published introductory points
and it now no longer can be contacted at those points, and it does
not have any new introductory points, it is unreachable.
Publishing a
descriptor announcing all zero of its introductory points will not
change its reachability, though it may slightly reduce wasted
effort by
tor nodes attempting to reach it.]
The current rend-spec allows for hidden service's to publish descriptors
without any introduction points. I think it would much better to add an
explicit 'revoked' line to the revocation descriptor.
I've done a quick test and it looks like relays already accept hidden
service descriptors containing undefined fields. As such implementing it
as such should be backward-compatible with previous version of Tor.
4.1.1 Steps required to add support
1) If current code results in hidden services publishing zero-
introductory point descriptors, this is blocked to prevent
accidental revocation. I would love to get this in 0.2.6.
2) If a modification is needed in step 1, then a grace period
is given for hidden service operators to update their
software. This grace period does not have to be long, we can
move
onto step 3 relatively fast, since the only penalty for
accidental
revocation step 3 would create is forcing the hidden service to
upgrade their software, and the hidden service being
unreachable for
a maximum of 25 hours (lifetime of a descriptor) after the
hidden service upgrades.
3) Hidden service directories are modified to not allow a
current unexpired revocation descriptor to be replaced by an
un-revocation descriptor. Basic support for revocation is
achieved!
4) A long upgrade grace period is now given. The vast majority
of hidden services should be using software which includes the
modifications made in step 1
5) Expanded revocation capabilities may be added, as described
below.
4.2 Expanded Capabilities
4.2.1 Cache of revoked services
A Tor node which tried to connect to a hidden service in the
past
and discovered that the service was revoked should remember
that
revocation and refuse to connect indefinitely, even if the
revocation ceases to be broadcast in the future.
The client should not keep local records of the hidden services that
they have accessed. I think the client should only store the descriptor
as normal in their local descriptor cache.
4.2.2 Presentation to the user
If an onion proxy that detects the user tried to visit a
revoked
service, this information should be presented to the user
out-of-band. I.E not in a way that could be mistaken for a
hidden
service which is only temporarily unreachable, or as
information
sent by the service. This could be done via a system level
popup, or
a taskbar notification. The presentation should be strongly
distinguished from a hidden service which is simple
unreachable.
A control port event should be defined to signal to a controller that
the accessed hidden service has been revoked. The controller (TorButton
etc.) could then notify the user is an appropriate way.
4.2.3 Automatic hijacking detection/revocation
Tor hidden service software could have a mode to detect if
another
party is using the hidden service private key to publish
descriptors
for that service. If the hidden service operator configures it,
the Tor hidden service software could immediately begin to
broadcast
the revocation for that service.
This may be possible, but I think it would be simpler and safer to
implement "hijacking" detection outside of little-t-tor.
It practice, it may be difficult to ensure that a client actually
receives a revocation descriptor. Firstly this protocol won't work very
well until enough relays upgrade to version implementing this protocol.
Additionally with the current implementation of hidden services, an
attacker who has compromised the HS key could position their relays to
be the HSDir's for the revoked hidden service. They could then provide
client's with only a standard descriptor and impersonate the HS. In
practice it may be possible for a revocation service to to watch for
this type of behaviour.
Thanks for putting this together. The best solution is of course of
hidden service operators their service key safe in the first place!
Regards
Donncha
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev