Probably not, as long as the client can properly respond to a changed server key. For instance, in SSH2, the ssh client "remembers" the server's key on the first connection. The client can be configured to abort server connections when the key changes from a known value, or at the minimum the client is alerted that the server key has changed and has the option to abort, which they should unless they have received instructions otherwise from the sys admin. This flouts the traditional MITM attack.
In SSL, this is prevented by peer certificate verification by the PKI system. Keary Suska Esoteritech, Inc. "Leveraging Open Source for a better Internet" From: "Pascal Janse van Vuuren" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Tue, 13 Nov 2001 08:36:47 +1300 To: <[EMAIL PROTECTED]> Subject: Man in the middle attacks ? Hi all, I'm not a real crypto expert. But, I'm facing a potential (?) problem. I've used OpenSSL to negotiate a secure control channel between two nodes of a private network. The generated private keys are encrypted with a specific password. Naturally, any secure system is only as strong as it's weakest link, but yesterday one of our developers raised the following concern. (I've included his email below) > MITM is particularly an issue for a proxy product, particularly with a nat. > One could write a proxy that provided this functionality! > Consider this situation, a standard man in the middle: > 1 Bob connects to the master. > 2 Mary intercepts the connection, and makes her own connection to the master. > Bob <-----> Mary <-----> Master > Mary is acting like a transparent proxy, and Bob does not know. > 3 Master send Bob the public key. > 4 Mary grabs it > 5 Mary creates her own key pair and send the public one to Bob. > 6 Bob Encrypts a new "session key" with Marys public key, that he thinks is > Masters key. > 7 Mary decrypts the data, re-encrypts it with the Real Qbik master key and > sends it. > 8 Master is happy, and the session starts with the session key. > Mary has all the pieces of the puzzle. > We can easily overcome this by using an extra level of security: Encrypting > with a shared secret the initial public key that is transmitted. Our key pairs are pre-generated, along with the associated, self-signed certifcates. They won't be used in any other instance, but for negotiating this connection. After the control-channel has been negotiated, we do normal user/node authentication, etc. Is this a vulnerability, or something we should be concerned about ? __________________________________________ Pascal Qbik New Zealand ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
