Shutting down middle relays (off-topic)
Regretfully, I have to shutdown my two middle relays (not too big, you won't even notice it :-D), since I am unable to resolve issues with the latest OpenSSL bug. I was able to find upgraded packages for Centos and Fedora that are supposed to address CVE-2014-0224 vulnerability (the change log claims so). However, the Tripwire )SSL_CCS_InjectTest and Qualys onlien tests both disagree. If someone can suggest a resolution that works, I might be able to keep them running, otherwise I see no point in running vulnerable relays until I figure things out. Thanks ...
On Fri, Jun 20, 2014 at 6:47 AM, Tora Tora Tora <tor@allthatnet.com> wrote:
Regretfully, I have to shutdown my two middle relays (not too big, you won't even notice it :-D), since I am unable to resolve issues with the latest OpenSSL bug.
I was able to find upgraded packages for Centos and Fedora that are supposed to address CVE-2014-0224 vulnerability (the change log claims so). However, the Tripwire )SSL_CCS_InjectTest and Qualys onlien tests both disagree.
If someone can suggest a resolution that works, I might be able to keep them running, otherwise I see no point in running vulnerable relays until I figure things out.
Did you restart all applications that are using openssl? If not, they continue to use the old librariers. Best way is to just do a complete restart..
On 06/20/2014 12:47 AM, Tora Tora Tora wrote: [snip]
If someone can suggest a resolution that works, I might be able to keep them running, otherwise I see no point in running vulnerable relays until I figure things out.
Suggestion #1: upgrade to current version of your OS and apply all updates available for that version Suggestion #2: rebuild Tor, using the current version of OpenSSL.
Sorry, I wasn't specific. I am running the latest Centos 6.5, build tor from source (0.2.5.4), have restarted all applications and confirmed the library used with 'lsof'. Since it is running other services, I have not tried to reboot yet. On 06/20/2014 07:45 AM, Steve Snyder wrote:
On 06/20/2014 12:47 AM, Tora Tora Tora wrote:
...
Suggestion #1: upgrade to current version of your OS and apply all updates available for that version
Suggestion #2: rebuild Tor, using the current version of OpenSSL.
You don't have to reboot the server. Just do a "lsof | grep DEL" (and maybe "lsof | grep delete") and restart those services that are using upgraded libraries. That said, there have been a couple of kernel updates in recent weeks (the latest being yesterday), so it is advisable to bite the bullet and reboot. On Friday, June 20, 2014 9:17am, "Tora Tora Tora" <tor@allthatnet.com> said:
Sorry, I wasn't specific. I am running the latest Centos 6.5, build tor from source (0.2.5.4), have restarted all applications and confirmed the library used with 'lsof'. Since it is running other services, I have not tried to reboot yet.
Agreed. I had a few other issues and went the reboot route. On 06/20/2014 at 10:42 AM, "Steve Snyder" wrote:You don't have to reboot the server. Just do a "lsof | grep DEL" (and maybe "lsof | grep delete") and restart those services that are using upgraded libraries. That said, there have been a couple of kernel updates in recent weeks (the latest being yesterday), so it is advisable to bite the bullet and reboot. On Friday, June 20, 2014 9:17am, "Tora Tora Tora" said:
Sorry, I wasn't specific. I am running the latest Centos 6.5, build tor from source (0.2.5.4), have restarted all applications and confirmed the library used with 'lsof'. Since it is running other services, I have not tried to reboot yet.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Basically, I am left to conclude that (1) the latest update on Fedora/Centos does not patch CCS Injection vulnerability or (2) the test is wrong--correction, both Tripwire and Qualys tests are wrong or (3) between a Fedora and two Centos machines, one of which is really just a test machine, all are out of wack or (4) something else is weird. Anyone else ran Qualys test on their "patched" Centos server? https://www.ssllabs.com/ssltest/analyze.html?d=YOUR_DOMAIN_NAME&hideResults=... Anyone else tried Tripwire on their "patched" Centos server? https://raw.githubusercontent.com/Tripwire/OpenSSL-CCS-Inject-Test/master/OS... I would love to see if anyone else is getting the same warnings. Thanks... On 06/21/2014 03:09 PM, Tora Tora Tora wrote:
And now I have tried a reboot. No change. Weird ...
At least the qualys online test is only testing port 443 - could it be that you run your web-server on this port? If you run your web-server with e.g. mod-spdy you also have to update mod-spdy because it is built with its own openssl. This was a problem on my server too (not fedora or Centos tough) Regards Am 22.06.2014 03:36, schrieb Tora Tora Tora:
Basically, I am left to conclude that (1) the latest update on Fedora/Centos does not patch CCS Injection vulnerability or (2) the test is wrong--correction, both Tripwire and Qualys tests are wrong or (3) between a Fedora and two Centos machines, one of which is really just a test machine, all are out of wack or (4) something else is weird.
Anyone else ran Qualys test on their "patched" Centos server?
https://www.ssllabs.com/ssltest/analyze.html?d=YOUR_DOMAIN_NAME&hideResults=...
Anyone else tried Tripwire on their "patched" Centos server?
https://raw.githubusercontent.com/Tripwire/OpenSSL-CCS-Inject-Test/master/OS...
I would love to see if anyone else is getting the same warnings.
Thanks...
On 06/21/2014 03:09 PM, Tora Tora Tora wrote:
And now I have tried a reboot. No change. Weird ...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Yes, both Qualys and Tripwire tests are testing a web server's HTTPS port. Yes, I do run mod_pagespeed on the web server. Alas, I get the same result when I disable it and restart Apache. It is however an interesting direction to investigate, since now I am thinking of examining other modules as well, such as mod_ssl, etc. Does anyone know of a test to run against OpenSSL directly to confirm it is patched (I do not mean checking the change log)? Thanks... On 06/22/2014 03:52 AM, Andreas Reich wrote:
At least the qualys online test is only testing port 443 - could it be that you run your web-server on this port? If you run your web-server with e.g. mod-spdy you also have to update mod-spdy because it is built with its own openssl.
This was a problem on my server too (not fedora or Centos tough)
Regards
Not exactly a direct openSSL-Test, but you could check your specific OR-Port (or any other port you want to check) and see if it's a web-server related problem or not. i find this site quite useful: https://filippo.io/Heartbleed/ if you are checking you OR-Port tick the: "Advanced (might cause false results): ignore certificates" Am 22.06.2014 21:24, schrieb Tora Tora Tora:
Yes, both Qualys and Tripwire tests are testing a web server's HTTPS port.
Yes, I do run mod_pagespeed on the web server. Alas, I get the same result when I disable it and restart Apache. It is however an interesting direction to investigate, since now I am thinking of examining other modules as well, such as mod_ssl, etc.
Does anyone know of a test to run against OpenSSL directly to confirm it is patched (I do not mean checking the change log)?
Thanks...
On 06/22/2014 03:52 AM, Andreas Reich wrote:
At least the qualys online test is only testing port 443 - could it be that you run your web-server on this port? If you run your web-server with e.g. mod-spdy you also have to update mod-spdy because it is built with its own openssl.
This was a problem on my server too (not fedora or Centos tough)
Regards
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
And i completely ignored that this is just testing for heartbleed and not the latest openssl cve. so just ignore my previous mail :) but you could check against different ports with the tripwire python script [1] to check if its a web-server issue or not. i just ran it against my ORPort and it reported 'rejected early CCS' [1] http://www.tripwire.com/state-of-security/incident-detection/detection-scrip... Am 23.06.2014 09:32, schrieb andreas@reichster.de:
Not exactly a direct openSSL-Test, but you could check your specific OR-Port (or any other port you want to check) and see if it's a web-server related problem or not.
i find this site quite useful: https://filippo.io/Heartbleed/
if you are checking you OR-Port tick the: "Advanced (might cause false results): ignore certificates"
Am 22.06.2014 21:24, schrieb Tora Tora Tora:
Yes, both Qualys and Tripwire tests are testing a web server's HTTPS port.
Yes, I do run mod_pagespeed on the web server. Alas, I get the same result when I disable it and restart Apache. It is however an interesting direction to investigate, since now I am thinking of examining other modules as well, such as mod_ssl, etc.
Does anyone know of a test to run against OpenSSL directly to confirm it is patched (I do not mean checking the change log)?
Thanks...
On 06/22/2014 03:52 AM, Andreas Reich wrote:
At least the qualys online test is only testing port 443 - could it be that you run your web-server on this port? If you run your web-server with e.g. mod-spdy you also have to update mod-spdy because it is built with its own openssl.
This was a problem on my server too (not fedora or Centos tough)
Regards
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Right you are. I did just run it against OR port and it tells it rejected early CCS. So it must be web server related problem. Thanks! On 06/23/2014 08:28 AM, andreas@reichster.de wrote: ...
but you could check against different ports with the tripwire python script [1] to check if its a web-server issue or not. i just ran it against my ORPort and it reported 'rejected early CCS'
[1] http://www.tripwire.com/state-of-security/incident-detection/detection-scrip...
On 06/20/2014 06:47 AM, Tora Tora Tora wrote:
Regretfully, I have to shutdown my two middle relays (not too big, you won't even notice it :-D), since I am unable to resolve issues with the latest OpenSSL bug.
I was able to find upgraded packages for Centos and Fedora that are supposed to address CVE-2014-0224 vulnerability (the change log claims so). However, the Tripwire )SSL_CCS_InjectTest and Qualys onlien tests both disagree.
If someone can suggest a resolution that works, I might be able to keep them running, otherwise I see no point in running vulnerable relays until I figure things out.
You have probably figured this out already (you just needs to restart the tor daemon), but you may find the following handy (Fedora, CentOS, RHEL specific): To find out if your openssl package has the fix: rpm -q --changelog openssl | grep CVE-2014-0224 To check which processes are using old libraries, you can use ps plugin for yum (install package yum-plugin-ps to get it) which scripts the lsof trick which has been already mentioned. Usage is simple: yum ps Martin Bukatovic
Yes, I tried below steps, other than 'yum ps'. On 06/21/2014 02:00 PM, Martin Bukatovič wrote: ...
You have probably figured this out already (you just needs to restart the tor daemon), but you may find the following handy (Fedora, CentOS, RHEL specific):
To find out if your openssl package has the fix:
rpm -q --changelog openssl | grep CVE-2014-0224
To check which processes are using old libraries, you can use ps plugin for yum (install package yum-plugin-ps to get it) which scripts the lsof trick which has been already mentioned. Usage is simple:
yum ps
Martin Bukatovic
participants (7)
-
Andreas Reich -
andreas＠reichster.de
-
cbritt＠hush.com -
Martin Bukatovič -
Simon Hanna -
Steve Snyder -
Tora Tora Tora