Hi David, I'm going to exist myself from this discussion at the conclusion of this mail - it's consumed enough list bandwidth without further eating into my own limited resources.
Clipping; On July 25, 2003 11:48 pm, David Schwartz wrote: [snip] > 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.) [snip] > 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. [snip] You are confusing SSL/TLS with use-cases for SSL/TLS. SSL/TLS gives you protection against MITM attacks modulo the identity assurances you can determine (and define) from X509. What you do with X509 is your business and if you foul that up (or ignore it, which amounts to the same thing) then *you* are vulnerable to MITM. Saying SSL/TLS itself is vulnerable to MITM unless you "do something extra that's not defined in SSL/TLS" is like saying a home alarm system is provides no protection against intrusion until you install it in a house. NB: OpenSSL's *implementation* will attempt to provide a *correct* handling of X509, but will not magically conjur up context for you. Ie. it should apply expiry checking, constraints, etc. It will not check certificate fields for "intended peer" information, because it doesn't know the application, the requirements, or the transport (you know, BIOs exist for more than just hiding TCP/IPv4 ...). > 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. [snip] You are trying to bamboozle us, I think. A MITM in your world is any programmable location between the end-points who does anything except ignore your traffic. Fine, whatever. This is not even relevant for discussing MITM attacks on poortly implemented HTTPS applications, and is ludicrous in trying to wiggle the MITM term into the SSL/TLS protocol itself by games of definition. I'm sorry you've spent so much time on google over this - that can't have been much fun. Trying to make sense of this thread, and feeling obliged to wade in when it risked staining the archives and misleading impressionable users, has not been much fun for me either. Please think more carefully about what SSL/TLS is defined as - you won't find host names, or even transport details. There is a reason for this, and the fact Netscape (and subsequent parties) have so carefully made sure to keep use-case specifics out of the specs is further evidence that the layering is no accident. Indeed these parties have almost exclusively shared a common intended use, yet they kept the protocol definition free of those details. Please share their enlightenment. I'm not going to waste space disagreeing with you about HTTPS, but that's because (a) I don't necessarily disagree, and (b) as far as this mail-list is concerned, I couldn't care less about HTTPS. Really. > I'm amazed that you would disagree with every published definition of > a MITM I could find. An explanation of an acryonym does not give it the context that it assumes in the field over time. Man In The Middle is a pretty symbollic phrase, appropriate for discussing diplomacy, customer support, and would probably make a pretty naff (and successful) pop song. "MITM attack" is already something more refined. Moreover, the layer you are discussing it at, as well as which particular aspect of that layer, matters. You can discuss MITM attacks against IPv4 and/or HTTPS all you like. Likewise you can discuss MITM attacks against X509 until you are blue in the face. If you want to discuss MITM attacks against the *SSL/TLS protocol* then you have been wildly overreaching. And to shuffle your feet around what you actually mean by "attack", to the extent that any disruption or nuisance-making at the wire-level automatically counts as a MITM attack on SSL/TLS, can only hold water if you define it to. But that takes you outside any reasonable definition that matters to anyone else. Anyway like Brian, that's all I have to say on this, for whatever it's worth. 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]
