Shibboleth Developers

["Scott Cantor" <>]

Lukas Haemmerle wrote on 2009-11-16:
> I just read about the OpenSSL Renegotiation issue and were wondering
> whether this affects the Shibboleth SP. In particular, if X.509
> clientAuth is enabled on a directory/location basis and not for the
> whole VirtualHost, renegotiation is used if I remember correctly.
> So, this could affect some installations if they upgrade their openssl
> version whose default then is set to not use renegotiation.
> 
> Infos: http://openssl.org/news/secadv_20091111.txt
> http://isc.sans.org/diary.html?storyid=7543

Note https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-3555

There's a mod_ssl patch out for Red Hat that apparently blocks
client-initiated renegotiation. I know that in the past we had setups that
for some reason used reneg to handle client certs, but I can't recall why
that was. We must have been trying to accommodate single vhost setups at the
time, but I remember documenting how to limit client-cert authn to the /AA
path.
 
I'll probably do some testing on my IdP with this Red Hat patch and see if
anything breaks, but that seems like a good work-around at the moment.

Note that the server can protect itself to some degree, but the client
can't. So in effect, it's still broken from the PoV of the SP and there's
really not much we can do about that.
 
I suspect a near term work-around may be to start requiring signed
assertions over the back-channel as a way of guaranteeing provenance for the
data. There's not currently a way to force the SP to require protocol-layer
signing, but most of the use cases today involve assertions. The exceptions
without a good workaround would be things like back-channel logout, which is
a denial of service thing, but not anywhere near as serious.

Anyway, we need more testing and input and then probably need to write up a
page about it.

-- Scott