HTTPS is not a magic bullet for Web security

People seem Grover-levels of excitement about some “S” sweeping the Web.

We’re in the midst of a major change sweeping the Web: the familiar HTTP prefix is rapidly being replaced by HTTPS. That extra “S” in an HTTPS URL means your connection is secure and that it’s much harder for anyone else to see what you’re doing. And on today’s Web, everyone wants to see what you’re doing.

HTTPS has been around nearly as long as the Web, but it has been primarily used by sites that handle money—your bank’s website, shopping carts, social networks, and webmail services like Gmail. But these days Google, Mozilla, the EFF, and others want every website to adopt HTTPS. The push for HTTPS everywhere is about to get a big boost from Mozilla and Google when both companies’ Web browsers begin to actively call out sites that still use HTTP.

The plan is for browsers to start labeling HTTP connections as insecure. In other words, instead of the green lock icon that indicates a connection is secure today, there will be a red icon to indicate when a connection is insecure. Eventually secure connections would not be labeled at all, they would be the assumed default.

Google has also been pushing HTTPS connections by “using HTTPS as a ranking signal,” meaning Google takes the security of a connection (or lack thereof) into consideration when ranking sites in search results. For the time being, Google says that HTTPS is “a very lightweight signal… carrying less weight than other signals such as high-quality content.” However, the company says that it “may decide to strengthen” this indicator as a means to encourage more sites to adopt HTTPS.

Through efforts like these, HTTPS has already moved beyond the obvious realms like banking and webmail. Popular sites like Facebook, Twitter, YouTube, as well as major online retailers like Target, Home Depot, and Adobe, are all served over HTTPS.

Target, Home Depot, and Adobe were not examples chosen at random, though. In recent years, all three have had major data breaches that exposed identifying information about users. HTTPS does not mean your data is secure, it just means your connection is secure.

This is not semantics. It’s critical for users to understand, and unfortunately HTTPS advocates sometimes present HTTPS as synonymous with “security.” The phrase “secure Web” gets used a lot in discussions, but as those three retailers illustrate, using HTTPS does not mean a website is necessarily secure. In fact, HTTPS says nothing about the website, the server it resides on, or what happens to whatever data you might give it.

And therein ultimately lies the biggest challenge for HTTPS—people need to understand what it means.

What’s so great about encryption, TLS, and authenticity?

If HTTPS is no guarantee of security, what exactly does it do? In short, HTTPS offers three things: secrecy, integrity, and authenticity.

“This is not semantics. It’s critical for users to understand, and unfortunately HTTPS advocates sometimes present HTTPS as synonymous with ‘security.’”

The simplest of these is secrecy. HTTPS uses encryption to make sure that no one can see the data that’s transmitted over the wire. When your browser connects to a website over HTTPS, the connection from your browser to the page you want to view is encrypted. That means any data exchanged is not visible to anyone else snooping the network.

The EFF’s Jacob Hoffman-Andrews, lead developer on Let’s Encrypt (a new tool that offers free HTTPS certificates similar to what Symantec offers) tells Ars encryption is a “necessary minimum bar” for today’s Web. “If we were designing the Internet from scratch today, we would say encryption is cheap and easy, there’s no export restrictions anymore, so it will be default and you won’t have to worry about it.”

Without the encryption, it’s easy for people with the ability to monitor the connection–say a person on the same unsecured WiFi network or a rogue ISP employee—to see everything you ask for and everything the site sends back. That allows attackers to perform what’s known as a Man in the Middle attack.

With an unencrypted connection, both your browser’s request and the server’s response are just plain text bits of data. All a Man in the Middle attack does is step into that stream of data and start reading and manipulating it. If your ISP wanted to add an advertisement to this page that requires you to click on it before reading the story, it could do that by just injecting a few packets of its own. You would have no way of knowing whether that ad came from Ars or some other source. Anyone could in fact do just about anything to the data traveling between the Ars server and your browser, including serving up an entirely different page or not showing the page at all.

Man in the Middle code injection is not a theoretical problem; It is an active, widely used attack. In the case of Verizon Wireless’ so-called “Perma-Cookie,” it’s even a business model.

Using a Man in the Middle attack, Verizon Wireless modifies traffic on its network to inject a tracker (it added an HTTP header called X-UIDH) that is then sent to all unencrypted sites that Verizon customers visit. This allows Verizon to, in the words of the EFF, “assemble a deep, permanent profile of visitors’ Web browsing habits without their consent.”

Verizon is not alone. It’s a safe bet that your ISP is doing something similar. Comcast’s Wi-Fi service already does this, as does AT&T’s Wi-Fi (you can opt out, for a fee). What your ISP does with this data is less well known, but it’s a big part of why Google wants the Web to move to HTTPS.

When you communicate in plain text over the network, you have to assume that someone is at the very least watching and very probably injecting some tracking code to record your requests. With the encrypted connection you get when a site uses HTTPS, the transmitted data is very difficult to read. There is no way to read or manipulate cypher text without the encryption keys. Score one for HTTPS, which can guarantee that you are getting the content your browser requested.

HTTPS also prevents the kind of censorship that happens at the state or ISP level. For example, Russia wanted to ban a Wikipedia article (about charas hashish), but because Wikipedia is served over HTTPS there’s no way to see which page visitors are requesting. Russia was faced with the choice: ban all of Wikipedia or none. It opted for none.

Score another one for HTTPS. As it turns out, unencrypted networks do not, as early Web enthusiasts liked to say, “see censorship as damage and route around it.” In fact, unencrypted networks make censorship very easy—just reach in and block what you want, change what you want.

Put all this together and you discover that the Web, the network on which your data travels, is not just insecure but actively hostile. As developer and HTTPS proponent Eric Mill writes, “I see companies and government asserting themselves over their network. I see a network that is not just overseen, but actively hostile. I see an Internet being steadily drained of its promise to ‘interpret censorship as damage’… In short, I see power moving away from the leafs and devolving back into the center, where power has been used to living for thousands of years.”

It’s getting worse, too. A considerably more alarming network attack has come to light in the last year that exploits the lack of HTTPS on the Web to create distributed DDoS attacks using unsuspecting users who never know they’re part of an attack. Great Cannon, as this attack has been dubbed, is a very sophisticated attack. In a nutshell, someone hijacked a bit of JavaScript served up by Chinese search giant Baidu and added a payload to it that made frequent requests to two websites that challenge Chinese government censorship. Everyone visiting Baidu who loaded that script became part of the attack.

This is what Mill means when he says the network is actively hostile. With Great Cannon it becomes so hostile it turns you, unknowingly, into a DDoS attacker. The only way to stop attacks like Great Cannon, or network tampering like what Verizon and others are doing, is to encrypt your traffic.

The last thing HTTPS provides is authentication. The site you’re visiting is verified by the browser as actually being that site and not some imposter. To authenticate your connection, Web browsers maintain a list of known, trusted certificate authorities. When your browser requests a page, it gets the page’s security certificate, which contains a chain that leads back to a certificate authority. If that authority matches an authority known to your browser, then your browser will trust that the site you’re connecting to is who it claims to be.

Security theater

When understanding what HTTPS offers—encryption, integrity and authentication—it should be easy to see why your bank uses it, why Gmail, Facebook, Twitter and any other sites you log in to use it (or at least should). What’s less immediately obvious is why every site on the Web can benefit from HTTPS. Does HTTPS help some long archived, no longer maintained bit of ephemera from the early Web?

Software developer and blogger Dave Winer argues, in a post entitled “HTTPS is expensive security theater,” that not only does HTTPS not help old, archived sites, it’s a waste of the site owner’s time. “I have a couple dozen sites that are just archives of projects that were completed a long time ago,” writes Winer. “I’m one person. I don’t need make-work projects, I like to create new stuff, I don’t need to make Google or Mozilla or the EFF or Nieman Lab happy.”

Winer is not alone. In fact, he’s in very good company: no less than Tim Berners-Lee has questioned the move to HTTPS, going so far as to call it “arguably a greater threat to the integrity for the Web than anything else in its history.” Berners-Lee does think the Web should be encrypted; he just doesn’t like the way it’s currently being done. Berners-Lee would like to see HTTP upgraded rather than shifting to the HTTPS protocol.

Together, Winer and Berners-Lee highlight the two big potential problems of moving the Web to HTTPS. It significantly complicates the process of setting up a website and creating something on the Web, and it might break links—billions of links.

It’s easy for savvy developers to dismiss the first problem—that HTTPS adds considerable complexity. But what makes the Web great is that you don’t have to be a savvy developer to be a part of it. Anyone with a few dollars a month to spare can rent their own server space somewhere, throw some HTML files in a folder, and publish their thoughts on the Web. A few dollars more gets you a nice URL, but that’s not strictly necessary.

Requiring sites to include a security certificate adds a significant barrier to entry to the Web. Anyone who has put in the effort to get HTTPS working on even one site knows that it can be a tremendous hassle. And this is likely the biggest obstacle to widespread HTTPS adoption among small site operators (who make up the bulk of the Web).

Until very recently, there was no way to obtain a free SSL certificate (a few certificate authorities did not charge to issue you a certificate, but if you needed to revoke it there was a fee). This was the first challenge that HTTPS proponents set out to solve. Again, companies like Symantec offer solutions for free certificates. And the EFF and Mozilla partnered to create Let’s Encrypt, which also offers free certificates. These options are really free, no catches, and they don’t require users to provide any identifying information. There’s also a set of command line tools that make installing and configuring these certificates pretty simple provided you have some basic sysadmin knowledge (and SSH access to your server).

That’s not the end of the headache, though. Once you have a certificate, you have to install it and get your Web server to serve it up properly. Again, assuming you have a basic sysadmin’s knowledge, this isn’t too hard, though tweaking it until you get an A+ grade on SSLLab’s security test can take many hours of debugging (and even top sites like Facebook only score a B). I have been running my own website, building my own CMSes, and running servers on the Web for 15 years, and I can say without hesitation that getting HTTPS working on my site was the hardest thing I’ve done. It was hard enough that, like Winer, I haven’t bothered with old archived sites.

Over the long run, Let’s Encrypt is hoping to partner with major Web hosts in such a way that users looking to set up their own blog using popular CMS like WordPress get an HTTPS site up and running as easily as clicking a button. Things will, however, likely never be that simple for anyone that wants to take a more DIY approach, writing their own software.

Simplifying the process of setting up HTTPS means more tools in your toolchain. It makes the individual more dependent on tools built by others. Developer Ben Klemens has an essay about exactly this dependency, writing that if “solving the problem consists of just starting a tool up, my sense of wonder has gone from ‘Look what I did’ to ‘Look what these other people did,’ which is time-efficient but not especially fun.”

It may seem trivial to developers employed by large companies solving complicated problems that taking the fun out of the Web is a problem, but it is. If the Web stops being fun for individuals, it becomes solely the province of those companies. We are no longer creators of the Web, just simple users.

Think of the Links

Berners-Lee’s concerns about HTTPS are easier to fix. What happens to all those links to HTTP sites when all those sites become HTTPS? The current answer is they break. There are quite a few proposals that would mitigate some of this at the browser level. When I asked Mozilla’s Barnes about Berners-Lee’s concerns, he told me, “Tim has been a really useful contrarian voice. His views have driven the browser and Web community to address concerns he has raised.”

To prove that Barnes actually does care about URLs, he’s the co-editor of a W3C specification that aims to preserve all those old links and upgrade them to HTTPS. The spec is known as HSTS priming, and it works with another proposed standard known as Upgrade Insecure Requests to offer the Web a kind of upgrade path around the link rot Berners-Lee fears.

With Upgrade Insecure Requests, site authors could tell a browser that they intend all resources to be loaded over HTTPS even if the link is HTTP. This solves the legacy content problem, particularly in cases where the content can’t be updated (like, for example, The New York Times‘ archived sites).

Both of these proposals are still very early drafts, but they would, if implemented, provide a way around one of the biggest problems with HTTPS. At least, they’d prevent broken links some of the time. Totally abandoned content will never be upgraded to HTTPS, neither will content where the authors, like Winer, elect not to upgrade. This isn’t a huge problem, though, because browsers will still happily load the insecure content (for now at least).

Remember, when browsers say “secure” this is referring to <em>connections</em> and not overall security for end-users.

Credit: Thomas Trutschel / Getty Images

More honest Web browsers

The Web needs encryption because the Web’s users need it. The Web needs encryption because the network needs it to remain neutral. The Web needs encryption because without it just browsing can turn you into an unwitting helper in a DDoS attack.

There are a lot of companies pushing HTTPS. While most have their own interests first, for now at least those interests align with Web users’ interests. But none of these companies have the kind of power and influence that Google and, to a lesser degree, Mozilla have as browser makers. And it’s up to browser makers to fix the confusion that currently surrounds HTTPS.

This starts with presentation. The current way browsers highlight HTTPS connections is misleading and needs to change.

The green lock icon that browsers used to denote a secure connection is too easily construed as a signal that the site is “secure.” And any perceived labeling of HTTPS sites “secure” and non-HTTPS sites “insecure” is deeply flawed. Again, just because a site uses HTTPS doesn’t mean it’s not storing your password and credit card number in plain text somewhere, and it doesn’t mean that the site hasn’t been hacked to serve malicious JavaScript and so on. As it stands today, browsers do not make it clear enough that the lock icon is a statement about the connection to the site and not the site itself.

As Hoffman-Andrews puts it, “calling HTTPS sites secure is generally not accurate, but it’s definitely accurate to call HTTP sites insecure.” In fact, browsers have no way of knowing if the site is truly “secure” in the broader sense. Neither do you and I. No one is ever going to fix that, but browsers can at least be more accurate and transparent with users.

The Chromium project has already announced plans to change the way it displays the lock and to start marking HTTP connections as insecure. Mozilla will do roughly the same with Firefox.

It’s tempting to see this as hostile to publishers. The message has become fall in line with HTTPS or, as Winer writes, the browsers will “make sure everyone knows you’re not to be trusted.” However, what the broken lock is really saying is that your browser can’t guarantee that the content you’re reading hasn’t been tampered with. It also can’t guarantee that you aren’t currently part of a DDoS attack against a site you’ve never even heard of. Nor can it guarantee that you’re connected to the site you think you’re connected to. All a browser can guarantee is that there is nothing secure about your connection and anyone could be doing anything to it.