> >>The case of connecting to a different party (hijacking) has nothing > >>whatsoever to do with MITM. > > > > A MITM is a different party! No offense, but do you have any idea > > what > >you're talking about? > > Back to school, David. MITM is used by cryptographers to refer to > an interposer who is able to see all traffic on the wire and inject > all traffic between two parties. SSL was specifically designed > to be proof against MITM.
No, David is right.
If I connect with SSL to a machine and get a successful SSL connection
then it means
I know that[1] no one can see what that machine and I are saying.
I don't know that the machine to whom I'm talking is the one
to whom I wished to talk. It could be anybody.
Ahha! I know what we'll do, we'll require certificate authentication!
Ok, assuming I have a list of the major CAs and the the certificate
verified correctly
I know that I'm talking to a machine that has a certificate
trusted by one of my trusted CAs.
I still have no proof that I successfully connected to
www.example.org, I could have connected to www.evil_empire.com
if it had a valid cert. (Signed by Verisign, etc)
Shoot, I'm still not there, am I? What can I do to be sure I connected
to www.example.org? I know, I'll check the CN?
If the CN says 'www.example.org' and it was signed by a trusted
CA above, then I can be sure[2] that I got the right host.
If CN doesn't match, I know I got the wrong place.
HTTPS uses not only certs and trusted CAs but the CN match test.
If I use Stunnel for communication between just a few machines,
perhaps I'll just use a few individual certs in hashed name
format (xxxxxxxx.0 style)
"SSL" doesn't say anything about CN checking.
So, back to the comment:
> Back to school, David. MITM is used by cryptographers to refer to
> an interposer who is able to see all traffic on the wire and inject
> all traffic between two parties. SSL was specifically designed
> to be proof against MITM.
Wrong. David's right.
If a machine is able to get packets to go through him at any point,
he can attempt to be a MITM. He doesn't need to know the keys on
either endpoint if the endpoints don't verify them. He can talk
SSL to both endpoints, and decrypt/encrypt between them using the
two separate connections.
Yes, this is a 100% valid definition of MITM. At least to us
security/network folks. SSL was designed to *provide you the
ability* to prevent MITM attacks, but you need to do all the
checks above, it doesn't just happen by itself.
I'm going to shut up now - this thread's gone on far too long
with no illumination in sight.
[1] Assuming no one has the server's private key
[2] Assuming your CA is trustworthy, and that the private key wasn't
compromised.
--
Brian Hatch It compiles!
Systems and Let's ship it!
Security Engineer -- the Microsoft motto
http://www.ifokr.org/bri/
Every message PGP signed
pgp00000.pgp
Description: PGP signature
