> Hi,
> On July 25, 2003 01:45 pm, David Schwartz wrote:
> > Hijacks and redirects are all within the scope of what a
> > MITM can do.
> No, they only within the scope of what an attacker can do. The attacker
> becomes a MITM if they can do it without you knowing anything's wrong.
The MITM attack is successful if either he intercepts any of the plain text
or he manages to convince the client that some data came from the server
when it really did not.
> Note "doing it without you knowing anything's wrong" means one of two
> things; one is to manipulate data in such a way that the end parties do
> not know that data has been changed (or created) in transit
> (authenticity), and the other is to be able to read the encapsulated data
> (secrecy).
Exactly.
> > You want a simple definition of a MITM? Here it is -- you think you
> > have:
> >
> > server <-> network <-> client
> >
> > But under a MITM attack, you really have:
> >
> > server <-> MITM <-> client
> >
> > The MITM can do anything he wants from his position, including pass
> > the data unmolested, drop bytes, or change them in both directions.
> > Hijacking and redirection all occur on the wire between the server and
> > the client, so they're all within the scope of a MITM attack.
> >
> > To put it simply, a MITM attack is any attack that can be
> > performed by
> > someone who has complete control over the network between the server
> > and the client, that is, he is in the middle instead of a trusted
> > network.
> >
> > If you think MITM means something else, please present your
> > definition. I have a feeling you'll find it becomes incoherent.
> Your definition is a waste of time, I'm sorry to say. What you're saying
> leads logically to the trivial extreme that any network protocol passing
> through the internet is vulnerable to MITM attacks. If you're happy with
> that definition then this email thread is without point.
Not at all. SSL with comparison of the certificate name to name of the
intended recipient is invulnerable to MITM attacks. All a MITM can do is
prevent data from being exchanged. (And, of course, a MITM can always do
that.)
You are playing games with the word "vulnerable". Yes, any Internet
protocol is vulnerable to a MITM attack in the sense that a MITM can deny
service. But we know that, and we live with that vulnerability.
We would, however, be upset with any cryptographic protocol where a MITM
attack could result in plaintext being compromised.
> SSL/TLS never claims that it can prevent active traffic manipulation by
> undesirable parties, it just claims you'll know something's wrong when
> and if it happens and that all data passing through the SSL/TLS streams
> until that point will be both tamper-free and secret.
How will you know something's wrong if you don't compare the name in the
certificate to the name of the server you intended to speak to? That's not
part of SSL/TLS. SSL/TLS itself is vulnerable to plaintext compromise from a
MITM attack unless you confirm the certificate in some way.
> Our definition of
> MITM is any attack that could passively or actively attack the
> communications such that you are none the wiser (or that you may have
> lost confidentiality or authenticity of data prior to knowing something
> was wrong).
I'm sorry, what good is it if I know that a theif got my credit card
information when I tried to send it to 'www.amazon.com'? All that matters
for a successful MITM attack is that either the MITM obtains some of the
plaintext or fools the client into thinking some data came from a trusted
party when it didn't.
A MITM can deny service. A MITM can make himself known. A MITM can fail to
obtain any plaintext. All of these things are within the scope of what a
MITM can do, they just might fail to make successful attacks.
> FWIW: there are limited MITM possibilities in SSLv2 that fit your
> definition *and* ours, but that's a different issue. It seems that you
> are defining your statement to be correct and working backwards from
> there. The one true MITM attack seems to be this enormous email thread -
> consisting of one side working from a sensible definition of MITM towards
> conclusions, and another working from an tautological conclusion
> backwards towards an unreasonable definition of MITM.
I'm amazed that you would disagree with every published definition of a
MITM I could find.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
