A list of 1777 proposed reject lines of fingerprints which have ever turned up as potentially exposed by Heartbleed in my scans is available at the URL below. This was generated with the following query:
(select distinct hb.probe_identity_digest as identity_digest from heartbleed_probe_results hb where hb.probe_has_heartbleed and hb.probe_tor_checked_identity) union (select distinct hb.expected_identity_digest as identity_digest from heartbleed_probe_results hb where hb.probe_has_heartbleed and not hb.probe_tor_checked_identity) order by identity_digest;
That is, it includes all probe results for which a Tor handshake was actually completed with the identity digest in question *and* a response to the Heartbleed probe was seen (1729 digests) or for identity digests we expected to see for that IP/port pair for which the handshake did not succeed but a Heartbleed response was seen (additional 48 digests).
The target list is all IP/port pairs which have ever appeared in a consensus or vote during the time I've been scanning, so some of these may not be in the current consensus or have ever appeared, or they may no longer be vulnerable but not have changed keys properly. There are a bit over 900 vulnerable relays in the latest consensus.
http://charon.persephoneslair.org/~andrea/private/hb-fingerprints-2014041700...
On Wed, Apr 16, 2014 at 06:24:40PM -0700, Andrea Shepard wrote:
The SHA-256 hash of that file, for the sake of stating it under a PGP signature, is:
dadd2beca51d1d5cd7ffe7d3fe3a57200c7de7e136cad23b0691df2fbe84ee3f
FYI guys - The Guardian just published an article about the effect of Heartbleed on the network:
Tor may be forced to cut back capacity after Heartbleed bug
http://gu.com/p/3zfqj On 17 Apr 2014 12:51, "Steve Snyder" swsnyder@snydernet.net wrote:
Roger Dingledine disturbed my sleep to write:
As an ordinary Tor relay operator who's running a directory mirror, is there anything I need to do for my Tor relay about this? I've found this message from the mailing list from a couple years ago:
https://lists.torproject.org/pipermail/tor-talk/2011-October/021936.html
...which seems to imply that the directory operators are separate, and this is nothing I have to take action about. But I wanted to make sure about this, as I couldn't find anything on the Tor FAQ. Apologies if this is answered somewhere else.
Thanks, Hugh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
(Disclaimer: I am just a "regular" supporter and have no great in-depth knowledge about Tor internals.)
there is a difference between a directory *authority* and a directory *mirror*. There are only 8 or so directory authorities in the Tor network which each give a "vote" on each relay. (E.g. Authority A thinks that Relay R should get the Running and Valid flag.)
The posts above are from Tor senior contributors, some running a directory authority. Roger (Tor "founder") originally said that he recommends dirauths to reject (give no flags to relays in their votes and therefore throwing them out of the Tor network) relays affected by the Heartbleed bug.
A directory mirror (a relay with the Directory Mirror option enabled) just mirrors the original votes by the dirauths. Because they are all cryptographically signed, any tampering you could do to the vote could be detected by clients. (Tor clients only trust votes signed by the dirauths' keys.)
Correct me if I'm wrong! :D
On 04/17/2014 04:55 PM, Saint Aardvark the Carpeted wrote:
The SHA-256 hash of that file, for the sake of stating it under a PGP
signature, is:
dadd2beca51d1d5cd7ffe7d3fe3a57200c7de7e136cad23b0691df2fbe84ee3f
Thanks Andrea. 374 of the 380 lines from Sina's file overlap with yours.
I was going to ask something similar, and this sounds like the best kind of answer - 'you don't need to do anything' :D
On 17 April 2014 17:05, Tobias Markus tobias@miglix.eu wrote:
Tobias, thanks so much for the explanation!
Can we do anything to attempt to contact those relay operators that are still affected by Heartbleed?
I might be a little late to the discussion and this has already taken place, just wanted to check.
On Thu, Apr 17, 2014 at 9:47 AM, Saint Aardvark the Carpeted aardvark@saintaardvarkthecarpeted.com wrote:
A lot of relay operators were contacted within 12 hours of the heartbleed bug being published. Of course, not everyone lists their mail address in the directory, so those didn't get contacted.
Tom
AJ B schreef op 17/04/14 20:04:
I'm supposedly running one of the still affected tor-relays and since my relay is also a guard, I'm in the latest blocklist[1] (pre-upgrade fingerprint). I did upgrade the system on April 9th to openssl 1.0.1-4ubuntu5.12 - base system is an ubuntu 12.04.
According to the changelog[2], this should have fixed the heartbleed issue and according to this scanner[3], it should be as well. I did create new keys anyway, but just to be sure: Is the host[4] still affected as given in the blocklist?
Best, Lars __________________________________ [1] https://atlas.torproject.org/#details/9AB511B6894566C1CF56043CE60077D213CF1A... [2] https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12 [3] https://filippo.io/Heartbleed/#tor.kumbier.it [4] tor running on 5.9.165.90:443
Am 17.04.2014 20:08, schrieb Tom van der Woerdt:
On Thu, Apr 17, 2014 at 08:58:46PM +0200, Lars Kumbier wrote:
A router at that IP with identity 9AB511B6894566C1CF56043CE60077D213CF1A1A tested positive for Heartbleed several times, most recently at 2014-04-17 10:19:18, before testing negative at 2014-04-17 18:51:46 (all times UTC). If you rotate the key you should be fine, but that key is potentially exposed.
Andrea Shepard andrea@torproject.org wrote:
No, I don't think that is sufficient. Not only must the onion keypair be replaced, but also the relay's identity keypair. Once the authorities have been told to reject the identity key with the fingerprint shown above, that relay will no longer be included in the consensus, nor will its published descriptor be distributed by them. The reason for rejecting the identity keys as well is that the identity secret key may just as easily have been leaked as the onion secret key. So, Lars, either destroy or rename all of your existing keys for tor, both secret and public, and then restart tor. It will not find existing keys during its startup phase and will therefore generate brand-new keys. After checking for reachability, it will publish a new descriptor. Within a couple of hours, the authorities will begin including the new relay in the consensus and distributing the descriptor. IOW, get rid of *all* the old keys, restart tor, and tor will handle the rest for you.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *or* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Thanks Andrea, Thanks Scott,
Keys have been replaced and I tested the relay with the script on github as well. I guess it was something stupid like forgetting to restart.
For the rest: test your server via the script on https://github.com/wwwiretap/bleeding_onions
Am 17.04.2014 22:58, schrieb Scott Bennett:
On Thu, Apr 17, 2014 at 12:17:02AM -0400, Roger Dingledine wrote:
Thanks Andrea. 374 of the 380 lines from Sina's file overlap with yours.
I've moved moria1 to reject the union of the two lists.
Four other directory authority operators have also blacklisted these keys, and they've now been dropped from the network.
For comparison, we moved from 5421 Running relays earlier yesterday, to 4354 Running relays now. Many of the affected relays were tiny, but there sure were a lot of them.
In the future, when we catch our breath a bit more, I'll start logging the rejected descriptors, and send another round of mail to everybody who set their ContactInfo to let them know to dump their keys and upgrade.
Oh, and since it's going to confuse people, at the same time as this change we also have been cutting relays running Tor 0.2.2.x out of the network: https://trac.torproject.org/projects/tor/ticket/11149 That's currently ~240 relays, but again they're mostly quite small. https://metrics.torproject.org/network.html#versions
--Roger
Dear Andrea,
Could you please elaborate if/how we can use your file on a Tor node? Should we use these as 'ExcludeNodes' rules in the `torrc` configuration files of our Tor nodes? Or is the file merely intended for Tor clients?
Best regards, Yoriz -- Operator of the privshield.com Tor exit node
On 17 Apr 2014, at 03:24, Andrea Shepard andrea@torproject.org wrote:
On Thu, Apr 17, 2014 at 09:20:10PM +0200, Yoriz wrote:
Dear Andrea,
Could you please elaborate if/how we can use your file on a Tor node? Should we use these as 'ExcludeNodes' rules in the `torrc` configuration files of our Tor nodes? Or is the file merely intended for Tor clients?
It's mainly intended for consumption by the directory authorities. You could transform into ExcludeNodes rules for clients if you want, I suppose.
tor-relays@lists.torproject.org
-
AJ B -
Andrea Shepard -
Chris Whittleston -
Lars Kumbier -
Roger Dingledine -
Saint Aardvark the Carpeted -
Scott Bennett -
Steve Snyder -
Tobias Markus -
Tom van der Woerdt -
Yoriz