On Fri, Apr 11, 2014 at 7:32 PM, Cyrus <[email protected]> wrote:
> On 04/12/2014 02:09 AM, Kostas Jakeliunas wrote: > > On Fri, Apr 11, 2014 at 6:19 PM, Cyrus <[email protected]> > 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 - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
