[12868] in cryptography@c2.net mail archive
Re: Who's afraid of Mallory Wolf?
daemon@ATHENA.MIT.EDU (Jeroen van Gelderen)
Tue Mar 25 15:12:45 2003
X-Original-To: cryptography@wasabisystems.com
X-Original-To: cryptography@wasabisystems.com
Date: Tue, 25 Mar 2003 14:19:03 -0500
Cc: Ian Grigg <iang@systemics.com>, cryptography@wasabisystems.com
To: Ed Gerck <egerck@nma.com>
From: Jeroen van Gelderen <jeroen@vangelderen.org>
In-Reply-To: <3E80A60C.8D0489FA@nma.com>
On Tuesday, Mar 25, 2003, at 13:55 US/Eastern, Ed Gerck wrote:
> Jeroen van Gelderen wrote:
>
>> Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the
>> MSIE
>> bug has any effect on this.
>
> Maybe we're talking about different MSIE bugs, which is not hard to do
> ;-)
I am NOT talking about MSIE bugs at all. I didn't mention them and I
don't know where you pull the reference from. I am talking about HTTPS
traffic (1%) vs. HTTP traffic (99%) on the Internet:
1. Presently 1% of Internet traffic is protected *by SSL* against
MITM and eavesdropping.
2. 99% of Internet traffic is not protected at all (because it
travels over plain HTTP).
> I was referring to the MSIE bug that affects the SSL handshake in
> HTTPS,
> from the context in discussion. BTW, HTTP has no provision to prevent
> MITM in any case -- in fact, establishing a MITM is part of the HTTP
> tool box and used in reverse proxies for example.
Well, that is *exactly* the point I made:
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.)
Hence the a priori truth.
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.
That is, we cannot add just privacy protection to HTTP by enabling SSL.
That sucks because HTTP with just privacy protection is preferable over
plain HTTP. But the present SSL infrastructure insists that I pay to
defend against MITM even if I have no need for that. That is the
problem I (and I suspect IanG) is talking about.
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 for (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.
Cheers,
Jeroen
--
Jeroen C. van Gelderen - jeroen@vangelderen.org
"They accused us of suppressing freedom of expression.
This was a lie and we could not let them publish it."
-- Nelba Blandon,
Nicaraguan Interior Ministry Director of Censorship
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
