[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