Shibboleth Developers

[Von Welch <>]

In case it helps, my confident understanding of the impact of the
bug is that it allows an active MITM to insert an arbitrary prefix
of their choosing into a SSL connection which will appear to the
server to have made by the client subsequent to any client SSL
authentication.

It does not allow the MITM to eavesdrop on the connection or make
any modifications after the initial prefex.

So I agree that your current understanding is true and what you
describe in your second paragraph (MITM hijacking) is not true.

Von

On 11/16/09 12:59 PM, Scott Cantor wrote:
> 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
> 
>