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.

  • 2
    Have a look at the Upgrade header.
    – Lekensteyn
    Apr 1, 2014 at 20:00

4 Answers 4


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.

  • 1
    Well, the issue is the efforts that you must go to in order to support https. With STARTTLS, you just run a couple of commands, generate some random certificate, and you're done -- a lot of stuff would be encrypted from thereon. With https, you also have to pay someone to verify your certificates, then also update said certificates every 1 or two years, and then at the end of the day, some people might still not be able to access your web-site at all [by following the links], because you run too many sites on a single IPv4 address, and their browser doesn't support TLS SNI.
    – cnst
    Apr 1, 2014 at 20:25
  • 1
    @cnst, you can easily do exactly as you mention with the https protocol. These are called self signed certificates. BUT self signed certificates can be easily subverted by a man-in-the-middle attack causing the 'security' you add by encrypting the payload to be rendered useless. If you encrypt without verifying a signer of a certificate then a third party located in the network can also sign a certificate and impersonate the remote end point. Apr 1, 2014 at 23:56
  • 1
    @AndrewRussell, no, you cannot do the same -- if people encounter the https link (e.g. from another user), but their browser is not compatible (say, Android 2.2), then they get no web-site at all; also, if compatible users get the http link, then they get no encryption; how is that the same as with STARTTLS, which is entirely transparent to everyone? Yes, if you encrypt without verifying, then you can still be subject to some attacks, but, at the very least, they'd have to be active attacks, whereas if you don't encrypt at all, then you're also subject to passive attacks as well.
    – cnst
    Apr 2, 2014 at 3:33
  • 4
    @cnst the non-support of the https protocol is a browser makers choice, likewise the non-support of STARTTLS. Both require exactly the same technology but STARTTLS over http has no installed base. Apr 2, 2014 at 6:04

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):

   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.

  • Imho the standard should be modified that the http connection should be counted as https from the successful tls handshake (and it should me mirrored in the browser guis as well). Yes, I know, it would mean that https would refer to a tcp/80 connection, but I can't think it would be so bad.
    – peterh
    Jan 19, 2017 at 14:24

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.


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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .