On Mon, Nov 30, 2009 at 10:50 AM, Rob Crittenden <rcrit...@redhat.com> wrote:
> I'm considering how to handle SSL re-negotiation in the Apache NSS provider
> mod_nss to handle the SSL client-initiated handshake bug.
>
> NSS provides a callback, SSL_HandshakeCallback(), which according to the
> docs is called when an SSL handshake has completed.
>
> So let's say I have the following:
>
> SECStatus FailureHandshakeCallback(PRFileDesc * socket, void *arg)
> {
> return SECFailure;
> }
>
> SECStatus InitialHandshakeCallback(PRFileDesc * socket, void *arg)
> {
> return SSL_HandshakeCallback(socket, (SSLHandshakeCallback)
> FailureHandshakeCallback, NULL)
> }
>
> When I create a socket I'll set the handshake callback to
> InitialHandshakeCallback(). Once the initial SSL handshake is done this will
> then reset it to the failure mode, so that if any subsequent handshaking
> happens it will fail.
>
> The Apache configuration lets one have per-location configuration, for
> example requiring SSL client auth only for a subdirectory. To do this it
> updates the SSL options on the socket and calls SSL_ReHandshake().
>
> What I was thinking about doing here is setting those options, then setting
> the callback handler back to InitialHandshakeCallback(). This should allow
> the server-initiated handshake to succeed and prevent any other handshaking
> (unless we again want to restart it from the server).
>
> Does this (1) seem like a reasonable approach and (2) will it protect
> against the client rengotiation issue?
>
> thanks
>
> rob
A server-initiated handshake is also vulnerable to an MITM. The
attack scenario is a bit more complex, but it's doable. (More
specifically, as soon as a HelloRequest is sent from the server,
perhaps as a request to "upgrade" the authentication level, that
HelloRequest can be sent from MITM to the client, which possibly has a
persistent connection going to the MITM. At that point, the
protocol's broken.)
Apache's willingness to do per-Location/per-Directory/per-Whatever
renegotiation for client authentication is what forced us into this
situation in the first place. I believe it should be considered a
bug, and fixed on Apache's side. Unfortunately, few others agree.
-Kyle H
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
