Hi, On July 25, 2003 03:13 pm, Brian Hatch wrote: > 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.
And this is precisely the crux of why I think this thread is a waste of bandwidth. Extremities and oddballs aside (NULL cipher-suites, etc), SSL/TLS provides authentication of at least one peer, potentially both. The SSL/TLS spec mentions key-exchange (read "private key") and X509 (read "public key"). SSL/TLS does not stipulate a canonical mapping of certification verification to any arbitrary trust model - for precisely the reason that SSL/TLS does not stipulate what transport it runs over nor what use it is being put to. Talking about SSL/TLS not being resistent to MITM unless you check host names against certificate fields is pointless, because SSL/TLS is not restricted to running over a network with the concept of host names?! It appears David is trying to say that MITM applies against SSL/TLS because MITM applies against *HTTPS* if you don't apply some certificate checking *relevant* to HTTPS. Note HTTPS is not SSL/TLS, and vice versa. If I run SSL/TLS over unix domain sockets, it may be because I want secure IPC between applications in which case the certificate mapping may be to system users (or applications, services, whatever). How those identities are encoded in the certs is anyone's guess - perhaps it's email style. Where on earth do domain names fit into this scheme? They don't because they're not relevant to SSL/TLS. David's arguments are about HTTPS over TCP/IPv4, whereas SSL/TLS is about the abstract mechanics of providing secure communications over any reliable (but untrusted) transport. SSL/TLS gives you the X509 "interface" for deciding what trust/identity mappings apply, just as PKCS7 does - you have to take them up to the level of HTTPS (or S/MIME, respectively) before you get a chance to even make a sensible statement about what identity validation is. Which is where all this MITM (and you'll excuse me for a moment here) horse-shit seems to be coming from. > 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. This doesn't make sense. SSL/TLS is probably implemented correctly by loads of HTTPS clients that are wildly broken - HTTPS is what they've managed to get wrong. SSL/TLS gives you X509 as a means to apply a mapping from "application x transport" space to "identity validation via X509". Do it however you want. SSL/TLS even defines the alerts and warnings to let you react appropriately if you don't like what you see. Why pollute the SSL/TLS specs with a bunch of layer-violating (again, excuse me) horse-shit to do with TCP/IPv4, web-browsers, or anything else? A perfectly validated (and Verisign-signed) certificate calling itself www.amazon.com will be absolutely no use to me if I'm program "X" trying to establish secure IPC comms with program "Y" relative to my own IPC-specific certificate expectations and my own approved CA-list. I don't need SSL/TLS giving me square pegs to put in round holes, thank you very much. > 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? This is seriously mixing up issues. The first is that supporting a protocol does not imply you haven't made a mistake. Orthogonally to that is a second, MITM is something you can protect against at the operational level only provided you define what it *means* at the operational level, and SSL/TLS is what you do underneath that. If Microsoft tells me that outlook express supports PKCS7, does that mean I should feel good when it authenticates email signatures and green-lights the results? No, because PKCS7 is not (quite) S/MIME. SSL/TLS is also, not (quite) HTTPS. You need to go a layer (or more) up from SSL/TLS before you have any space in which to make *sense* of identity, and thus to define what a MITM threat is. What David appears to be saying, however, is either (i) that SSL/TLS itself is vulnerable to MITM no matter what you do at the operational level (which is wrong), or (ii) that SSL/TLS is vulnerable to MITM because it doesn't define the operational (or "instantiation") level interpretation of certificate contents and identities (which is cruel and unusual punishment to abstraction). > 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? Yes because (i) you're running over TCP/IPv4, (ii) you're running with the presumption that you are serving HTTPS, and (iii) the consequent presumption is that "correct" (HTTPS-specific) behaviour is that the CN of the server cert should match the requested host-name *and* it should have a certificate(-chain) that successfully validates to a trusted root cert from a list of CAs you consider valid for authorising HTTPS certificates. <phew> SSL/TLS provides the abstract means (X509) to give meaning to identity validation and thus, a meaning to the term "MITM". HTTPS gives you a more concrete environment in which to *define* identity validation, so you should take any and all complaints you might have to that level. Your stunnel invocation is a case in point of a totally incomplete and unsatisfactory application of HTTPS, at least if you want to have some assurance that you are communicating with something that has a reasonable claim to being www.example.com. > 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. No this is confusing abuse of a protocol with a flaw in the protocol. Anyone can abuse a protocol, and you just showed a perfect example of that. SSL/TLS will help you establish comms that are confidential and authenticated to be between you and the owner of the X509 certificate's private key, such that no widely known attack is possible for a MITM to decrypt communications mid-stream or to tamper with communications undetected. All the "MITM" talk I've heard about so far is just people communicating (securely) with the wrong party, and to define whether a party is wrong or right depends on the transport, application, and mapping of identity to X509 certs (and authorised CAs). This is all outside the scope of SSL/TLS. > 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. Right. Their applications may be vulnerable to MITM attacks viz-a-viz the application itself, the transport used, and the differences between what it *should* consider trusted compared to what it *accepts* as trustworthy. At the SSL/TLS level, this is not MITM, it is simply communicating (and authenticating) with the wrong peer. I'm afraid that's not a vulnerability of SSL/TLS to MITM attacks, it's a misunderstanding and misapplication of the protocol to a particular use-case. Take it up with the browser writers and other HTTPS-interested parties. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
