[OpenID] rfc2817: https vs http

Ben Laurie benl at google.com
Mon Sep 1 16:56:52 EDT 2008


On Mon, Sep 1, 2008 at 9:49 PM, Eric Rescorla <ekr at 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 at metzdowd.com



More information about the cryptography mailing list