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

Re: [tor-talk] trusting .onion services



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rejo Zenger <rejo@xxxxxxxxx>:

> [2] OK. Not entirely true, maybe. It may be possible to include those
> key in some listing of the directory authorities marking them as bad
> nodes. This is a manual process.

There should be a possibility to automate this process. Something like...

1. HS owner realizes that his HS key has been stolen (but he still has 
his copy)

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

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

4. All relays with HSDir flag should keep in their DHT (the ones with 
hidden service descriptors) also these revocation messages

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

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)

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

Any flaws in my idea? I see two:

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?

2. What if someone tries to fill the DHT with malicious revocation 
messages? But it can also happen with normal HS descriptors...

- -- 
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
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJWoANIAAoJEGaQzFIxjbhMX0YH/R30viK1OFRsC5NSSF40jOHG
UKItJdGKZupuARcoYwe2DoQloCxiLINPhPigjzRpY6YGzUfYw9+yu9V82MK7CDbj
FXnORHfDJjj3qereao1K98aYCrOji+11sAC/aeuuwqxqdHfzSqY0WCqwq4MCMsex
lLWghummxQ9qs96EIadUWOszQAWPnfNojNp+ylrFU4sRC364AMCxMyvrM8xG0zpu
XUUPtAfo9LEagRKcxpa+zmSvIVOd3f3X+SBIrkBRqdfm7bOizPHigPkFwhPUBoe5
9WiONqm3NBZO6Tfi+4elsNIOkUR99N4SgpLChNRRpnpc6LmIo7aKvXNhUYA3a8w=
=UBxQ
-----END PGP 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