> 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? > It can then > check for the right public key, or the right certificate fingerprint > (more convenient via the OpenSSL API than extracting public keys, ...) Sure, if it knows what the "right public key" is. > > Basically, in this case you can use the original SSL authentication to > > bootstrap a separate MITM detection step. I strongly recommend > > doing this in > > a custom application if you use SSL in a way that prevents its > > normal MITM > > detection from being effective. > 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. 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. 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. > Why ask users to invent very difficult > to get right security protocols? If you mean end users, they just use the software. They don't care how it works, they just need it to work. We aren't talking about HTTP here, we're talking about specialized uses of SSL where the standard PKI trust model doesn't work. 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. > > In this case, the OP was defeating SSL's normal MITM detection > > because his > > server certificate does not contain a name vouched for by a trusted CA. > > That's why I suggested an alternate means of MITM detection. > 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'. A MITM cannot make the 'finished' messages match and still retain the ability to intercept or modify the data. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
