> David Schwartz wrote:
> > Hijacks and redirects are all within the scope of what a
> > MITM can do.
> That's a Humpty-Dumpty argument, not the definition used by
> cryptographers.
> You're simply confused, or are immune to education.
No, I am not at all confused. You are confused and immune to education and
based on the number of emails I've gotten about this thread from
professional security people, I'm pretty sure I'm right.
> > You want a simple definition of a MITM? Here it is -- you
> > think you have:
> Simple definitions are often wrong, as is yours.
> > 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.
> No, mounting a MITM attack requires that the client be _unable to
> detect it_. The MITM cannot correctly negotiate the SSLv3 handshake,
> and cannot change bits without being detected.
No. Mounting a MITM attack requires nothing at all except the ability to
intercept and modify network traffic. Mounting a *successful* MITM attack
requires that you either obtain some of the plaintext *or* convince the
client that some data came from the server when it really didn't.
> You had been describing a completely different attack, in which
> the endpoint of the SSL channel is a hostile party. Obviously,
> this could turn out badly.
That's a MITM attack. One of the things a MITM can do is be the endpoint
for two separate SSL connections rather than the one from server to client
that you think you have. That's a classic MITM attack.
> I'll repeat this -- SSLv3 was specifically designed to be proof
> against MITM attack. And it is. You can snoop all you want,
> you won't get the master shared secret and you won't be able
> to change bits in either direction without detection.
The MITM can run separate SSL sessions to both the server and the client
and proxy the plaintext between the two connections. That's well within the
scope of what a MITM can do.
SSLv3 only provides protection against a MITM attack if one of two things
is the case:
1) The end that cares about authentication (the client for HTTPS) compares
the name in the certificate against the name of the server it wants to talk
to, OR
2) Only trusted parties have access to certificates signed by any CA the
end that cares about authentication trusts.
The Internet security model employs option 1. Without it, there would be no
protection whatsoever from a MITM who closes both SSL sessions and proxies
the plaintext.
Lest anyone thinks I'm making this up, I'll offer the following links all
of which support my definition that a MITM attack occurs when the attacker
has total control over the network:
http://www.wordspy.com/words/maninthemiddleattack.asp
"A computer security breach in which a malicious user intercepts - and
possibly alters - data traveling along a network. (Also: man-in-the-middle
attack.)
Backgrounder:
This exploit also goes by the name TCP hijacking (where TCP is a method by
which data is transmitted across a network). "
http://www.wikipedia.org/wiki/Man_in_the_middle
"In cryptography, the man in the middle attack is an attack where the
attacker is able to read, and possibly modify at will, messages between two
parties without letting either party know that they have been attacked. The
attacker must be able to observe and intercept messages going between the
two victims.
With public keys an attack might look as follows:
Adam wishes to communicate with Betsy. Edith wishes to eavesdrop on the
conversation, or possibly deliver a false message to Betsy. Adam will ask
Betsy for her public key. Betsy will send her public key to Adam, but Edith
will intercept it, and send Adam her own public key. Adam then encrypts his
message with Edith's key (which he believes is Betsy's) and sends it back to
Betsy. Edith again intercepts, decrypts the message and reads the contents.
She then encrypts the message (altered if she so desires) with Betsy's key
and sends it on to Betsy, who believes she has received it directly from
Adam. A similar principle can apply to packets transmitted using any public
key technology."
http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html
"Man-in-the-Middle Attack (MITM)
If the first connection and host key exchange between a client and a
particular host is compromised, the MITM attack fools both the client and
server into thinking that they are communicating directly with one another
when, in fact, an attacker is actually intercepting all traffic between the
two as illustrated below:
In a MITM attack an attacker (Eve) impersonates both the server and the
client.
The client (Bob) initiates a connection with the server (Alice). Unknown to
both Bob and Alice, an attacker (Eve) is waiting to intercept their
connection negotiation. Eve receives Bob's request for a connection and
authenticates herself as Alice. Eve then initiates a connection with Alice
posing as Bob and authenticates herself. Two secure SSH sessions are now in
place with Eve reading all of the data being passed between Bob and Alice in
clear text. Secure Shell protects against MITM attacks through server host
authentication. Unless the host itself has been compromised, Eve does not
have access to the server's private key and cannot impersonate Alice."
http://www.tools4nt.com/resources/manual/monitormagic/Man_in_the_middle_atta
ck.htm
"Although HTTPS (secure socket layer) is a very safe and secure form of
encryption it is susceptible to one type of interception known as the man in
the middle attack. If you want to use the MonitorMagic web interface over
the Internet there is a way you can avoid being susceptible to this type of
attack. After MonitorMagic generates a digital certificate for you, save it
to floppy disk. If you want to use the MonitorMagic web interface from home
bring the floppy disk containing your digital certificate home with you.
Install the digital certificate on your web browser at home off the floppy
disk. Your susceptibility to the man in the middle attack has now been
circumvented, the attack can only take place during the initial exchange of
digital certificates and keys.
How the man in the middle attack works:
There are always three parties involved in the man in the middle attack. The
sender, the recipient, and the man in the middle. For the sake of this
example we will say that Mike is the sender, John is the recipient, and Elmo
is the man in the middle. Mike wants to communicate over HTTPS with John.
Unknown to both Mike and John, Elmo is waiting for them to communicate so he
can intercept. Mike attempts to initiate communication with John, but the
communication is intercepted by Elmo who authenticates himself as John.
Elmo, who now has everything he needs to impersonate Mike, initiates
communication with John and authenticates as Mike. There are now actually
two sessions in place. One between Mike and Elmo and another between Elmo
and John. Mike and John do not know anything is wrong because the
communication between them seems normal. In actuality all the information
Mike and John are exchanging is passing through Elmo in clear text form."
http://www.s0ftpj.org/docs/OTUexplain.txt
"We all know that SSH and SSL perform secure data transport because at the
starting of the connection any peer send its public key and with this
receive
the simmetric key which will be used since this time for encrypting all
connections.
This is a good protection against any passive sniffing attack (except for
the
good study about passive ssh traffic analysis) but it doesn't protect
against
the man in the middle attack.
Dsniff and ettercap are two really good sniffer implementing the man in the
middle attack for SSH and SSL...
These tools work by simple network hijacking: assigning to the sniffing box
the MAC address of the attacked host we can proxy the secure
connection...thee
connection is established with the sniffing proxy host and is the proxy
which
make the connection with the real destination host."
I simply googled for "man in the middle attack" and picked links that
define or illustrate what the attacks were. Not one article supported your
definition and several carefully pointed out that SSL is vulnerable to MITM
attacks.
Since we're talking about a definition, it's impossible for everybody else
to be wrong and for you to be right. I am neither confused nor immune to
education. In fact, I've patiently pointed this out four times now and you
still don't get it.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
