"What fraction of the tor network by consensus weight are the openssl-vulnerable relays?"
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.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. [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/38d88bcb1136f97881f81152d3d883c4e94... - https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c258... - https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93... -- kostas / wfn 0x0e5dce45 @ pgp.mit.edu
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. :)
[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/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 -- Kostas. 0x0e5dce45 @ pgp.mit.edu
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@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. :)
[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/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
--
Kostas.
0x0e5dce45 @ pgp.mit.edu
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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
[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/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
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.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, this is a beyond-hacky-could-fail quick thing[5] that gives you fingerprints of relays that were vulnerable in a recent vulnerable-relay-file[6] (ideally it would pull those vulnerable relays from some online source) that are in any consensus provided (default is latest consensus available in Tor Metrics): http://ravinesmp.com:7777/ Provide consensus using "/consensus/%Y-%m-%d %H:%M:%S" (standard UTC date format). Consensuses are available since ~2008. So e.g. current vulnerable relay fingerprint list intersected with an older consensus when there were heartbleeding openssl versions: http://ravinesmp.com:7777/consensus/2012-10-20%2016:00:00 (" http://ravinesmp.com:7777/consensus/2012-10-20 16:00:00") There's also a nice concise Nick's script to get the % of network bandwidth of any given list of relay fingerprints (bandwidth is the one in the consensus, so parts of it will be self-reported and parts of it will be measured)[7]. [5]: https://gist.github.com/wfn/11070928 [6]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b [7]: https://gist.github.com/nmathewson/10309480 [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/38d88bcb1136f97881f81152d3d883c4e94... - https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c258... - https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93...
participants (2)
-
Geri -
Kostas Jakeliunas