Please stop writing such non-sense garbage... ;-)
The SSL request sent by the browser doesn't reach your server, it is
captured by the sniffer (if you want to understand how, then get the
dsniff package, reade the source, the docs, and try it). The sniffer sends
a self-signed certificate to the browser, which displays a warning to the
user, which in turn accepts the certificate (the real flaw is exactly
here). From now on, the browser has accepted the connection, the user
thinks the data is securely transmitted, since the browser has performed
the SSL handshake. The user can even see the locked icon on his
screen. The sniffer acts as a server here.
The sniffer then sends a SSL request to your server, through your SSL
accelerator, they both perform the SSL handshake, the sniffer gets your
real certificate, your cryptoboard is okay (the sniffer acts as a client
here), but the sniffer don't have to send the real certificate to the
browser, since this part of the handshake has already been performed.
>From now, the sniffer receives all the traffic sent by the browser in SSL,
sends everything to your server (through your cryptoboard) in SSL,
receives any reply from your server (through your cryptostuff) in SSL, and
sends everything to the browser in SSL. But all the data is simple
cleartext in the sniffer memory, since the SSL is performed between the
browser and the sniffer, and between the sniffer and the server, and not
from the browser to the server.
If you think you protected yourself using a cryptoaccelerator, then you
missed something: the dumb user.
On Tue, 19 Dec 2000, Thomas Nichols wrote:
> This is competely wrong. You fail to see the network topology. The SSL request would
> still have to go through MY SSL accelerator in order to reach the actual server.
> There's no other route to take. Even if what you suggest would be attempted, or even
> possible, the user's browser would get the correct certificate, albeit a second cert.
>
> Erwann ABALEA wrote:
>
> > No. A MITM attack can also occur even if you're using a crypto
> > accelerator. The only way this attack cannot occur is if you ask for
> > client authentication.
> >
> > - the sniffer generates a self-signed certificate with the same name as
> > your server cert (www.secure.site)
> > - the browser wants to connect to your site (www.secure.site), but
> > instead connects to the sniffer (sniff.evil.domain)
> > - the sniffer negociates the SSL session with the browser, by presenting
> > the newly generated self-signed cert
> > - the browser gets a warning claiming that the cert is invalid
> > - the attack goes there: the user only clicks OK because he doesn't know
> > anything about PKI
> > - the sniffer then establishes a SSL session with your server, using your
> > crypto accelerator if you want. In this exact case, the sniffer only
> > acts as a valid customer browser, so this connection is perfectly
> > valid.
> > - the sniffer then routes all the data between the beowser and the
> > server, but all this data is cleartext in it's own address space, and
> > ciphered between (browser, sniffer) and (sniffer, server).
> >
> > So your cryptoboard cannot do anything against a dumb user being sniffed.
> >
> > Again: the attack has nothing to do with the server, or the cryptoboard
> > the server might have.
> >
> > On Tue, 19 Dec 2000, Thomas Nichols wrote:
> >
> > > Quite the contrary. There is no method available for an MIIM to replace the SSL
> > > cert as it can only reside where it is and is linked to private IP servers behind
> > > the accelerator.
> > > Erwann ABALEA wrote:
> > >
> > > > On Tue, 19 Dec 2000, Thomas Nichols wrote:
> > > >
> > > > > The best method is to not have the SSL certificate and key on the server to
> > > > > begin with. I use a non-ip based ssl accelerator.
> > > >
> > > > This not a protection against this attack.
> > > >
> > > > This attack doesn't steal the private key of the host, it only relies on
> > > > the "dumbness" of the users, which only clicks "OK" when a warning pops up
> > > > (considering that the user doesn't know anything about PKI).
> > > >
> > > > This attack is not against SSL, or SSH, but only against the users.
--
Erwann ABALEA
[EMAIL PROTECTED]
RSA PGP Key ID: 0x2D0EABD5
------
Common sense isn't.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
