At Mon, 1 Sep 2008 21:56:52 +0100, Ben Laurie wrote: > > On Mon, Sep 1, 2008 at 9:49 PM, Eric Rescorla <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]