perfSONAR Announcements

[Jason Zurawski <>]

Hi All;

Just to finalize this discussion for others that may not be following closely 
- Roderick's patch below does work for the common/generic use case for 
perfSONAR Toolkits.  If you are using special mods as in Trey's case (for 
puppet or other things), your Apache configuration could be modified and 
require additional changes.  We would still recommend people use the RPMs, as 
they solve the portions the Toolkit manages.

Other note - we have not seen upstream patches for the SSL libraries as of 
yet, so our solution of disabling SSLv3 completely is still the best bet.  

Thanks;

-jason

On Oct 16, 2014, at 8:43 AM, Trey Dockendorf 
<>
 wrote:

> Just FYI I discovered on one of my web servers that setting
> SSLProtocol in a IfModule block to "ALL -SSLv2" and then setting "-ALL
> TLSv1" in a VirtualHost block did NOT fix the problem.  I had to
> modify the SSLProtocol in the IfModule block as well.  The IfModule
> block in my case was set by puppetlabs-apache Puppet module and unsure
> if the behavior of a VirualHost being unable to override that value is
> expected behavior or a bug.
> 
> - Trey
> =============================
> 
> Trey Dockendorf
> Systems Analyst I
> Texas A&M University
> Academy for Advanced Telecommunications and Learning Technologies
> Phone: (979)458-2396
> Email: 
> 
> Jabber: 
> 
> 
> 
> On Thu, Oct 16, 2014 at 2:37 AM, Roderick Mooi 
> <>
>  wrote:
>> Hi all
>> 
>> For 3.3., as I understand these articles, disabling SSLv3 (if that's an 
>> option for you) should mitigate the vulnerability.
>> 
>> https://access.redhat.com/articles/1232123
>> https://access.redhat.com/solutions/1232413
>> 
>> In /etc/httpd/conf.d/ssl.conf
>> remove +SSLv3 from the line:
>> SSLProtocol -ALL +SSLv3 +TLSv1
>> so that it becomes:
>> SSLProtocol -ALL +TLSv1
>> and restart httpd
>> service httpd restart
>> 
>> Regards,
>> 
>> Roderick
>> 
>>>>> On 2014-10-15 at 17:01, Jason Zurawski 
>>>>> <>
>>>>>  wrote:
>>> Greetings;
>>> 
>>> This morning a new vulnerability in the SSLv3 libraries was disclosed.  
>>> The
>>> colloquial name is 'POODLE', keeping up this year's tradition of catchy 
>>> ways
>>> to make you feel better about how you will spend part of your day patching
>>> devices.  A write up is available here:
>>> 
>>> https://access.redhat.com/articles/1232123
>>> 
>>> And the full CVE from Redhat is here:
>>> 
>>> https://access.redhat.com/security/cve/CVE-2014-3566
>>> 
>>> The best way to summarize the risk is that someone attempting a man in the
>>> middle could steal authorization headers from HTTP traffic, and gain 
>>> entry to
>>> a server.  This naturally impacts all servers implementing SSLv3 
>>> protocols,
>>> including the perfSONAR Toolkit.  There are no reports of perfSONAR 
>>> servers
>>> being victimized by this vulnerability, but the risk is a danger for any
>>> communication that uses the vulnerable libraries.
>>> 
>>> As of this morning (Oct 15 2014) there is not an upstream patch available
>>> from CentOS to correct the underlying problem in the libraries for 
>>> servers.
>>> Our development team has taken the steps to modify the Apache 
>>> configuration
>>> on the toolkit to disable use of SSLv3 within the 3.4 release of 
>>> perfSONAR.
>>> A new package is available in our yum repository that addresses this.  We 
>>> are
>>> recommending that netinstall users:
>>> 
>>> - Check your logs to see if the package has been automatically downloaded
>>> yet.  The package names are perl-perfSONAR_PS-Toolkit-3.4-29.pSPS and
>>> perl-perfSONAR_PS-Toolkit-SystemEnvironment-3.4-29.pSPS
>>> 
>>> - If you don't see it automatically downloaded, 'yum update' by hand.
>>> 
>>> A modification to the 3.3.2 release of the LiveCD is being built, but will
>>> take a more time. LiveCD users with concerns can power down, or expedite 
>>> your
>>> migration to the netinstall platform.  There will not be a 3.3 package
>>> released for netinstall users who have not upgraded yet - take this
>>> opportunity to upgrade to 3.4 if possible.
>>> 
>>> We will keep everyone posted on when a patch from the upstream vendor is
>>> released - for now we are confident that the changes we are implementing 
>>> on
>>> the server side will reduce the risk this vulnerability poses.
>>> 
>>> Thanks;
>>> 
>>> -jason