[OpenID] rfc2817: https vs http

[Eric Rescorla]

At Mon, 1 Sep 2008 21:56:52 +0100,
Ben Laurie wrote:
> 
> 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.

Agreed. I thought we were contemplating protocol changes in
any case, so I figured having clients just use a longer session
cache (5 minutes is silly for a client anyway, since the amount
of memory consumed on the client is miniscule) wasn't much
of an obstacle.


> BTW, sessions are only that small if there are no client
> certs.

True enough, though that's the common case right now.


> > Second, you can use
> > CSSC/Tickets [RFC5077] to offload all the information onto the client.
> 
> Likewise.

Except that CSSC actually looks better when client certs are used, since
you can offload the entire cert storage to the client, so you get
more memory savings.

-Ekr

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