----- Original Message ----- From: "Ed Gerck" <[EMAIL PROTECTED]> To: "Jeroen C. van Gelderen" <[EMAIL PROTECTED]> Cc: "Ian Grigg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, March 24, 2003 11:20 PM Subject: Re: Who's afraid of Mallory Wolf?
> > > "Jeroen C. van Gelderen" wrote: > > > 1. Presently 1% of Internet traffic is protected by SSL against > > MITM and eavesdropping. > > > > 2. 99% of Internet traffic is not protected at all. > > I'm sorry, but no. The bug in MSIE, that prevented the correct > processing of cert path restraints and which led to easy MITM > attacks, has been fixed for some time now. Consulting browser > statistics sites will show that the MSIE update in question, > fueled by the need for other security updates, is making > good progress. > Their is another bug that has not been fixed by MS that allows signed but invalid certificates to be used to MITM the browser as well with no notification. > > 3. A significant portion of the 99% could benefit from > > protection against eavesdropping but has no need for > > MITM protection. (This is a priori a truth, or the > > traffic would be secured with SSL today or not exist.) > > I'm sorry but the "a priori truth" above is false . Ignorance about > the flaw, that is now fixed, and the need to do a LAN attack (if > you want not to mess with the DNS) have helped avert a major > public exploit. The hole is now fixed and the logic fails for this > reason as well. > > > 4. The SSL infrastructure (the combination of browsers, > > servers and the protocol) does not allow the use of > > SSL for privacy protection only. AnonDH is not supported > > by browsers and self-signed certificates as a workaround > > don't work well either. > > There is a good reason -- MITM. AnonDH and self-signed > certs cannot prevent MITM. > > > > > 5. The reason for (4) is that the MITM attack is overrated. > > People refuse to provide the privacy protection because > > it doesn't protect against MITM. Even though MITM is not > > a realistic attack (2), (3). > > But it is, please see the spoof/MITM method in my previous post. > Which, BTW, is rather old info in some circles (3 years?) and is > easy to do by script kiddies with no knowledge about anything we > are talking here -- they can simply do it. Anyone can do it. > > > (That is not to say that (1) can do without MITM > > protection. I suspect that IanG agrees with this > > even though his post seemed to indicate the contrary.) > > I think Ian's post, with all due respect to Ian, reflects a misconception > about cert validation. The misconception is that cert validation can > be provided as an absolute reference -- it cannot. The *mathematical* > reasons are explained in the paper I cited. This misconception > was discussed some 6 years in the ssl-talk list and other lists, and > clarified at the time -- please see the archives. It was good, however, > to post this again and, again, to allow this to be clarified. > > > > > 6. What is needed is a system that allows hassle-free, > > incremental deployment of privacy-protecting crypto > > without people whining about MITM protection. > > You are asking for the same thing that was asked, and answered, > 6 years ago in the ssl-talk and other lists. There is a way to do it > and the way is not self-signed certs or SSL AnonDH. > > > Now, this is could be achieved by enabling AnonDH in the SSL > > infrastructure and making sure that the 'lock icon' is *not* displayed > > when AnonDH is in effect. Also, servers should enable and support > > AnonDH by default, unless disabled for performance reasons. > > Problem -- SSL AnonDH cannot prevent MITM. The solution is > not to deny the problem and ask "who cares about MITM?" > > > Ed Gerck wrote: > > > BTW, this is NOT the way to make paying for CA certs go > > > away. A technically correct way to do away with CA certs > > > and yet avoid MITM has been demonstrated to *exist* > > > (not by construction) in 1997, in what was called intrinsic > > > certification -- please see www.mcg.org.br/cie.htm > > > > Phew, that is a lot of pages to read (40?). Its also rather though > > material for me to digest. Do you have something like an example > > approach written up? I couldn't find anything on the site that did not > > require study. > > > ;-) If anyone comes across a way to explain it, that does not require study, > please let me know and I'll post it. > > OTOH, some practical code is being developed, and has been sucessfully > tested in the past 3 years with up to 300,000 simultaneous users, which > may provide the example you ask for. Please write to me privately if you'd > like to use it. > > Cheers, > Ed Gerck > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
