The unvoidable single point of failure is the loss of control on a given onion node. Isn't possible to require multiple nodes to sustain a single hidden service? So that loosing control of a single node doesn't compromise the whole service.
Domenico On Tue, Mar 3, 2015 at 2:40 PM, Adrien Johnson <adri...@adrienj.com> wrote: > A client receiving a revocation descriptor would want to remember not to > trust that hidden service for as long as possible, so there's still going to > be long-term storage somewhere in the chain. Putting it in the directories > would mean that as many client as possible could be notified of the hidden > service's revocation, even long after the initial revocation is published, > in cases where the hidden service operator is unwilling or unable to > continue to announce the revocation. > > Consider that for long-validity revocations, there would actually be less > load placed on the network than for a regular short term descriptor. The > hidden service would not need to frequently publish a new descriptor about > itself. Once a client knows a hidden service is revoked, they do not need to > ask about it again. Old revocations could conceivably be stored to disk. > > The need to revoke hidden service keys is real. It doesn't take long to dig > up anecdotes and news reports of .onion sites that have been compromised, > but even when detected there is no reliable way for a legitimate hidden > service operator to notify the network his service cannot be trusted. > Detecting if someone has stolen your hidden service key is easy and is > hijacking your traffic is easy, you only have to look out for hidden service > descriptors for your service that you did not publish, but there is > currently not much that can be done with this information. The hidden > service operator could include a notice on his hidden website warning of the > compromise and telling users to divert to a different .onion address, but a > user has no way of knowing if that warning was published by the attacker and > directs to another malicious site. > > > On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote: >> >> 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 <adri...@adrienj.com> >>>> 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@lists.torproject.org >>>>> To unsubscribe or change other settings go to >>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>>> >> >> > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
