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: <client> <----> <proxy> <----> <host> In this situation our <proxy> takes the <host> 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 <client> <----> <host> will in fact look identical to <client> <----> <proxy> and it is clear that our <proxy> can extablish a connection to the <host> just as a <client> can. I don't see how the openSSL protocol prohibits this or even accomodates either the <client> or the <host> knowing that it is even taking place.. One way to address this would be to take the IP address of the <host> and the <client> and encode this within the message being transmitted - and this may be done. But this STILL does not solve the problem. Since the <client> in general will not know the IP address of the host, our <proxy> in the middle can still completely mimic the actions of the <host>. Furthermore, in general most clients may in fact live behind a firewall and this would mean the <host> will be talking literally to millions of <clients> at 192.168.1.x. I think there _may_ be a way to address this. In the foregoing situation the <proxy> 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 <host> 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 <client> is running has not been tampered with - at least the <client> 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 <host> can find out if a <proxy> in the middle is really there. SUppose the IP address of the computer doing the encryption is encoded into the record. Then a <host> could potentially keep a list of <proxys> that may be set up and simply refuse to talk to them. Note that any message sent to an intended <client> behind such a <proxy> can be modified by the <proxy> unless the <lient> somehow is able to obtain their own public key with which the <host> can encrypt the message. But in my mind it is not clear how this can be accomplished because in the senerio above... what would stop say Iraq from intercepting the publication of a public key and simply acting as a CA and subsituting their own... on the fly? If repression like this is attempted then I think generally there is not much that the <client> can do. Any attempted communication with the outside world can be intercepted and mimiced. Howver one can argue that on the <host> side there can be trust and the <host> can be programmed in some cases to deal with a list of known dirty <proxies>. I hope this is pertinant. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
