[132198] in cryptography@c2.net mail archive
Re: [OpenID] rfc2817: https vs http
daemon@ATHENA.MIT.EDU (Ben Laurie)
Mon Sep 1 17:52:59 2008
Date: Mon, 1 Sep 2008 21:56:52 +0100
From: "Ben Laurie" <benl@google.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
Cc: "Story Henry" <henry.story@bblfish.net>,
"OpenID General" <general@openid.net>, cryptography@metzdowd.com
In-Reply-To: <20080901204917.C63DF50846@romeo.rtfm.com>
On Mon, Sep 1, 2008 at 9:49 PM, Eric Rescorla <ekr@networkresonance.com> wrote:
> At Mon, 1 Sep 2008 21:00:55 +0100,
> Ben Laurie wrote:
>> The core issue is that HTTPS is used to establish end-to-end security,
>> meaning, in particular, authentication and secrecy. If the MitM can
>> disable the upgrade to HTTPS then he defeats this aim. The fact that
>> the server declines to serve an HTTP page is irrelevant: it is the
>> phisher that will be serving the HTTP page, and he will have no such
>> compunction.
>>
>> The traditional fix is to have the client require HTTPS, which the
>> MitM is powerless to interfere with. Upgrades would work fine if the
>> HTTPS protocol said "connect on port 80, ask for an upgrade, and if
>> you don't get it, fail", however as it is upgrades work at the behest
>> of the server. And therefore don't work.
>
> Even without an active attacker, this is a problem if there is
> sensitive information in the request, since that will generally
> be transmitted prior to discovering the server can upgrade.
Obviously we can fix this at the protocol level.
>> Why don't we? Cost. It takes far more tin to serve HTTPS than HTTP.
>> Even really serious modern processors can only handle a few thousand
>> new SSL sessions per second. New plaintext sessions can be dealt with
>> in their tens of thousands.
>>
>> Perhaps we should focus on this problem: we need cheap end-to-end
>> encryption. HTTPS solves this problem partially through session
>> caching, but it can't easily be shared across protocols, and sessions
>> typically last on the order of five minutes, an insanely conservative
>> figure.
>
> Session caches are often dialed this low, but it's not really necessary
> in most applications. First, a session cache entry isn't really that
> big. It easily fits into 100 bytes on the server, so you can serve
> a million concurrent user for a measly 100M.
But if the clients drop them after five minutes, this gets you
nowhere. BTW, sessions are only that small if there are no client
certs.
> Second, you can use
> CSSC/Tickets [RFC5077] to offload all the information onto the client.
Likewise.
>
> -Ekr
>
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
