Shibboleth Developers

[Peter Williams <>]

There is a long history to ssl renegotiation, with and without cert
based client auth using the cac/smartcard. Not everyone in the world
ever wanted an socket provider centric security layer (they wanted it
app controlled) and some folks wanted consumers  to have no control
over crypto rekeying (and thus the work factor of attacking the
cipherstream or cryptostate)

  there was a time when navigator did a full handshake every n mins,
the 2nd and nth instances per connection being tied to each other and
the initiating handshake by the (encryption not hmac derived) data
origin authentication properites of the record layer protocol.

There was the explicit expectation that internal socket layer entities
could signal non app data to each other, requiring " payload
injection" into the record layer. Think of it as the ssl2 era
extension model that, unlike ssl3/tls hello based negotiation, is not
tied to the handshake protocol. It was the insertion point for pacs
and key release/escrow, for example.

Understand that ssl3 took alot of design (both stuctural and
ciphersuite) input from NSA, In return for navigator being accredited
for large dod office system procurements - presented as a model for
corporate needs.

Should see lots of webapps now focus on asking: so just what are our
rekeying requirements? And this will be including saml sps.


On Nov 16, 2009, at 11:21 AM, "Von Welch" 
<>
wrote:

>
> 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
>>
>>
>