On Wed, Apr 9, 2014 at 3:31 PM, Geri toxiroxi@gmail.com wrote:

Hi Guys,

im running also a few guard relays and they are listed in here - but today i've patched and restarted all the nodes - so these logs arent actually anymore. what does it mean, available for challenger?

Note that this list is as unofficial as it gets. It's meant more for doing diagnostic metrics stuff, getting aggregate (publicly available) statistics about these relays, etc.

'challenger' is just a script meant for somewhat different purposes; it will eventually produce graphs out of aggregate metrics data: https://github.com/kloesing/challenger

The vulnerable fingerprints file is now somewhat outdated I'm sure. It's useful for doing retrospective metrics inquiries ("what part of the network in terms of bandwidth did the vulnerable relays comprise three days ago?"); don't worry too much (and sorry if the initial email sounded alarm bells, that was not the intention, at all.)

another thing: is it a real good idea to post public which ip/ports are vulnerable to that openssl bug? in my opinion it is much more getting dangerous for those relays being attacked - the information which of the relays are still vulnerable should be treatened more carefully to minimally get rid of the scriptkiddies trying to attack.

The scripts for testing out relays and any kinds of arbitrary web services are available publicly (see: https://blog.torproject.org/comment/reply/843/55536 ); this would be a quintessential instance of 'security through obscurity'; people need to do their diagnostics. But I agree that providing PoC's all over the place does not reduce the number of scriptkiddie attacks.

furthermore - how can i check if my tor nodes are now safe now?

If you upgrade your openssl and then restart tor, you're fine. I guess you can use of them unofficial tools which do not guarantee anything. There's a python script you might try running,

http://s3.jspenguin.org/ssltest.py as of now, it says 'access denied', here's a copy: http://ravinesmp.com/volatile/ssltest.py

Be careful running random scripts from the internet, of course. This whole thread is not meant to convey things in any kind of official capacity (quite the opposite.)

thanks!

2014-04-09 5:41 GMT+02:00 Kostas Jakeliunas kostas@jakeliunas.com:

...

On Wed, Apr 9, 2014 at 3:49 AM, Kostas Jakeliunas <kostas@jakeliunas.com

...

wrote:

...

Making a separate thread so as not to pollute the challenger[1] one.

Roger: you wanted to know (times are UTC if anyone cares),

[22:08:35] [...] we now have a list of 1000 fingerprints, and we could

...

...

pretend those are in the challenge and use our graphing/etc plans on them [22:08:45] they happen to be the relays vulnerable to our openssl bug [22:11:43] "what fraction of the tor network by consensus weight are they?" [22:11:49] "over time"

Given them[2], the challenger (with minimal changes to fix downloader and to make Onionoo not falter)[4] will spit out the following results:

http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.j...

http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.jso...

http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.jso... [uh oh, this one's empty. Why is it empty? Didn't look into it.]

http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json

The 'combined-weights.json' is probably the one you might be after. But that's all I did for now.

You also said that these aren't all the vulnerable relays that there are out there. You linked to a more complete list[3], but it has some typos, etc. I haven't done anything with it, maybe someone will take over, or I will do something later on.

fwiw, I ran the script for the larger batch of vulnerable relay fingerprints available[5], and these are the resulting files:

http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-bandwidth.j...

http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-weights.jso...

http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-clients.jso... [empty]

http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-uptime.json

The whole thing (with the sleep delays included) took ~84 minutes to run.

(It may be that Onionoo doesn't know (at least not in a way that allows it to provide the relevant info here) about the majority of those fingerprints (?), so not sure if this is useful much, but it can't hurt.)

Okay, I'm probably done running and patching code I'm not familiar with for the time being. :)

regards,

--

Kostas.

0x0e5dce45 @ pgp.mit.edu

...

...

https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e94...

https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c258...

https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93...

[5]: fingerprints ready for challenger: http://ravinesmp.com/volatile/challenger-stuff/1648_vuln_fingerprints.txt