[tor-relays] "What fraction of the tor network by consensus weight are the openssl-vulnerable relays?"

[Geri]

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?

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.


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

thanks!




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

> On Wed, Apr 9, 2014 at 3:49 AM, Kostas Jakeliunas <kostas at 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.json
>>   -
>> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.json
>>   -
>> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.json
>>   [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.json
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-weights.json
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-clients.json [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. :)
>
>
>
>> [1]:
>> https://lists.torproject.org/pipermail/tor-relays/2014-April/004214.html
>> [2]: http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt
>> [3]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b
>> [4]: commits:
>>   -
>> https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e9480188
>>   -
>> https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c25889dfc
>>   -
>> https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93909ae
>>
>
> [5]: fingerprints ready for challenger:
> http://ravinesmp.com/volatile/challenger-stuff/1648_vuln_fingerprints.txt
>
> --
>
> Kostas.
>
> 0x0e5dce45 @ pgp.mit.edu
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140409/dfbc4103/attachment.html>