Shibboleth Security Advisory [23 January 2018]

[Cantor, Scott]

On 1/24/18, 9:04 AM, "users on behalf of Mark Cairney" <users-bounces at shibboleth.net on behalf of Mark.Cairney at ed.ac.uk> wrote:

> What (practically) does this mean and what's the best way to protect against it?

The backchannel should not be used. Any use of SOAP that's really needed should be handled over port 443 and secured (in somewhat limited fashion) by signing and encrypting messages. That's largely automatic with the latest IdP and SP software. Most sites don't need it and shouldn't support it.
 
> As we upgraded from a legacy V2 setup we are currently using the same
> keypair for backchannel/signing/encryption. Should we migrate to using
> separate keypairs for each and is there a way to generate these
> independent of the install script as you can with the SP?

You can use any tools to do it that produce the supported formats (which are mostly PEM files these days in practice). I use OpenSSL in most cases.

Migrating to a different key won't help with ROBOT unless you don't support artifact resolution. As long as a vulnerable key is sitting in the IDPSSODescriptor, the potential threat exists if a similar attack surfaces. Splitting the keys helps with bugs like Heartbleed that actually expose the key by limiting the damage.

What you *should* do is eliminate the back channel entirely and avoid securing SOAP with a TLS key. That's the only real solution. I did the former, quite easily for the most part, when I upgraded to V3.

> Alternatively can this be mitigated with an appropriate cipher suite configuration at the webserver level?

"This" being ROBOT, yes, according to them.

This advisory isn't really about ROBOT in the end. It's about an opportunity to stop something people should stop. This is just the motivator.

-- Scott