> 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. And SSL/TLS does not itself let you know anything is wrong. SSL/TLS provides the *ability* for you to know something is wrong *if* the developers correctly used the tools available to them. Without enforcing certificate authentication and/or CN matching, the user will not know anything is wrong. This is a situation 100% possible in SSL/TLS implementations out there, and they are numerous. Hell, even Microsoft got it wrong when they failed to check certificate constraints, and I with an example.com cert could sign yahoo.com and be completely valid in the eyes of IE until it was patched. That was an example of SSL/TLS done wrong, that lead to the possibility of MITM attacks, period. > 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). Agreed. > 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. Yep, and he's right. With unencrypted/unauthenticated TCP, we admit that MITM is always a possibility, and isn't worth meantioning. If I telnet to some host with good old fashioned telnet, the router can sniff and/or modify my packets. Someone sitting with ethereal/hunt/etc can redirect things through their box. We just don't bother meantioning this vulnerability because it is guarenteed to be possible, and cannot be prevented. Yep, still a MITM, just not of interest. With SSL/TLS, however, the ability to do encryption and authentication should be able to prevent it. However, implementing SSL/TLS *correctly* is the only way to prevent it. If you do it right, then you'll get invalid certs or cn or other warnings. If you don't do it right, you don't know it happened. > 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. No, SSL/TLS doesn't. I will continue to argue that it provides you the tools to do the above. It's done wrong all over the place. I don't want people to think that if they use SSL/TLS that they are secure, they are not unless the implementation is done well. My palm phone has an email app that only trusts a few CAs. I have a self signed cert on my server. I clicked the button 'always trust the remote cert'. I'm using TLS, yet I could still get no warning if there's a MITM attack.[1] If a closed source product were handed to you that says it supports SSL, would you stand up and say on a witness stand that it cannot be vulnerable to a MITM attack? Without knowing how it was written? For that matter, what about running 'stunnel -c -r www.example.com:443' ? That specifies no certificate sources and doesn't say to verify. It uses SSL - does that mean MITM attack is possible? What you've been saying above is that if something uses SSL, it is secure. I still say it must have SSL done *right* for it to be secure. All over the world, applications are being written by people with no crypto background, using third party libraries, who blindly piece together sample code until an SSL handshake completes successfully, and then they ship it. -- Brian Hatch When two egotists Systems and meet, it's an I Security Engineer for an I. http://www.ifokr.org/bri/ Every message PGP signed
pgp00000.pgp
Description: PGP signature
