On Mon, Sep 24, 2007 at 03:01:56PM -0700, David Schwartz wrote:
>
> > SSL works just fine to prevent MITM with self-signed certs, provided
> > the client has prior knowledge of the self-signed cert.
>
> Right, but what if they don't?
Create a key management system that makes it so, or deploy a private-label
CA (which is still key management, except that you sweep revocation
under the rug, and pretend it is not a problem, or public revocation
lists, by which point it is often easier to publish a list of valid
unrevoked certs as an online service, but I digress).
> > I strongly disagree. How does the client this "separate detection"
> > step to the protocol handshake.
>
> Once the SSL handshake finishes, the client software enters a "ready for
> secondary authentication" phase. In this phase, secure data is not
> exchanged, but the secondary authentication can proceed.
Not likely to be MITM-proof, without brilliant programmers and infallible
programmers doing the work.
> The server and client then exchange challenges and responses. The responses
> are signed with a key the client can verify and include the SSL "finshed"
> messages, which a MITM cannot tamper with or control.
An MITM generates a new SSL session with each side, so there is a
perfectly evil SSL finish message in hand, the trick is to now securely
mix this into a protocol handshake that involves some other kind of server
credential, but this is difficult. Note if the process does not end up
authenticating the server, MITM resistance is impossible. If the server
can be authenticated, why not via its cert rather than some additional,
equally difficult to manage credential?
Instead of throwing away TLS and rolling your own, I would consider PSK
(still in development) or any other approach that builds on security
features of SSL, rather than inventing a second authentication protocol
and trying to tie it into the SSL handshake.
> Once each side verifies the other side's response to its challenge and sees
> that the 'finished' values match, both the server and client can enter a
> normal data transfer state.
It is not as simple as you describe.
> > Why ask users to invent very difficult
> > to get right security protocols?
>
> If you mean end users, they just use the software.
No, toolkit users (programmers).
> If you mean users of the OpenSSL library, the problem is that the standard
> SSL security model doesn't fit every application. In that case, you have to
> do some of your own security work.
This is where I strongly disagree. I have met very people who I would trust
to design a security protocol (I am not one of the ones I would trust).
> > No, self-signed certs don't defeat MITM detection, they defeat the
> > X.509 PKI trust model for server authentication, so authentication of
> > the server cert needs to use a different trust model.
>
> Whatever you want to call it. The point is, if the client can't validate the
> self-signed cert, you need some other way to make sure the server and client
> have opposite ends of the *same* SSL connection, rather than ends of two SSL
> connections to a MITM. A simple way to do this is to compare each sides
> 'finished' with the other side's 'peer finished'.
No, the challenge is key management. TLS is just fine. If CAs don't solve
key management for you, roll your own key management, but use existing
protocols.
I would like to see GSSAPI support in TLS (so would Microsoft and a
few others). This addresses key management, without requiring secondary
protocols, and ties into the dominant standard intra-mural authentication
system. This would use a certificate-less cipher-suite, but the point
remains that authentication should be within TLS, not an add-on.
Over and out.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
