“Deprecating” Insecure HTTP, Part 1: Myths, Facts, and Missing Principles

May 2015  |  Status: First Draft

Some time ago, Chromium floated the idea of “marking” plain unencrypted HTTP, the protocol that has been the backbone of the web for 25 years, as insecure. This was widely seen as a not-so-subtle nudge for everyone to adopt HTTPS — “HTTP Secure” — instead, and not everyone was happy with that little nudge. After all, who wants a scary security warning to show up when people visit their website? So began the often heated debate about whether it’s okay for a browser vendor to (ab)use its power to push HTTPS down everyone’s throat.

Meanwhile, a number of well-known organizations have launched an ambitious project to bring free and easy encryption to everybody, and even the U.S. federal government joined what now seems to be an inevitable march toward encrypting the entire web. The government’s proposal is not without detractors; a 900-pound gorilla adding its weight to one side of the debate must have made a lot of people on the other side rather nervous.

Last week, Mozilla added even more fuel to the debate by publicly announcing that they would like to “deprecate” HTTP at some point in the near future. Mozilla, of course, is a prominent member of the consortium that’s working on Let’s Encrypt, the aforementioned free CA project. Also as the maker of the world’s third most popular browser, they have a lot of power to influence the behavior of website owners and visitors alike. So it’s not surprising at all that a shitstorm followed their announcement, this time a lot more negative than before. How could Mozilla, the indignant critics argue, leave the little people (who can’t easily set up HTTPS) in the dust and collude with the extortion racket that everyone knows certificate authorities (CAs) to be?

(This, of course, isn’t new. Whenever browsers make security-related decisions that increase the cost of running a website, such as displaying an error for an expired certificate, people rush to complain about it. In 2008, the complaint was “How dare they tell me to renew my certificate?” In 2015, the complaint is “How dare they tell me to buy a certificate in the first place?”)

Overview

This series of posts is an attempt to debunk some of the worst misinformation and blatant alarmism on both sides of the HTTPS Only controversy, and suggest that we take a more holistic, long-term point of view. It is loosely based on the comments I wrote on various HN threads, but I hope that the long format will make my position clearer and reduce the chance of misunderstanding that so often plagues real-time discussion threads.

In the first part, I will criticize the FUD (fear, uncertainty, and doubt) that both sides of the controversy have been spreading, and explain what browser vendors should do to assure the rest of us that they will not throw us under the bus, even in the sacred name of security.

In the second part, I will argue that we should not evaluate the browser vendors’ proposals in isolation, but in the context of much-needed disruptions in the domain registration, certificate, and hosting markets that the proposals are likely to trigger.

Enough with the FUD

The single most unfortunate thing about Mozilla’s announcement is their careless use of loaded phrases like “deprecate” and “phase out”. In tech circles, to deprecate something usually means that there is a clear intention to remove support for it at some point in the future. For example, the arcane mysql extension that was responsible for so many security holes was deprecated in PHP 5.5, and it is slated for complete removal in PHP 7.0. Similarly, when browsers try out a new CSS property, they often put it behind a vendor-specific prefix such as -moz- or -webkit- until everyone agrees on how that feature should behave. When agreement is reached, a standard property without the prefix is implemented, and the prefixed property is deprecated and removed shortly.

Naturally, when Mozilla talked about “deprecating” unencrypted HTTP, a lot of people reasonably assumed that the plan was to remove support for unencrypted HTTP altogether. But this is a massive misunderstanding. Nowhere in the blog post does Mozilla talk about removing support for good ol’ HTTP. You can still write up your craziest ideas and serve it to the world on port 80. Nobody will stop you from reading nerd classics like The Cathedral and the Bazaar, which at the time of this writing is most definitely not available on HTTPS.

It is also absolutely false that this change will require developers to buy an SSL certificate for every project in development. It would be easy to carve out an exception for localhost, as well as my favorite officially reserved TLD, .local. Moreover, it is trivial to set up self-signed certificates on a local server and tell Firefox to trust it. I already do it for nearly every project.

So if anyone tells you that the entire port 80 is about to become unusable thanks to Mozilla, you should know that it’s nothing but FUD.

The people who are rallying behind the HTTPS Only campaign, on the other hand, are also responsible for spreading their share of FUD. While it is true that HTTPS is meant to provide both confidentiality (nobody can eavesdrop on your communication) and authentication (nobody can modify the packets to add ads or malware to the content you send and receive), and while it is also true that many people would benefit from encrypting content that is public knowledge anyway (you might not want to let an oppressive government know that you accessed a particular piece of knowledge), it simply is not true that every single resource available online needs to be served over HTTPS.

Massive dumps of scientific data were mentioned in the U.S. government thread as one example of data that does not need to be encrypted. HTTPS Only supporters ask “what if somebody manipulates that data in transit?” but this is FUD. There are well-known ways to verify the authentication of a static blob of data without relying on HTTPS. Linux distributions have been signing their packages with PGP for ages. Scientists can do that, too, if they are worried about inauthentic data.

The idea that every silly cat meme in the world needs to be encrypted, therefore, is also FUD. There is probably a lot of value in preventing another MITM-based DDoS attack like this, so I agree that consumer-facing websites should use HTTPS whenever possible. But there are lots of other purposes for which HTTPS is not necessary at all.

Principles and Assurances

As I noted above, Mozilla could have avoided a lot of FUD from the other side if they phrased their announcement a bit more tactfully. As a major browser vendor and widely trusted guardian of internet freedom, they have a responsibility to ensure that people can clearly understand and follow any changes they make, no matter how urgent and/or strongly justified.

According to their announcement,

There are two broad elements of this plan:

1. Setting a date after which all new features will be available only to secure websites
2. Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.

The first element is a carrot to make HTTPS more attractive. The second element is a whip to make HTTP less attractive. This is serious business. It’s not just a technical demonstration or statement of ideals. This is realpolitik, Mozilla’s attempt to use its hard-earned power and authority to encourage (or, to be more blunt, manipulate) developers to build more secure websites.

In the next part, I’m going to argue that this kind of manipulation is not necessarily evil, and in fact is very much needed in an imperfect world such as ours. Nevertheless, nobody likes being forced into doing things. If you’re trying to act like a benevolent dictator, you need to give the rest of us assurance that you actually are acting benevolently. This means that your decisions need to follow clear principles, e.g. protecting us from realistic attack vectors, rather than merely picking the carrots and whips that will have the most psychological effect on the masses.

In order to minimize negative backlash and accommodate other legitimate points of view while achieving their core objective, I suggest that Mozilla and other browser vendor follow the principles below:

First, HTTP must continue to be supported indefinitely.

Second, no feature must be removed from HTTP merely in order to encourage adoption of HTTPS.

Each removal must be justified with a security rationale that is more specific than the mere fact that HTTP does not normally provide confidentiality and authentication. For example, Firefox already denies persistent permissions for microphone access over an insecure connection, and this can be justified because an MITM attacker can exploit previously granted permissions to record a user’s voices and ambient sound without his consent. On the other hand, if browsers refused to render webfonts for the sole purpose of annoying HTTP users, that would be an obvious abuse of their market share. Although an attacker could serve malware-laden fonts, browsers should do their best to prevent such fonts from harming the user rather than disabling them wholesale.

Third, a similar principle must be followed when deciding which new features to make HTTPS-only.

Access to the biometric sensors of a mobile device, for example, sounds like a powerful API with lots of potential for abuse. A new CSS property that makes it slightly easier to draw shiny hexagons, on the other hand, does not provide enough justification to discriminate against insecure transports. Likewise, if browsers deliberately failed to implement certain optimizations from HTTP connections to make them slower, that would be a terrible abuse of the trust that we have given to Mozilla et al.

Fourth, the timing of these changes must be guaranteed to leave plenty of room for people to adapt, and reconsidered at any time if current expectations are not fulfilled.

For example, Mozilla is probably expecting their upcoming free CA, Let’s Encrypt, to make it drastically easier for everyone to use HTTPS. But if this free CA somehow fails to materialize, or if it is not adopted as quickly as planned, Mozilla should be ready to delay their “HTTP deprecation” plan as well.

The point of these principles is to assure web developers around the world that they will not be taken advantage of merely for the sake of promoting HTTPS. Resorting to whips and carrots dehumanizes people who are subjected to them. It should only be done when there is a strong, specific justification involving vulnerabilities that cannot be plugged in any other way.

Most importantly, browser vendors must understand that the change they’re talking about this time is qualitatively different from the other HTTPS-related changes they made recently, such as phasing out SSLv3 and SHA1-signed certificates. Those changes made sense because they helped close the gap between what people expect when they see a padlock icon and the degree of security that they actually get. But the gap between HTTP and HTTPS is not like that; it is possible for people to agree to use HTTP with the explicit understanding that they are forgoing confidentiality and authentication. Not using HTTP is a choice that website owners and users alike should be free to make, and nobody has the right to take away this freedom without a pressing need to defend ordinary users from a specific class of attacks that cannot be easily prevented any other way.

In case someone at Mozilla is reading this and thinking “but we’re already planning to do that”, my concern is that your intentions are not so clear to the rest of the world. Planning to do good is not enough. Everyone should know that you’re planning to do good.

Continued in Part 2.