Who's afraid of Mallory Wolf?

Jeroen C. van Gelderen jeroen at vangelderen.org
Tue Mar 25 01:42:53 EST 2003


On Monday, Mar 24, 2003, at 18:57 US/Eastern, Ed Gerck wrote:
> I'm sorry to say it but MITM is neither a fable nor
> restricted to laboratory demos. It's an attack available
> today even to script kiddies.
>
> For example, there is a possibility that some evil attacker
> redirects the traffic from the user's computer to his own
> computer by ARP spoofing. With the programs arpspoof,
> dnsspoof and webmitm in the dsniff package it is possible
> for a script kiddie to read the SSL traffic in cleartext (list
> of commands available if there is list interest). For this attack
> to work the user and the attacker must be on the same LAN
> or ... the attacker could be somewhere else using a hacked
> computer on the LAN -- which is not so hard to do ;-)

This is good info!

>> ...
>> Clearly, the browsers should not discriminate
>> against cert-less browsing opportunities
>
> The only sign of the spoofing attack is that the user gets a
> warning about the certificate that the attacker is presenting.
> It's vital that the user does not proceed if this happens --
> contrary to what you propose.

True. Based on his first post however I think that IanG is saying 
something like:

1. Presently 1% of Internet traffic is protected by SSL against
    MITM and eavesdropping.

2. 99% of Internet traffic is not protected at all.

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.)

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.

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).

    (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.)

6. What is needed is a system that allows hassle-free,
    incremental deployment of privacy-protecting crypto
    without people whining about MITM protection.

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.

> 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.

Cheers,
Jeroen
-- 
Jeroen C. van Gelderen - jeroen at vangelderen.org

                 The python
            has, and I fib no fibs,
              318 pairs of ribs.
       In stating this I place reliance
   On a séance with one who died for science.
     This figure is sworn to and attested;
     He counted them while being digested.
             -- Ogden Nash


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



More information about the cryptography mailing list