Does http support encryption without https (like STARTTLS)?

Question

Does http support encryption without https, akin to STARTTLS in smtp?

This may sound like a stupid question, but just think about it.

Banks require strong encryption, and cannot do business without it.

However, regular websites may not necessarily do so, but would benefit from casual encryption nonetheless, preventing many kinds of attacks, just as is the case with STARTTLS in smtp.

As such, for a regular web-site, if the browser is having any issues with ssl (be that protocol incompatibility, an underpowered mobile device, or an explicit preference of the user), it should just safely proceed without encryption without too much extra hassle.

Is there any extension of the HTTP protocol that would allow for encryption without explicit use of https? E.g. something akin Accept-Encoding: gzip and Content-Encoding: gzip? Or STARTTLS in smtp? If not, why not? Even WPA2 from WiFi comes to mind, which does do encryption, but doesn't bother with certificates or certificate authorities.

Basically, I'm thinking about something like the HTTPS-Everywhere extension, but which works automatically without the viral propaganda of the https:// address scheme -- without forcing people who don't want to be a part of it to be a part of it, like the https:// address scheme does, without dividing the address scheme, and without requiring the content provider to commit to always supporting https:// from thereon.

Answer 1

There is a standard for STARTTLS in plain HTTP. Note that "STARTTLS" is still SSL; it merely modifies the dynamics, but no implementation complexity is avoided that way.

Generally speaking, nobody uses STARTTLS for HTTP, mostly because it is less secure. Indeed, a very big part of SSL-for-Web-browsers is the visual feedback, by which the user is made aware of the encryption (the famous "padlock icon"). Without it, the user would have no way of knowing whether he really gets SSL, or whether he is browsing a fake site which plunders his passwords and bank accounts.

"Protocol incompatibility" and "underpowered device" are myths. Any browsing-capable device currently running knows at least how to do SSL 3.0, and that's sufficient for decent security. As for power, I have personally implemented and run SSL on a 33 MHz embedded ARM CPU; that's the kind of device that you would not deem worthy as a wristwatch. Even a basic bank smart card, the small chip embedded in a plastic rectangle, has more power than that. When people say that they don't support SSL because of lack of power, this is a lie; what they should say is that they don't support SSL because they are lazy.

As for "user preference": well, that one is kind of intangible. However, safety belts are mandatory in cars, and for good reasons. In fact, the Society as a whole is entitled to enforce safety belts regardless of "user preferences", because the same Society as a whole will have to support the consequences of a careless driver who has a slight accident turned into a dramatic disability because he did not have his belt on. The same reasoning applies for SSL: I do not want to let users "opt out" of SSL when such opting out is bloody stupid.

Answer 2

You shouldn't.

The reason being, the https:// URI scheme signals both to the user and to the browser that it is acting in a secure environment, and precautions should be taken to prevent secure information from leaking to an insecure environment. This is well-understood and a pretty strong system. The mechanism a server would use for switching from an insecure connection to a secure one is a redirect to the secure URL. The mechanism a client would use is to request the URL using https instead of http. As a rule, this whole thing works.

But to answer your question more accurately, yes such a thing exists. It's the HTTP/1.1 Upgrade header. This allows the client and server to directly negotiate a protocol. Upgrading to TLS is described in RFC 2817.

A client might send a message like this to find out if the server supports upgrading (example taken from the RFC):

   OPTIONS * HTTP/1.1
   Host: example.bank.com
   Upgrade: TLS/1.0
   Connection: Upgrade

While a server response indicating that an upgrade is required to view the requested resource would look like this (again, from the RFC):

   HTTP/1.1 426 Upgrade Required
   Upgrade: TLS/1.0, HTTP/1.1
   Connection: Upgrade

These are almost entirely unused for reasons stated above; you should use the HTTPS URI. The "upgrade" mechanism is an inferior option in the interest of security.

Nonetheless, the "upgrade" mechanism is used for other purposes: specifically, it's how web sockets are initiated, and also one of the ways a client and server can switch to the SPDY protocol.

Answer 3

I think you misunderstood STARTTLS. This command just tells the other server, that the clients wants to do TLS and after the server agreed the normal TLS handshake will start, e.g. with certificates and all the stuff - same as with https. The main difference is, that you don't commit to TLS right after TCP connect, but only after exchanging some plain text data (welcome message, EHLO...). And that the URL does not tell you if TLS is used, which may be a good or a bad thing.

But yes, HTTP has a similar mechanism which is also widely used: the CONNNECT request when tunneling through proxies. This is defned n RFC2818 and in the same RFC another mechanism for upgrading is also defined, using the 'Upgrade' header. This upgrade can be optional (client wants but accepts if server does not support it) or mandatory (server requires https).

While the Upgrade header is today used to create a WebSockets connection I've never seen it used for SSL upgrade and I doubt that any browsers support it.

Answer 4

Yes, it's presently on track to be defined as an extension of HTTP/2 by https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-alt-svc-06, and actual browser support is being written/committed/supported (bmo #1003448) and enabled (bmo #1113790) as of late 2014 and early 2015, as per http://daniel.haxx.se/blog/2015/03/06/tls-in-http2/, which points out that upcoming Mozilla Firefox 37 may be the first product shipping with Opportunistic Encryption (OE).