On 02/01/12 10:59, William Waites wrote:
> What if instead, we used a similar mechanism as we already have for
> the hidden services and do say hash("antani").nym and push that out to
> the introduction hosts. The introduction hosts would check if they can
> resolve it, if they can, the request is rejected, if they cannot then
> they keep the mapping (careful implementation to avoid race conditions
> here). Have an cache+expiry mechanism from there so the mapping isn't
> trivially lost when the hidden host goes offline.
If I'm understanding you correctly...
Let's say Mallory discovers a scripting error and exploits it to
fork-bomb Alice's service. It has insufficient resources to keep the
hidden service online but still responds to pings and even manages to
serve an occasional static page on a non-hidden address, fooling Alice's
home-grown monitoring solution. Alice of course notices the problem when
she manually checks the service, but she attributes the failures to
something else, leaving Mallory free to keep trying. Eventually Alice
takes a vacation and Mallory is successful at keeping the service
offline for $expiry_time. At this point the nym can be hijacked as no
secret is needed to claim it.
Am I missing something?
Julian
--
3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012@xxxxxx>
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev