InCommon Operations Notifications

[Tom Scavo <>]

This important message is being forwarded to all Site Administrators
in the InCommon Federation. Regardless of what SAML software you use,
please read this important message from Scott Cantor of the Shibboleth
Project.


---------- Forwarded message ----------
From: Cantor, Scott 
<>
Date: Mon, Apr 7, 2014 at 11:25 PM
Subject: OpenSSL heartbleed bug / Shibboleth implications
To: 
""
 
<>


A very serious bug in OpenSSL 1.0.1  was announced this afternoon:

http://heartbleed.com/

The actual direct impact on the Shibboleth software packages is
relatively minimal in comparison with the fallout from this. The only
distribution of OpenSSL included with any Shibboleth software is the
Windows SP.

I'm not waiting to produce an actual advisory on this before saying
something because this is a major, major bug and it's public.

I am working to prepare a patch for this (I had no advance warning)
and it will be done as soon as I can produce it. It will *only* apply
to the supported SP version, which is 2.5.3. Anything older than 2.5.0
didn't include an affected OpenSSL version, but any 2.5.x version will
need to be updated to 2.5.3 and then patched.

Any other SP version is still vulnerable if used with OpenSSL 1.0.1,
but I don't control the process of obtaining an update, so that will
depend on your OS or local build.

On the IdP side, this is really a matter for deployment
considerations. We don't provide the actual web server and TLS
implementation for the IdP, so you would need to evaluate your choices
there and determine whether OpenSSL 1.0.1 is implicated. Obviously
pure Java solutions hosting the IdP are not, though some Java
containers can be configured to use OpenSSL as a TLS stack for
performance reasons.

As to the implications, this is a very severe bug, and has apparently
been shown to leak the private key used on the server or client. In
the case of an IdP, that usually means the potential exposure of *the*
signing key because that key usually doubles as a server key for SOAP
traffic on a second port.

In the case of the SP, there is, I think, somewhat less risk because
the SP doesn't generally contact arbitrary servers that might be used
to attack it, but that doesn't guarantee safety.

In the security parlance, keys at risk are basically considered
compromised and the official advice would have to be to revoke and
replace them. I would imagine that federations will be moving on this
to help people understand and react to this, but I felt an obligation
to say something in the interim, given the gravity of the bug.

-- Scott Cantor
Shibboleth Project/Consortium

--
To unsubscribe from this list send an email to