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

Wed Apr 9 13:00:31 UTC 2014

On Wed, Apr 9, 2014 at 3:31 PM, Geri <toxiroxi at 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 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. :)
>>
>>
>
regards,

--

Kostas.

0x0e5dce45 @ pgp.mit.edu

>
>>> [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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140409/591cf15e/attachment-0001.html>