[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] trusting .onion services

Hash: SHA1

Oskar Wendel <o.wendel@xxxxx>:

I already see some flaws in my solution, so forgive me for answering 

> 2. HS owner creates the "revocation message" for the onion address, signs 
> it with his key and submits it to the DHT the same way a HS descriptor 
> is uploaded

I think it should be done by Tor after putting a directive in torrc below 
HiddenServiceDir. Something like:

HiddenServiceDir /some/dir
HiddenServiceRevoke 1

> 3. This revocation message, once received and confirmed that it belongs to 
> the owner of the specified onion address, cannot be cancelled or undone. 
> The address is marked as "bad" forever. Alternatively, to avoid cloggering 
> the network, it could be marked as "bad" only for a certain amount of 
> time (a year?) and during the validity period, the owner should reissue 
> a new revocation message, or else it will expire

Better idea would be to publish it exactly as HS descriptors are 
published. I don't know the validity period of a HS descriptor, but it 
should be periodically refreshed as long as Tor is running (just like HS 
descriptors are - are they?)

Of course only one Tor instance would be sufficient to revoke all HS 
descriptors, published by the attacker who stole the key.

Of course, the attacker could post his own revocation message, but he 
would only do everyone the favor by doing so.

> 5. When client tries to download a HS descriptor from a HSDir relay, it 
> will receive the descriptor, but it will also receive the revocation 
> message
> Now it all depends on the client:
> 1. Client too old to understand revocation message will ignore the message 
> and connect anyway

Maybe it would be better to check client version (does it send its version 
when asking for HS descriptor?) and in case the client is too old and a 
valid revocation message exists, refuse sending this HS descriptor.

> 2. Client with a default configuration will verify the signature of the HS 
> revocation message and if valid, will refuse to build circuit to HS 
> introduction point (and log this information)

The signature should always be valid, as it is checked by the HSDir relay, 
but the client should do its check anyway (because HSDir relay could be 

> 3. Client with a special configuration flag set (IgnoreHSRevocations or 
> something like that) could log the revocation message, but build circuit 
> anyway, at the client owner risk

Of course logging with the usual "[scrubbed].onion" text.

> 1. What if Tor on HSDir relays is too old? They won't process this message 
> properly. Maybe we should have a new flag for revocation message directory 
> relays and use it instead?

Bad idea, as all clients would then need a separate circuit to the 
revocation directory just to check the revocation message and it would 
slow down connecting to all hidden services.

What do you all think?

- -- 
Oskar Wendel, o.wendel@xxxxxxxxxxxxxxxxx
Pubkey: https://pgp.mit.edu/pks/lookup?search=0x6690CC52318DB84C
Fingerprint: C8C4 B75C BB72 36FB 94B4 925C 6690 CC52 318D B84C


tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to