Alternatively the original hidden service operator could publish hidden service descriptors with a normal validity period which contain a revocation field. A HSDir which receives a descriptor containing the revocation could replace the (potentially malicious) HS descriptor stored in its cache. A client could be show an alert that the hidden service they are attempting to access has been compromised/revoked and should not be used in future. A HS operator would then keep broadcasting the revocation descriptor until such time that all clients are likely to have been notified. This kind of replacement approach would allow revocation without placing any more load or memory demands on the network. In practice do HS operators have a need to revoke hidden service keys? On 03/03/15 03:05, Adrien Johnson wrote: > An solution might be to allow hidden service revocation descriptors to > expire after a long time, and to be updated by the hidden service > operator, but only as a new revocation descriptor which has a later > expiration date. That way the Tor network can eventually forget about > revoked hidden services which are no longer used and where the operator > no longer feels there is a threat of impersonation. > > On 2015-03-02 9:50 PM, Max Bond wrote: >> It seems like the only way this scheme could work is if the directories >> remembered which services had issued revocations, making compromises >> expensive for the whole network and opening the door for >> denial-of-service >> attacks that effect hidden services as a whole. >> >> I would counter propose that you set up a Twitter account which tweets >> about the status of your hidden service, where you could make an >> emergency >> announcement. Perhaps you could have a passcode required to enter the >> site >> that changes on a daily basis and is announced from twitter, so that your >> users get in the habit of checking twitter before logging in to your >> site. >> >> On Mon, Mar 2, 2015 at 6:40 PM, Adrien Johnson <adrienj@xxxxxxxxxxx> >> wrote: >> >>> Deleting your key and taking down your service would prevent further >>> compromise of your system, but if your private key was already >>> stolen, it >>> wouldn't stop an attacker from continuing to announce your key and >>> running >>> an imposter service. >>> >>> -- >>> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx >>> To unsubscribe or change other settings go to >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>> >
Attachment:
signature.asc
Description: OpenPGP digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk