Re: [tor-talk] Revoking a hidden service key

[Domenico Andreoli <domenico.andreoli@xxxxxxxxx>]

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 <adrienj@xxxxxxxxxxx> 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 <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
>>>>>
>>
>>
>
> --
> 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
-- 
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