Shibboleth Developers

["Scott Cantor" <>]

Just a bit more on this to chew on...my initial understanding of this bug
doesn't seem to be correct (big surprise) and it doesn't seem to me that
this is going to be too big of a deal after all (wrt Shibboleth). I think
the server-side fix(es) that are coming out now to block renegotiation at
the web server should be mostly sufficient.

Initially I thought I had read that in addition to the chosen prefix attack,
there was some kind of MitM scenario in which the attacker actually ended up
with a negotiated session with the server (and then independently with the
client). That would obviously be a big threat, and requires the client
actively protect itself (or not use TLS, which is where Chad and I were
playing around).

So, if that's not the case, it's really only a threat to the SOAP server,
because the SP isn't going to care about the kinds of CSRF nonsense that
browsers would have to worry about. Our SOAP messaging is just simple in/out
messages and the SP just has to know that the IdP's cert is bound to the
response.

On the IdP side, we also do NOT (in the SOAP case) create sessions based on
the client certificate from the SP. Every message is evaluated in the
context of the certificate that comes in with the request. So the threat is
when that binding is broken, and that's what the fixes that are coming out
prevent by just blocking renegotiation. Also, even if the attacker was able
to "play" his own request, he can't see the response, so it's not really
obvious what you'd accomplish anyway.

So, basically, I'm not sure there's any real hole here given our use of SOAP
and the backchannel, and if there is, I think it's fixed by disabling
renegotiation (already available for at least Red Hat, and in source form
for any other Apache).

Of course, the browser-facing stuff is a whole other mess, but that's
neither our server nor client, and it's likely that any attacks via this
method would be equally a problem through other methods. It's a question of
defending against CSRF.

-- Scott