Tom Otvos wrote: > As far as I can glean, the general consensus in WYTM is that MITM attacks are very > low (read: > inconsequential) probability. Is this *really* true?
The frequency of MITM attacks is very low, in the sense that there are few or no reported occurrences. This makes it a challenge to respond to in any measured way. > I came across this paper last year, at the > SANS reading room: > > http://rr.sans.org/threats/man_in_the_middle.php > > I found it both fascinating and disturbing, and I have since confirmed much of what > it was > describing. This leads me to think that an MITM attack is not merely of academic > interest but one > that can occur in practice. Nobody doubts that it can occur, and that it *can* occur in practice. It is whether it *does* occur that is where the problem lies. The question is one of costs and benefits - how much should we spend to defend against this attack? How much do we save if we do defend? [ Mind you, the issues that are raised by the paper are to do with MITM attacks, when SSL/TLS is employed in an anti-MITM role. (I only skimmed it briefly I could be wrong.) We in the SSL/TLS/secure browsing debate have always assumed that SSL/TLS when fully employed covers that attack - although it's not the first time I've seen evidence that the assumption is unwarranted. ] > Having said that then, I would like to suggest that one of the really big flaws in > the way SSL is > used for HTTP is that the server rarely, if ever, requires client certs. We all > seem to agree that > convincing server certs can be crafted with ease so that a significant portion of > the Web population > can be fooled into communicating with a MITM, especially when one takes into account > Bruce > Schneier's observations of legitimate uses of server certs (as quoted by Bryce > O'Whielacronx). But > as long as servers do *no* authentication on client certs (to the point of not even > asking for > them), then the essential handshaking built into SSL is wasted. > > I can think of numerous online examples where requiring client certs would be a good > thing: online > banking and stock trading are two examples that immediately leap to mind. So the > question is, why > are client certs not more prevalent? Is is simply an ease of use thing? I think the failure of client certs has the same root cause as the failure of SSL/TLS to branch beyond its "mandated" role of "protecting e- commerce." Literally, the requirement that the cert be supplied (signed) by a third party killed it dead. If there had been a button on every browser that said "generate self-signed client cert now" then the whole world would be using them. Mind you, the whole client cert thing was a bit of an afterthought, wasn't it? The orientation that it was at server discretion also didn't help. > Since the "Internet threat > model" upon which SSL is based makes the assumption that the channel is *not* > secure, why is MITM > not taken more seriously? People often say that there are no successful MITM attacks because of the presence of SSL/TLS ! The existance of the bugs in Microsoft browsers puts the lie to this - literally, nobody has bothered with MITM attacks, simply because they are way way down on the average crook's list of sensible things to do. Hence, that rant was in part intended to separate out 1994's view of threat models to today's view of threat models. MITM is simply not anywhere in sight - but a whole heap of other stuff is! So, why bother with something that isn't a threat? Why can't we spend more time on something that *is* a threat, one that occurs daily, even hourly, some times? > Why, if SSL is designed to solve a problem that can be solved, namely > securing the channel (and people are content with just that), are not more people > jumping up and > down yelling that it is being used incorrectly? Because it's not necessary. Nobody loses anything much over the wire, that we know of. There are isolated cases of MITMs in other areas, and in hacker conferences for example. But, if 10 bit crypto and ADH was used all the time, it would still be the least of all risks. iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
