Who's afraid of Mallory Wolf?

[NOP]

----- Original Message -----
From: "Ed Gerck" <egerck at nma.com>
To: "Jeroen C. van Gelderen" <jeroen at vangelderen.org>
Cc: "Ian Grigg" <iang at systemics.com>; <cryptography at wasabisystems.com>
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
majordomo at wasabisystems.com
>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com