Re: [tor-talk] Hidden service may be compromised

[Kostas Jakeliunas <kostas@xxxxxxxxxxxxxx>]

On Fri, Apr 11, 2014 at 7:32 PM, Cyrus <cyrus_the_great@xxxxxxxxxx> wrote:

> On 04/12/2014 02:09 AM, Kostas Jakeliunas wrote:
> > On Fri, Apr 11, 2014 at 6:19 PM, Cyrus <cyrus_the_great@xxxxxxxxxx>
> wrote:
> >
> >> My hidden service address may have been compromised in Heartbleed. I
> >> can't seem to reach my own hidden service most of the time. Other
> >> services I hope so far seem unaffected. I am curious what happens if the
> >> same private key is used by someone else, and how an attacker might use
> >> a private key to disable a hidden service. I am currently switching to a
> >> new key as a precaution. Information would be greatly appreciated,
> >> because I think someone is blocking my hidden service somehow.
> >>
> >
> > To attempt to actually answer your question (don't count on this answer
> > though, at all..) in a mostly amateur fashion: if your hidden service's
> > long term identity private key is stolen, it might be used to create
> > descriptors about that hidden service that point to a different set of
> > introductory points (relays used by clients in the initial phase of
> trying
> > to reach a hidden service), behind which a different server is hiding.
> > Since they (thieves) have your HS private key, they can then full well
> > pretend to be the HS that you've been running, and the clients would not
> > know.
> >
> > I'm not sure, but I think that any experiments with this kind of attack
> > have been minimal to nonexistent [a niche for investigation!] The
> > speculation would be that if this happens and someone else tries to
> > advertise a HS under the same address, it's more or less a matter of
> chance
> > which descriptor is actually fetched by clients trying to reach that
> > address. Sometimes they would reach one point and sometimes another; they
> > would think both attempts would be valid. If the bogus hidden server is
> > down / nothing is listening behind it (no actual application (e.g. web
> > server)), connection attempts would simply fail at the last phase. (This
> > reminds me to publish a very primitive and tiny script that tells you
> which
> > point of the connection to a HS fails (intro point / rendezvous /
> > application-level server), I guess this is a valid incentive to do so..)
> >
>
> That is very interesting.
>
> There is some strangely good news that services I've added just now are
> not working either, so the problem is with my Tor service in general. So
> all I need to do is solve it. Some services come back up and go down,
> and requests for the services are sometimes showing in the info log.


From this, thinking heuristically (read: guessing in the dark) one may lean
towards "problems on your end", yeah. Maybe try to reproduce with a way to
ensure that any responses actually from your services (e.g. a hidden
service may run a web server with a self-signed certificate (not that one
should do this normally), and you could check each time you try to connect
- to see if the fingerprint for the certificate remains the same - the one
you actually have on the web server. Maybe there are easier and quicker
ways.. and not sure if this would prove anything, at all: it would be best
to try all six hidden service descriptor directory servers responsible for
the HS address in question[1], to see if any return a rogue descriptor for
your HS address.)

Hopefully there's a more practical and easier approach/explanation from
someone.

[1]: relevant reading material:
https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt(e.g.
section 1.4)
-- 
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