Re: Man in the middle attacks ?
[In response to Pascal Janse van Vuuren, 13 Nov 2001] The "RSA Security's Official Guide to Cryptography" has pretty good discussion of various kinds of attacks and how they can be dealt with. See p108 for a discussion on using Diffie-Hellman based key exchange. (Doesn't mention OpenSSL, though. Or "open" anything.) === JJ = __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Man in the middle attacks ?
"Pascal Janse van Vuuren" <[EMAIL PROTECTED]> writes: > 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. It's hard to answer your question because you don't say whether you're using SSL or just some ad-hoc protocol with OpenSSL for your crypto. For the sake of the rest of the discussion I'll assume you're using SSL. If you've invented your own protocol you probably have bigger problems than this. > Is this a vulnerability, or something we should be concerned about ? The usual way SSL prevents man-in-the-middle attacks is by having the client check the server's certificate against a trusted CA. If you're using self-signed certificates and the client doesn't have any independent knowledge of the server's certificate you certainly are vulnerable to a man-in-the-middle attack. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Man in the middle attacks ?
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]
Re: Man in the middle attacks
You are correct about IE 5.x not checking the CRL by default, but be careful in using this. I recently found a bug with Windows 95, 98, and NT where if you checked the box in Internet Options to tell IE to verify the CRL, it would do so, but if a CRL link was provided, all other certificate verification would be bypassed - including the certificate CN/hostname comparison, making the man in the middle attack very easy to pull off. Essentially, you would think you are getting more security, but you are losing it instead. This would only work for these OS/browser combinations, but that is a hefty piece of the web surfer pie. Win2K did not have this problem. MS was notified, but I haven't checked for patches since then (I don't use IE - or Window$, if I can help it). Just thought you would want to know. L > On Mon, Feb 05, 2001 at 09:12:42AM -0500, Michael T. Babcock wrote: >> Greg Stark wrote: > >> > The attack you are referring to is defeated by the client checking >> > the identity that is contained in the certificate. I do not know >> > why you are so sure that this checking is not normally done. IE and >> > Netscape Nav. do it, for example [...] > >> IE 5.x does not, by default, check to see if the server or signer >> certificate is revoked. These must be turned on in the advanced >> options. This is a real problem because it means an attacker can >> break into a web site, steal their certificates and do what they >> wish to do without the certificate owner able to do anything about it >> because they can't revoke their certificates in a meaningful way. > > That should be an exceptionally rare circumstance and, presuming > the secret key is passphrase protected (all of ours are), still > requires that the attacker steal the passphrase as well as the secret > key. The certificates are useless without those. The secret key > should be tougher to steal (root access on the box or maybe stored in > a smart card where it can be used but not read). The passphrase is > normally only entered when the server is started. > > Alternatives... You could try to steal the key out of memory > (where it is no longer protected) but you have to find it first, or > you could trojan the box to sniff the passphrase and then force the > server to restart. An advanced cracker/intruder could do it... But > he's probably got better/easier things to do. > > Gee... If you have reached that level of authority on the box, > why bother with a man in the middle attack at all? You have the end > point. Game over! Drop in a root kit, hide yourself real well, and > really do some REAL damage, no MITM required! You got that level of > authority, trojan the web server! That's a hell of a lot easier and > yields a much better return than attempting very iffy MITM attacks. > That could even defeat the cases where you can NOT obtain the secret > key (smart cards). > > The threat you describe is not a realistic threat since once > an individual can achieve your base requirements (level of authority > capable of stealing certificates, secret keys, and passphrases) he > already has done far more damaged to you and is capable of continuing > to do far more damage to you on your own box than he could with those > purloined keys and certs. > > Not that it should be totally dismissed, mind you. PKI is > intended to provide support for revocation lists and such and what you > describe is a limitation in the application implimentation, not a > limitation in the SSL protocol. The information (just like CN and the > start and end dates) is there (well, you have to access a CRL to check > for revocation). It's up to the end point application to check it and > what to do with it when it fails. > > So... In the end, what you describe is not an SSL problem but > an application problem. Just like Kurt Seifert's paper describes MITM > attacks that depend on user stupidity (ignoring warnings about CN not > matching or expired or unknown CA). > > The cryptography and the protocols are fine. It's what we do > with them as end users. As Bruce Schneier likes to say "If you > believe that cryptography can solve your problem, you don't understand > your problem and you don't understand cryptography." > >> -- >> Michael T. Babcock (PGP: 0xBE6C1895) >> http://www.fibrespeed.net/~mbabcock/ > > Mike > -- > Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] > (The Mad Wizard) | (678) 463-0932 | > http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist > believes we live in the best of all > PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of > it! > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] >
Re: Man in the middle attacks
On Mon, Feb 05, 2001 at 09:12:42AM -0500, Michael T. Babcock wrote: > Greg Stark wrote: > > The attack you are referring to is defeated by the client checking the > > identity that is contained in the certificate. I do not know why you are so > > sure that this checking is not normally done. IE and Netscape Nav. do it, > > for example [...] > IE 5.x does not, by default, check to see if the server or signer certificate > is revoked. These must be turned on in the advanced options. This is a real > problem because it means an attacker can break into a web site, steal their > certificates and do what they wish to do without the certificate owner able to > do anything about it because they can't revoke their certificates in a > meaningful way. That should be an exceptionally rare circumstance and, presuming the secret key is passphrase protected (all of ours are), still requires that the attacker steal the passphrase as well as the secret key. The certificates are useless without those. The secret key should be tougher to steal (root access on the box or maybe stored in a smart card where it can be used but not read). The passphrase is normally only entered when the server is started. Alternatives... You could try to steal the key out of memory (where it is no longer protected) but you have to find it first, or you could trojan the box to sniff the passphrase and then force the server to restart. An advanced cracker/intruder could do it... But he's probably got better/easier things to do. Gee... If you have reached that level of authority on the box, why bother with a man in the middle attack at all? You have the end point. Game over! Drop in a root kit, hide yourself real well, and really do some REAL damage, no MITM required! You got that level of authority, trojan the web server! That's a hell of a lot easier and yields a much better return than attempting very iffy MITM attacks. That could even defeat the cases where you can NOT obtain the secret key (smart cards). The threat you describe is not a realistic threat since once an individual can achieve your base requirements (level of authority capable of stealing certificates, secret keys, and passphrases) he already has done far more damaged to you and is capable of continuing to do far more damage to you on your own box than he could with those purloined keys and certs. Not that it should be totally dismissed, mind you. PKI is intended to provide support for revocation lists and such and what you describe is a limitation in the application implimentation, not a limitation in the SSL protocol. The information (just like CN and the start and end dates) is there (well, you have to access a CRL to check for revocation). It's up to the end point application to check it and what to do with it when it fails. So... In the end, what you describe is not an SSL problem but an application problem. Just like Kurt Seifert's paper describes MITM attacks that depend on user stupidity (ignoring warnings about CN not matching or expired or unknown CA). The cryptography and the protocols are fine. It's what we do with them as end users. As Bruce Schneier likes to say "If you believe that cryptography can solve your problem, you don't understand your problem and you don't understand cryptography." > -- > Michael T. Babcock (PGP: 0xBE6C1895) > http://www.fibrespeed.net/~mbabcock/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Man in the middle attacks
Greg Stark wrote: > The attack you are referring to is defeated by the client checking the > identity that is contained in the certificate. I do not know why you are so > sure that this checking is not normally done. IE and Netscape Nav. do it, > for example [...] IE 5.x does not, by default, check to see if the server or signer certificate is revoked. These must be turned on in the advanced options. This is a real problem because it means an attacker can break into a web site, steal their certificates and do what they wish to do without the certificate owner able to do anything about it because they can't revoke their certificates in a meaningful way. -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Man in the middle attacks
I am replying to -users even though the original post was sent to -dev. First, a nit on terminology. The protocols should be referred to as the SSL protocols or perhaps more accurately the SSL/TLS protocols, not the openssl protocol. OpenSSL is an implementation of these protocols. The attack you are referring to is defeated by the client checking the identity that is contained in the certificate. I do not know why you are so sure that this checking is not normally done. IE and Netscape Nav. do it, for example, The mere possession of some valid certificate is not in and of itself likely to be good enough for any SSL-secured protocol, and certainly not for HTTPS. See RFC 2818 (http://www.rfc-editor.org/rfc/rfc2818.txt). I can conceive of some scenarios where the only checking needed to trust a peer is that the peer's certificate is rooted at some specially-trusted CA, but this is clearly a specialized scenario. In the case of OpenSSL, no such checking is performed, because it is not appropriate. The SSL protocol is always used by some higher layer protocol, such as HTTP over SSL. The SSL protocol merely provides for certificate-based authentication. It is the job of this higher-level protocol to decide what identifying information in the certificate must be checked. OpenSSL faithfully adheres to this. It checks the validity of the certificates as much as it possibly can, but it cannot sensibly enforce a check on the identity contained in the certificate since these can vary from application to application. It can, and does, provide ample hooks for developers to get at this identity information to complete the steps needed to authenticate the peer. This information is typically contained in the subject name and sometime also in the extensions. Perhaps the only complaint one *might* make is the absence in OpenSSL of an example to perform the most common identity check, that the hostname contained in the CN field of the subject name matches the hostname the client intended to connect to. I am not complaining, though. _ Greg Stark Ethentica, Inc. [EMAIL PROTECTED] _ - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 04, 2001 8:16 AM Subject: Man in the middle attacks > I have been thinking that the openssl protocol might be vulnerable to man in the middle attacks. > > From a general standpoint here is what I am thinking and I will use an https example although I think it is apparent that any protocol is vulneable. And I will admit that I may be out to lunch here too. > > Suppose we set up the classic Man in the Middle attack: > > <> <> > > In this situation our takes the website for example and fully duplicates it including going to the effort of going to say Tawtie and getting a valid cert. > > A connection like <>will in fact look identical to <>and it is clear that our can extablish a connection to the just as a can. > > I don't see how the openSSL protocol prohibits this or even accomodates either the or the knowing that it is even taking place.. > > One way to address this would be to take the IP address of the and the and encode this within the message being transmitted - and this may be done. But this STILL does not solve the problem. Since the in general will not know the IP address of the host, our in the middle can still completely mimic the actions of the . Furthermore, in general most clients may in fact live behind a firewall and this would mean the will be talking literally to millions of at 192.168.1.x. > > I think there _may_ be a way to address this. In the foregoing situation the had to obtain a valid cert from a CA. The https protocol just expects a valid cert to be there and says nothing about who this cert was issued to. What is to stop a repressive governement like say Iraq for instance from funneling 100% of their citizens IP traffic through a proxy that inserts "THEIR" cert in place of the cert in the authentication process. > > What has to take place is that the software that runs in the client computer must issue some sort of message indicating "who" it is establishing a connection with in all cases. Then it _could_ come up and say something to the effect of "secure connection established to "Iraq Proxy" and presuming the code the is running has not been tampered with - at least the would know. > > As it stands now - I think there is ZERO in the way of security against this kind of attack and I don't even think the can find out if a in the middle is really there. > > SUppose the IP address of the computer doing the encryption is encoded into the record. Then a could potentially keep a list of that may be set up and simply refuse to talk to them. Note that any message sent to an intended behind such a can be modified by the unless the somehow is able to obtain their own public key with
