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:
>
> <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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
