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