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 abasic 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 anyother 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 canmove 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 isachieved!
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 thepast 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 arevoked 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 ifanother 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