[tor-bugs] #15729 [Tor]: Proposal: Hidden Service Revocation

Sat Apr 18 10:03:28 UTC 2015

#15729: Proposal: Hidden Service Revocation
-------------------------------------------------+-------------------------
 Reporter:  Nathaniel                            |          Owner:
     Type:  enhancement                          |  Nathaniel
 Priority:  normal                               |         Status:  new
Component:  Tor                                  |      Milestone:
 Keywords:  hidden, rendevous, descriptor,       |        Version:
  revocation, compromise                         |  Actual Points:
Parent ID:                                       |         Points:
-------------------------------------------------+-------------------------
 Filename: xxx-rend-revoke.txt
 Title: Hidden Service Revocation
 Author: Nathaniel 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.

  1. Motivation

   A Hidden service operator can determine that the hidden service secret
 keyis compromised in several ways today. Forensic traces of intrusion may
 bedetected on the hidden service server, or valid signed descriptors for
 theservice may be published by someone other than the legitimate operator
 in atraffic hijacking attack.

   Even though it is possible for the operator to detect a hidden service
 key iscompromised, there is no satisfactory way for a hidden service
 operator tonotify its users of this fact. The hidden service may displaya
 message to its users warning of the compromise and directing them to a
 newsupposedly uncompromised .onion domain, but a user has no way to
 knowwhether such a message was posted by the legitimate hidden service
 operatoror a hijacker.

   A revocation system where anyone possessing the hidden service secret
 keycan revoke trust in the key solves this problem.

  2. Overview

   This revocation system is built on the hidden service directory system.
 Arevocation takes the form of a hidden service descriptor which provides
 noway to contact the hidden service (i.e. zero introductory points),
 andcontains a "revoked" line of the following format

   "revoked" NL

   [At most once]

   If present in a hidden service descriptor which also contains
 zerointroductory points, indicates that this is a revocation of the
 hiddenservice.

   A hidden service directory which receives a revocation descriptor
 andverifies its signature should discard any non-revocation descriptors
 itpossesses for that hidden service, and should propagate the
 revocationthrough the hidden service directory system as normal.

   Crucially, a hidden service directory which possesses a
 revocationdescriptor for a hidden service and receives a newer, valid
 descriptor forthat hidden service which is not a revocation descriptor
 MUST retain therevocation descriptor and MUST discard the newer non-
 revocation descriptor.This is the only change needed to support this
 revocation system at abasic level today.

  3. Design considerations

   3.1 Revocation lifetime

   Ideally, a revocation should be permanent. The Tor network wouldideally
 remember forever that a hidden service has been revoked, andthis would
 provide the maximum possible protection to the users of thehidden service
 against imposter services.

   However, a permanent (or even just long-lived) revocation in the
 hiddenservice directories present problems:

   1) Increased memory and bandwidth requirements on the Tor
 networkcompared to a normal hidden service descriptor. For non-malicious
 use,this may not really be a problem, since once a service is revoked,
 therewould be only a trickle of requests for updated information about
 it(from visitors who have not already found out it was revoked).
 Howeverfor a malicious user who attacks the Tor network by flooding it
 withhidden service descriptors for fake hidden services, any
 increasedlifetime of a revocation descriptor over a normal descriptor
 representsa multiplication of their attack power.

   2) For next generation hidden services as described in224-rend-spec-
 ng.txt, a revocation which lasts longer than one blindedsigning key
 validity period weakens the privacy protection againstcorrelation which is
 provided by rotating blinded signing keys. If arevocation were - for any
 amount of time - not expected to besigned by the current normal blinded
 signing key for that service, butinstead a separate 'blinded revocation
 signing key', then users seekingto check the revocation status of that
 service before visiting wouldhave to make two requests for a hidden
 service descriptor: one to see ifthere is a revocation descriptor
 published by that service, and one tosee if there is a normal descriptor
 published by that service. A malicious hidden service directory (or group
 of directories) could usethis correlation to determine which hidden
 service descriptors belong tothe same hidden service between blinded
 signing key rotations.

   Implementing a long-lived hidden service revocation at the client
 level,a cache of previously seen revoked hidden services for example,
 woulddisclose the user's browsing history to anyone who examined it, and
 istherefore not a good solution either.

   For these reasons, revocations which last no longer thana normal hidden
 service descriptor, and which the operator musttherefore constantly
 broadcast, are the safest option for implementinghidden service
 revocations.

   Short lived revocations have the advantage that the Tor network does
 notneed to make any hard-and-fast judgement about how long it is
 worthwhileto remember a hidden service has been revoked, the hidden
 serviceoperator can make that judgement for themselves and broadcast
 therevocation for as long the operator feels hijacking and impersonationis
 a concern.

   If the operator is unable to maintain (or fears they will be unable
 tomaintain) a revocation broadcast for an appropriate amount of time,they
 can disclose their private key to a 3rd party service who willbroadcast
 the revocation on the operator's behalf. An operator wouldwant to employ
 several of these services, since if only one service hadthe private key,
 and if they were malicious, they could ceasebroadcasting the revocation
 and instead use the key to set up animpostor service.

   Despite these minor difficulties that short-lived revocations
 impose,they are still a major improvement to the security of the Tor
 network.

   3.2 Side note on the shape of a 3rd party Revocation Broadcast Service

   Though it is outside the scope of this specification,I envision these
 3rd party key revocation services being simple websiteswhere anyone can
 upload a hidden service private key and the websitewill broadcast the
 revocation indefinitely. They could employ simpleabuse-mitigation like
 CAPCHAs or IP ratelimiting over the clearnet toprevent mass-upload of
 keys. This should keeps costs low enough thatthese revocations services
 would operate for free.

  4. Implementation

   4.1 Basic Support

   For the Tor network to support hidden service revocations at a
 basiclevel, a large proportion of hidden service directories must
 recognizethat a hidden service descriptor with zero introductory points
 and able"revoked" line has the special meaning of being a revocation.These
 hidden service directories must not allow a current unexpiredrevocation
 descriptor to be replaced by a non-revocation descriptor(so called 'un-
 revocation'). In all other ways, treatment of arevocation descriptor is
 identical to treatment of a non-revocationdescriptor for a hidden service.

   4.1.1 Steps required to add support

   1) Hidden service directories are modified to recognize the formatof a
 revocation descriptor, and prevent revocation descriptors frombeing
 superseded by a non-revocation descriptor for the sameservice. Basic
 support from the core software is achieved!

   2) The ability to broadcast revocations is implemented.

   5) Expanded revocation capabilities may be added, as describedbelow.

   4.2 Expanded Capabilities

   4.2.1 Presentation to the user

   If an onion proxy that detects the user tried to visit a revokedservice,
 this information should be presented to the userout-of-band. I.E not in a
 way that could be mistaken for a hiddenservice which is only temporarily
 unreachable, or as informationsent by the service. This could be done via
 a system level popup, ora taskbar notification. The presentation should be
 stronglydistinguished from a hidden service which is simple unreachable.

   4.2.2 Automatic hijacking detection/revocation

   Tor hidden service software could have a mode to detect if anotherparty
 is using the hidden service private key to publish descriptorsfor that
 service. If the hidden service operator configures it,the Tor hidden
 service software could immediately begin to broadcastthe revocation for
 that service.

   [Per Donncha's feedback, both of these should probably be delegatedto
 control software, with tor itself simply exposing an eventwhenever a
 revoked site is encountered or a new valid descriptoris published, and the
 external controller will take care of notifyingthe user or detecting if
 any separate tor node is publishing descriptorsfor the same service.]

  5. Future Compatibility with Next Generation Hidden Services

   Next generation Tor hidden services require a modifiedrevocation system
 because the hidden service master secret key is betterprotected, and does
 not need to be constantly live on the hidden service tornode. The day-to-
 day operation of the service is carried out by a pre-loadedset of changing
 subordinate descriptor signing keys, which expire after aset time (25
 hours by default). If descriptor signing keys are compromised,they can be
 used to hijack traffic and impersonate the hidden service,but only until
 the descriptor signing keys expire. So there is an additionalneed for a
 way to revoke descriptor signing keys and provide new ones,without
 permanently revoking trust in the hidden service.

   Also, theft of descriptor signing keys should not allow an attacker
 torevoke the master secret key.

   The revocation permissions would looks something like the
 following.(Blinded signing keys are equivalent to the master secret key
 forrevocation purposes because if an attacker obtains any blinded
 signingsecret key, they can mathematically derive the master secret key.)

   1) Current descriptor signing key can revoke current descriptor signing
 key.

   2) Master secret key can revoke any descriptor signing key and provide a
 newdescriptor signing key for that time-period.

   3) Master secret key is the only one that can revoke master secret key.

   [TODO: Sketch out implementation later]

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15729>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online