Opened 6 years ago

Last modified 3 years ago

#15729 new enhancement

Proposal: Hidden Service Revocation

Reported by: Nathaniel Owned by: Nathaniel
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, tor-spec stalled security revocation
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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.

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

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

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

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

Child Tickets

Attachments (1)

xxx-rend-revoke.txt (11.3 KB) - added by Nathaniel 6 years ago.
Text file version of proposal

Download all attachments as: .zip

Change History (10)

Changed 6 years ago by Nathaniel

Attachment: xxx-rend-revoke.txt added

Text file version of proposal

comment:1 Changed 6 years ago by Nathaniel

Hello all,

I was advised by Donncha that moving the discussion on this proposal from the tor-dev mailing list to here would make organization easier. Seems the formatting came out a little strangely though. A text file version with the line breaks intact has been added as an attachment.

Also, since the Tor Summer of Privacy has been unveiled this year, I'd love to implement this proposal myself (incorporating all your feedback) as part of that program. I am currently completing my Bachelor of Engineering, and the financial stipend would allow me to make this project my main focus in the coming months. So don't hold back in suggesting major or difficult changes in the fear that you'll be the one having to implement them.

Looking forward to getting this proposal to the point that initial implementation patches will be welcomed!

comment:2 Changed 6 years ago by special

I like the concept. I agree with your arguments against implementing long-lived revocations, and I don't see any reason to make it more complicated.

It might be worth mentioning that a client must not continue requesting descriptors from HSDir mirrors after receiving a valid revocation descriptor, so we remember to verify that behavior.

There is a race between a real descriptor and revocation at every time-period rotation, but we can fix that. Revocation descriptors should be published some time before the time-period changes, and HSDirs must accept those. Currently, they accept descriptors up to REND_CACHE_MAX_SKEW (currently 24 hours, #13207) in the future.

As a side effect, the revocation client would have to support publishing two sets of descriptors for different time periods simultaneously.

There's another race any time the HSDir hash ring changes for the service. I don't think we can avoid that one, other than by making sure the revocation is published promptly after a new consensus.

A malicious HSDir could ignore the revocation, impacting ~1/6 clients. This is detectable, only lasts one time-period, and I don't see any reasonable fix. That seems acceptable.

A revocation takes the form of a hidden service descriptor which provides no way to contact the hidden service (i.e. zero introductory points)

This is a problem for clients that don't have the fix for #15601.

  1. Future Compatibility with Next Generation Hidden Services

I'd like to see this figured out semi-promptly. We should avoid creating more work to finalize prop224 than we already have.

comment:3 Changed 5 years ago by teor

Milestone: Tor: 0.2.???

comment:4 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 4 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 3 years ago by dgoulet

Keywords: tor-hs tor-spec added; hidden rendevous descriptor revocation compromise removed
Severity: Normal

comment:8 Changed 3 years ago by nickm

Keywords: stalled security revocation added

comment:9 Changed 3 years ago by Dbryrtfbcbhgf

I think it would be great to see "5. Future Compatibility with Next Generation Hidden Services" in a future version of Tor.

Note: See TracTickets for help on using tickets.