OpenSSL heartbleed bug / Shibboleth implications

Cantor, Scott cantor.2 at
Tue Apr 8 13:15:10 EDT 2014

On 4/8/14, 12:54 PM, "Rich Graves" <rgraves at> wrote:

>If you are using the native SP, which has process/privilege separation
>from the web server, I would not worry about replacing the SP keys. The
>vulnerability should only have exposed memory accessible to the httpd
>process. If you were using something like simpleSAMLphp
> then there could possibly be some concern.

This isn't the case, as Ian explained. This isn't a typical TLS issue,
where the server is the only vulnerable point. The heartbeat extension
flows bidirectionally and allows a server to attack a client that connects
to it. In the SP's case, that means an IdP or metadata endpoint could be
subverted to steal the client's key.

Is that likely? Much less than in the IdP case, because it means not only
did somebody have to subvert one of those servers, but also mount an
active MITM attack against the SP connecting to something so that it
connects to the attacker wielding a key stolen from the subverted endpoint.

So yeah, it's not anything close to the threat the IdP would be under, but
it's not zero, and it definitely does not involve privilege separation.
That just doesn't help here.

>I would replace your public-facing SSL keys/certificates if I were you.
>That's relatively easy.

Yeah, totally this (and the rest of the advice).

>Consider invalidating any especially long-lived cookies. Maybe change
>internal admin passwords too, if they could have touched httpd processes
>also reachable by
> the public. Attack a server that's still vulnerable and see what you can

-- Scott

More information about the users mailing list