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. 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 [EMAIL PROTECTED]
