[OpenID] rfc2817: https vs http

Eric Rescorla ekr at networkresonance.com
Mon Sep 1 16:49:17 EDT 2008


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.


> 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. Second, you can use
CSSC/Tickets [RFC5077] to offload all the information onto the client.

-Ekr

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



More information about the cryptography mailing list