---------- Forwarded message ---------- Date: Thu, 15 Aug 2002 16:09:24 -0400 From: Ian Grigg <iangat_private> To: dbsat_private Subject: Fwd: Re: [ISN] Security flaw found in Microsoft Web browser I'm not actually on InfoSec News, but here's a personal reply that seems to merit sharing. ---------- Forwarded Message ---------- Subject: Re: [ISN] Security flaw found in Microsoft Web browser Date: Thu, 15 Aug 2002 07:49:38 -0400 From: Ian Grigg <iangat_private> To: <someone> On Thursday 15 August 2002 00:53, you wrote: > On Wed, Aug 14, 2002 at 04:34:58AM -0500, InfoSec News wrote: > > Not that anyone will believe them, but in this case, it is indeed > > appropriate to assure that MITM attacks are hard. > > Hello Ian. They aren't hard, they're trivial in many places where > most people could be shopping from, like university or student's > house networks, internet caffees etc. You see, it all turns on the definition of hard. I postulate to you (and the world) that what is easy for the techie is hard for the crook. It is hard for the thief to employ an MITM because: 1. he (Mallory) needs access to the traffic 2. Mallory needs to sift through a *lot* of traffic in order to find one CC. I'll leave the quantity as an exercise... I grant you that WiFi or similar makes access to the data easier, much more so than in the past, but see 2., above. In the past, access to traffic more or less implied a trusted position such as a network administrator. Which ruled out thievery, as the two are, in general, incompatible occupations. But, Mallory is still stuck with 2. He takes a large degree of risk in sitting there condicting his attack, whilst waiting for his credit card. Alternatively, he could just use his talents to hack into some windows machine on the net somewhere, and scarf up a database load of credit card information. All pre-filtered for quality, and collected in a nice format. That's what I mean by being hard. Thieves are not fools and they are not techies. They have a mission, and the generally choose the most cost-effective way of doing it. And, in this case, sniffing credit cards from the net is so low on the success ratings that > Take a look at my demonstration at > http://arch.ipsec.pl/inteligo.var, which I tried to perform for > plain curiosity, and it worked very nice. Right! One of the things that your average Mallory will need is such demos, but even then, the barriers are significant. BTW, you have, coincidentally, identified yourself as a non-Mallory type :-) The issue that we, as security professionals face, is that we are still fixated on the inadequate 100% security model: Fix 100% of issues within the code. In the real world, security doesn't work like that. There are risks that are too small too worry about, and there are costs that make some risks not worth worrying about. Practically speaking, the browsers fix an issue that is a very low risk, but impose mammoth costs on the server providers: SSL servers are forced to have certs. Consequence of this is that SSL usage is way down below what it should be for a successful protocol. It's hard to come up with a good comparison, but consider SSH versus telnet, as against SSL versus straight HTTP. So, the way to re-address this balance is to fix the browsers to create *two* security locks. One for certified sessions (advised for confidential user data) and one for encrypted sessions (advised for general private browsing). The fix is simple: don't discriminate against un-certified sessions, and let the user enjoy straight old boring encryption-protected sessions, albeit with slight risk of Mallory's interest. My bet: use of certificates will go up. I'll leave the business logic of that for now... -- iang - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Fri Aug 16 2002 - 02:28:08 PDT