[tor-dev] A Proposal for a hidden service revocation system

Sun Mar 8 12:24:19 UTC 2015

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150308/3f65e922/attachment.html>