Way back in 2010, we launched our popular browser extension HTTPS Everywhere as part of our effort to encrypt the web. At the time, the need for HTTPS Everywhere to protect browsing sessions was as obvious as the threats were ever-present. The threats may not be as clear now, but HTTPS Everywhere is still as important to users as ever.

In 2010, HTTPS Everywhere was a novel extension. It allowed users to automatically use the secure version of websites that offered both insecure HTTP and secure, encrypted HTTPS. Sites such as Google had only recently exposed to users the option to search using HTTPS. Facebook had not yet allowed users to browse the site securely. The dangers of insecure browsing were demonstrated by the powerful browser extension Firesheep, which intercepted HTTP packets and allowed attackers on the same WiFi network as their victims to hijack browsing sessions when logged in to popular sites. Firesheep provided a simple point-and-click interface to perform this "session hijacking" attack - no need for terminal screens or complicated command-line tools. Tools with similar functionality had existed for a while, but anyone could install Firesheep with minimal effort.

Fast forward to 2018. HTTPS is more prevalent than ever, and continuing to take big strides. On July 24, Google announced that users of its Chrome browser would see HTTP sites labeled as "not secure." And a Google transparency report shows that between 71% and 90% of page loads are over HTTPS as of December 2018. The vast majority of the top sites not only offer HTTPS, but automatically redirect to the HTTPS version of the site when you connect over HTTP. This has led a lot of people to ask a very good question: what's the point of using HTTPS Everywhere anymore? Why should we use it when sites are already forwarding us to the secure version?

The Relevance of HTTPS Everywhere in 2018

HTTP Strict Transport Security (HSTS)

HTTPS not only protects users from session hijacking, but also prevents governments and ISPS from blocking specific pages and spying on the pages people view and the information people send. HTTPS Everywhere guarantees that the websites we protect will never be accessed over insecure HTTP as long as you have the extension enabled.

Usually, users type “www.example.com” when they access a site, leaving off the protocol (such as “http://” or “https://”). For backwards-compatibility, this still defaults to HTTP, meaning that server administrators still have to serve a redirect header to HTTPS over HTTP. This is important due to a type of attack that takes advantage of this small window of time where websites upgrade your connection security. Many websites rely on actively upgrading your connection from HTTP to HTTPS every time you access the site, which gives attackers plenty of opportunities to carry out their attacks.

Technologies such as HTTP Strict Transport Security (HSTS) allow sites to tell users browsers that they should expect to access a site over HTTPS in the future, and prevent the browser from connecting insecurely. However, HSTS is sent in the form of a web header, and this is only delivered and cached after you access that site for the first time. This means that if an attacker intercepts your insecure connection on that first request, they can remove the HTTPS redirect without you ever knowing. Your browser would still connect, but the attacker would be sitting in the middle of it all, removing the security of web traffic between you and the site. This is not just theoretical - sslstrip is a tool which automates this type of attack.

One additional problem is that caching HSTS headers can be used to create a supercookie in the browser to track users. Apple spotted trackers in early 2018 abusing the security header for just this purpose. This is also why Firefox stopped sharing HSTS state in Private Browsing Mode, and the future of the security header in other browsers is somewhat uncertain. This means that users have to be vigilant to access the HTTPS version of a site every time they fire up a Private Browsing session or download a new browser in order not to fall prey to sslstrip-style attacks.

Or users could download a list of sites that fully support HTTPS, rather than caching sites from a header. This is the intention of the HSTS preload list, which is delivered in all major browsers and ensures that sites on the list will never be accessed over plain HTTP. Any site that is included on the list (this includes “eff.org” and all subdomains, for instance) will have the assurance of its visitors traffic being 100% HTTPS for all major browsers. This is a great technology, and has some adoption among larger sites (for instance, SecureTheNews tracks HSTS preload adoption for major newspapers). However, many sites don't know about the HSTS preload list or are wary of implementing it because they don't want to make their sites permanently inaccessible in the case of improperly configured HTTPS. Google is also very concerned about the size of the HSTS preload list and the impact it has on the download size for Chrome browser. For this reason, inclusion criteria has been restricted over time and preloaded domains remain a very small percentage of the total number of HTTPS websites.

This is where HTTPS Everywhere comes in. HTTPS Everywhere in its default configuration effectively expands on the HSTS preload list to vastly improve coverage. The HSTS preload list currently contains about 50 thousand target domains and subdomains, whereas HTTPS Everywhere contains 125 thousand, which are on by default. We also remove domains which are already covered by the preload list, which means combining HTTPS Everywhere and the HSTS preload list (which comes with your browser) will cover about 175 thousand domains and subdomains. That's much better protection than you get from your browser out of the box!

Encrypt All Sites Eligible (EASE) Mode

By default, HTTPS Everywhere forces encryption on websites that we know support HTTPS. For these sites, it also takes care of some complicated edge cases. For instance, a site may support encryption only on a secure subdomain, like “secure.example.com”. For other sites, we may want to only transfer session cookies over HTTPS. Other sites may only support HTTPS under certain paths, like “example.com/login”. Historically, taking care of these edge cases has been vital in providing a smooth user experience.

But what about sites we don't know support HTTPS? A recent feature added to HTTPS Everywhere automatically attempts to upgrade connections from HTTP to HTTPS for all sites, and prevents unencrypted connections from being made. Currently known as "Block all unencrypted requests," this feature applies to sites we don't already know support HTTPS. Since we aren't sure if these sites support HTTPS at all, we also aren't sure if the security upgrade will be successful. We try to upgrade the connection and if it fails, we present the user with a screen that explains what happened, and allows the user to disable HTTPS Everywhere for that specific site if they wish to access the insecure HTTP site anyway.

Soon to be renamed "Encrypt All Sites Eligible (EASE)", this helps to ensure that the user avoids ever connecting over an insecure HTTP site unless they explicitly opt into doing so. Projects like Let's Encrypt have made security on the web so widespread that we believe the user experience when you turn this feature on is not significantly impeded for most users.

Over time, attacks targeting insecure HTTP have only gotten more sophisticated. QuantumInsert, a program developed and employed jointly by the NSA and GCHQ and revealed in the Snowden leaks, redirects HTTP requests to websites containing malware. In 2015, China used its nationwide Internet infrastructure to rewrite incoming HTTP Baidu Analytics JavaScript requests, hijacking users’ browsers to conduct an attack on GitHub. It is only safe to assume that more sophisticated attacks on HTTP will appear over time. With EASE, these types of HTTP attacks on your browser are rendered impossible.

HTTPS Everywhere 2020 and Beyond

Between the browsers' built-in HSTS preload list, HTTPS Everywhere's own list of sites, and enabling EASE mode, we believe HTTPS Everywhere helps deliver the safest browsing experience available today. In the future, we would love to see browsers deprecate the insecure and outdated HTTP transport layer entirely.

Until then, using HTTPS Everywhere (in combination with extensions that protect you from trackers after the secure connection is made, such as our own Privacy Badger) remains an important tool in your toolbox for keeping yourself safe on the world wide web.

Related Updates

More lessons from "Facebook Research"Last week, Facebook was caught using a sketchy market research app to gobble large amounts of sensitive user activity after instructing users to alter the root certificate store on their phones. A day after, Google pulled a similar iOS “research program” app. Both of...

This article was first published on Lawfare. The most recent purportedly serious proposal by a Western government to force technology companies to provide access to the content of encrypted communications comes from Ian Levy and Crispin Robinson of the Government Communications Headquarters, or GCHQ, the U.K.’s...

Tracking is everywhere on the Internet. Over the past year, a drumbeat of tech-industryscandals has acclimated users to the sheer number of ways that personal information can be collected and leaked. As a result, it might not come as a surprise to learn that emails...

This article was first published on Just Security. Government Communications Headquarters (GCHQ), the UK’s counterpart to the National Security Agency (NSA), has fired the latest shot in the crypto wars. In a post to Lawfare titled Principles for a...

We saw 2017 tip the scales for HTTPS. In 2018, web encryption continues to improve. EFF has begun to shift its focus towards email security, and the security community is shifting its focus towards further hardening TLS, the protocol that drives encryption on the Internet. By default, all Internet...

This wasn’t a great year for those of us whose job it is to defend the use of encryption. In the United States, we heard law enforcement officials go on about the same “going dark” problem they’ve been citing since the late 90s, but even after all these years...

Earlier this week, Google dropped a bombshell: in March, the company discovered a “bug” in its Google+ API that allowed third-party apps to access private data from its millions of users. The company confirmed that at least 500,000 people were “potentially affected.” Google’s mishandling of data was bad...