Some advocates present HTTPS as synonymous with "security"—but this is not semantics.

Share this story

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

Further Reading

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

Further Reading

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.

This article should include a bit about how HTTPS does note even really secure your connection unless you personally vet the list of trusted CAs. Otherwise, your company, ISP, govt., etc. can still perform a MITM attack. Given the extensive list of CAs trusted by default in Chrome and Firefox, some of them explicitly governmental, a 'secure' indication by your browser does not actually mean 'secure'.

Granted, it may eb interpreted as 'more secure', or 'secure as long as nobody in authority cares', but that does not equate to 'secure' in the sense that most people probably expect.

This would have been stronger with some examples of non-salespeople making that claim – as currently worded, it sounds a bit like a strawman and could detract from the subsequent balanced discussion.

Similarly, this wording is too strong:

Quote:

What happens to all those links to HTTP sites when all those sites become HTTPS? The current answer is they break.

That's only true if you choose not to setup redirects, which is incredibly easy to do even on large sites. There are harder problems like mixed-content handling but overselling this one distracts from that.

Should also mentioned the issue where unscrupulous companies just become intermediate Certificate Authorities allowing them to potentially snoop on https traffic:https//www.engadget.com/2016/05/26/intermediate-certificate-authority/

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

Well the Wiki URLs contain data that could be used for filtering. https : // en.wikipedia.org/wiki/Charas

You kinda missed the point didn't you? That 'wiki/Charas' string is getting encrypted before being sent from the browser to the wiki server - at least it is so long as you're using https.

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

Well the Wiki URLs contain data that could be used for filtering. https : // en.wikipedia.org/wiki/Charas

The entire URL is encrypted with HTTPS. A network-level observer can see the IP address, which could be owned by the Wikimedia foundation or could just be a generic hosting company like Amazon or Rackspace.

This is why you'll periodically hear about innocuous sites being blocked because they shared an IP address or even subnet with a site which has content some government wanted to block more than they cared about collateral damage. CDN vendors reportedly spend a fair amount of time dealing with this.

We keep reading about Comcast et al injecting cute little notes at the protocol level. Eg for a while when you signed into a Comcast hotspot it would plaster over every page you visited a "brought to you by Comcast" message. I also am a huge detractor of the gated hotspots that most public hotspots use and https kills these dead.

On the other hand, maybe this would just displace the problem and force the user to install all these untrusted certs to "make it work". And it's hard to justify needing all this fancy security for that Harry Potter fanfic.

Sure that means you still have to serve *something* over HTTP (the redirect), and yes that means you're still vulnerable to SSL stripping, but you can remedy that somewhat with 1-2 more lines in your config to add a HSTS header to your HTTP responses.

Sure that means you still have to serve *something* over HTTP (the redirect), and yes that means you're still vulnerable to SSL stripping, but you can remedy that somewhat with 1-2 more lines in your config to add a HSTS header to your HTTP responses.

Wouldn't the simplest fix for broken http links be for a server that's enabling https to use some form of url-rewriting to forward http requests to https?

That's a good per-server fix. For people with legacy servers, though, it takes time to go through them all and update them to that setting. Furthermore, people running low-price rented server space might not have sufficient access to the server config to get it to work.

Also, it's an extra technical detail. The fact that you asked that question means you're already well-versed in it. Someone who runs a hobby Wordpress site and isn't so technically-minded wouldn't find it so simple. Remember, just getting a non-techie up to speed on using a genuine plaintext editor is a hassle.

I'd argue that this statement is debatable. I've seen articles on this very site detailing how a root CA that is less than trustworthy got into the root bundle in some browsers. I've also seen articles detailing how certificates were issued inappropriately for high profile domains from supposedly trusted CAs. I think this should maybe be reworded to "HTTPS is supposed to offer three things:"

A point not brought up here: the (admittedly small) price of getting an HTTPS cert limited the usage of it by automated phishing and scam routines. Sure, it's easy to pay for one or two certs, but if you're bulk-generating virtual servers the price got high quickly. That's no longer the case with letsencrypt.

So, the green lock will soon be everywhere, and thus is will be less useful for picking out low-grade phishing schemes. Take your target financial site, spawn a hundred lookalike URL's and get them all green locks for the cost of one captcha each.

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

This seems an odd argument to me. I'm not writing the browser, I'm not writing the server, the router, the compiler, I'm not providing the internet connection or the data interconnects for the backbone. I'm writing a web page. Why should it offend me that I'm also not writing the HTTPS tools? The point of creating my website was not to show off my skills (if that was it, I would take it down right now). The point was to make some content available.

True, using HTTPS doesn't necessarily mean your site is "secure", but *not* using HTTPS *does* mean your site is insecure. No matter what security measures you implement on your server, if you're not using HTTPS then anyone who visits your site is subject to a MITM attack.

And even if you (like Dave Winer) are not worried about the security of your site, you really *should* be concerned about the security of your site's *users*. A user visiting an insecure HTTP site is vulnerable to drive-by downloads, injected ads, and all sorts of other nasty things which a MITM attacker could take advantage of to potentially compromise their security. That's not something you should be exposing your site's users to. Use HTTPS.

Wouldn't the simplest fix for broken http links be for a server that's enabling https to use some form of url-rewriting to forward http requests to https?

That's a good per-server fix. For people with legacy servers, though, it takes time to go through them all and update them to that setting. Furthermore, people running low-price rented server space might not have sufficient access to the server config to get it to work.

Also, it's an extra technical detail. The fact that you asked that question means you're already well-versed in it. Someone who runs a hobby Wordpress site and isn't so technically-minded wouldn't find it so simple. Remember, just getting a non-techie up to speed on using a genuine plaintext editor is a hassle.

Or resources. I rent a low-power Atom box (about $10/mo) for a personal site hosting photo albums and hobby projects. With HTTP, it starts to bog down around 7-10 concurrent connections, when I tested a self-signed HTTPS it was bogging down around 5 concurrent sessions.

And while I work with Linux machines daily for my job and I can work my way thru manpages to figure it out, certainly you make another good point...a lot of people who run their own blog or something wouldn't have the sysadmin background to configure everything.

It doesn't have to be a magic bullet. Starting with a standard lock on the front door is better than nothing.

I believe the analogy would be closer to coming over to a friends house and closing the curtains so your nosy neighbors can't see what you are doing. If your friend has chosen not to actually put a lock on the door, nothing would stop those nosy neighbors from just coming over and opening the door to see what you are doing though, which is pretty much the entire point of this article.

Closing the curtains is a good thing, but you shouldn't take that to mean that what you are doing is *actually* private.

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

This seems an odd argument to me. I'm not writing the browser, I'm not writing the server, the router, the compiler, I'm not providing the internet connection or the data interconnects for the backbone. I'm writing a web page. Why should it offend me that I'm also not writing the HTTPS tools? The point of creating my website was not to show off my skills (if that was it, I would take it down right now). The point was to make some content available.

Agreed. I operate a Web server (among other things), and while I did not use the Certbot software to modify my configuration for me (it wasn't a practical option with nginx), I felt no nerd shame at using a graphical text editor rather than vim, or installing from a binary package rather than compiling from source. Please.

Tooling can break and then things can get messy, though, which is a problem. In my opinion ACME should be extended (or complimented by another spec like acmetool's) to specify exactly how certs live so that a server daemon needs only to listen on port 443, know an ACME base path (which would usually be a default), and that's the end of configuration.

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

Well the Wiki URLs contain data that could be used for filtering. https : // en.wikipedia.org/wiki/Charas

The thing with HTTPS is that when you go to a site you don't get anything about it when you intercept the traffic. All you would see is the equivalent of the following:

en.wikipedia.org:443

You don't get any information after the domain. And all the data served up is encrypted. So no, unless they could break the encryption and MITM attack the connection then there is no way to see which wiki you were accessing.

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

Well the Wiki URLs contain data that could be used for filtering. https : // en.wikipedia.org/wiki/Charas

The thing with HTTPS is that when you go to a site you don't get anything about it when you intercept the traffic. All you would see is the equivalent of the following:

en.wikipedia.org:443

You don't get any information after the domain. And all the data served up is encrypted. So no, unless they could break the encryption and MITM attack the connection then there is no way to see which wiki you were accessing.

It's trivial to see which page is accessed. One just need to measure the amount if bytes transfered and compare it with wikipedia page sizes, which are public information available to anybody.

Er... No? Bytes transferred will include the header, which may or may not include cookies, and any number of things. Plus the size of the payload itself will depend on cookies, compression, and other factors.

Edit: TLS also makes it opaque whether you're using HTTP/1.1 or HTTP/2, or indeed some completely unrelated protocol e.g. XMPP over port 443. Bytes transferred tells you one thing only : how many bytes were transferred.

What exactly do the Target and Home Depot breaches have to do with their websites using HTTPS? The breaches were of their POS systems, not their webserver. Non sequitur much?

It's an example of securing the connection but not the data, thus no security.

Kind of like putting a deadbolt on a cardboard door.

Not really since using HTTPS on their website means that people couldn't have been MITMed and thus an attacker could have stolen their credit card info without it ever reaching Target to begin with.

So you're saying that they could NOT have been MITM'd so an attacker could have stolen the card info before reaching Target?

/confused.

Are you suggesting that Target's HTTPS was also somehow compromised?

Setting that aside the point is that if a website uses TLS 1.3 with 4096-bit keys, but leaves the data unprotected once it gets there, that's almost like having no security at all. Yes, HTTPS minimizes the attack surface, but to extend my metaphor, what's the point of a triple bolted steel front door if you're going to leave your valuables out in plain sight viewable from the back door "secured" with a spring latch?