Why use HTTPS Everywhere when we have HSTS supported browsers?

Question

I know that the browser's default protocol to access any site is http:// when https:// is explicitly not mentioned, but even then if we browse to a website say www.facebook.com, the response header from the Facebook servers would have HSTS mentioned and our browser would direct us from http:// to https:// so why do we need another plugin to do this when browser itself does this for the user? What is the purpose of HTTPS Everywhere when our browser does it's job by default.

Answer 1

HSTS uses a Trust on First Use model. If your first connection to the site was already compromised, you may not receive an HSTS error on subsequent requests.

The HTTPS Everywhere plugs this hole, by letting your browser know that the site is an HTTPS only site from the first connection.

Also, some websites don't advertise an HSTS header even when they support HTTPS. Or they may have their HTTPS be in a different domain/path (e.g. http://www.example.com but https://secure.example.com), HTTPS Everywhere attempts to help with these situations by rewriting the site's URLs.

Answer 2

HTTPS Everywhere is client-side, and HSTS is server-side.

So the answer is that HTTPS Everywhere is to defend in cases where the server does not set an HSTS header.

Answer 3

even then if we browse to a website say www.facebook.com, the response header from the Facebook servers would have HSTS mentioned

I made a curl request to http://www.facebook.com and this is what I got:

< HTTP/1.1 302 Found
< Location: https://www.facebook.com/
< Content-Type: text/html
< X-FB-Debug: zgK/A+8XSlghi/vWvAivsZ04gawpdr+3BuO7yuQaKDdrP/+B14oSVDSreHh0GbchyNPnav39pQq9Zgw5mSXX5A==
< Date: Sat, 29 Apr 2017 19:23:25 GMT
< Connection: keep-alive
< Content-Length: 0

As you can see there is no HSTS header here, because according to its specification (RFC6797):

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

Web browsers also ignore HSTS headers in HTTP responses:

Note: The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.

The purpose of HSTS is to tell the client NOT to switch to HTTP once it has accessed a website over HTTPS, and not the other way round. From Wikipedia:

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking.

Protocol downgrade attack:

A downgrade attack is a form of attack on a computer system or communications protocol that makes it abandon a high-quality mode of operation (e.g. an encrypted connection) in favor of an old, lower-quality mode of operation (e.g. clear text) that is there for backward compatibility with older systems.

So a HSTS header isn't used to redirect a new HTTP connection to HTTPS, but rather to prevent a browser from making HTTP requests to an existing HTTPS site.

The HTTPS Everywhere plugin on the other hand ensures the web browser makes HTTPS connections to websites that support HTTPS, but are also accessible over HTTP.

Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site. The HTTPS Everywhere extension fixes these problems by using clever technology to rewrite requests to these sites to HTTPS.

Answer 4

HSTS is at the discretion of the website operator. They must decide whether the security benefits of mandatory HTTPS are worth the extra server load, blocking of users who can't use HTTPS and rendering caching proxies ineffective. Mandatory HTTPS is a prerequisite for HSTS.

Many sites offer HTTPS optionally but whether or not to use it is normally chosen not by the end user but by the person providing a link or URL. HTTPS Everywhere allows users to use HTTPS on such sites, even when the link or typed URL used HTTP.

As more sites make HTTPS mandatory and introduce HSTS to reduce the security risk from plaintext redirects there will be less need for "HTTPS Everywhere", but until/unless all sites that offer HTTPS do so it will still be a useful plugin.

Answer 5

The question rests on false premises.

...if we browse to a website say www.facebook.com, the response header from the Facebook servers would have HSTS mentioned and our browser would direct us from http:// to https://...

is not true*. Although the Strict-Transport-Security header is an HTTP header, the HSTS specification requires servers to include it only in responses which are sent over an encrypted channel, and requires clients to ignore it if sent over a non-encrypted channel. From RFC 6797:

HTTP Strict Transport Security Host: is a conformant host implementing the HTTP server aspects of the HSTS Policy. This means that an HSTS Host returns the "Strict-Transport-Security" HTTP response header field in its HTTP response messages sent over secure transport.

...

An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS Policy, which is represented by and conveyed via the Strict-Transport-Security HTTP response header field over secure transport (e.g., TLS).

...

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

...

If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).

---

* Ok, I'm excluding the possibility that both Facebook's server and your browser violate the HSTS spec. And it is true that a well configured server with HSTS will typically also be configured to either not listen on port 80 or send a permanent redirect to an HTTPS URL. But see section 7.2 of the RFC on the limitations of that.

Answer 6

A lot of domains don't have HSTS configured correctly. For example Google has HSTS on www.google.com and it's subdomains, but not on google.com and its subdomains. So HSTS is not enforced on mail.google.com or drive.google.com as a result of visiting https://google.com or https://www.google.com

The reason Google has such a setup is complex.The requirements to get on the Chrome HSTS preload list are that you have HSTS for a domain and its subdomains. I assume Google has some internal and perhaps public-facing services that don't work over HTTPS. So HSTS for all subdomains of Google.com would break those services. HSTS for all www.google.com domains really only covers www.google.com, as it doesn't have any subdomains at *.www.google.com.

However, HTTPS Everywhere can have rules that are much more complex than HSTS that allow for such complex use cases.

Answer 7

I see none of the answers have touched on HSTS preloading yet. To summarize: the caveats mentioned in existing answers, such as @Lie Ryan's:

HSTS uses a Trust on First Use model. If your first connection to the site was already compromised, you may not receive an HSTS error on subsequent requests.

(…)

Also, some websites don't advertise an HSTS header even when they support HTTPS.

do not apply to websites which are preloaded; that is, they are on a list that's built into the web browser. Sites on this list will, like with HTTPS Everywhere, always be rewritten to HTTPS, even during the first visit.

For this reason, HTTPS Everywhere's maintainers have decided that websites on the preload list will not get added to (and may be removed from) HTTPS Everywhere's database of URI's to rewrite.

Answer 8

I use HTTPS Everywhere specifically for Stack Exchange itself. Last time I checked (several months ago) it did not use HSTS and did not even redirect from HTTP to HTTPS. However, it did provide HTTPS, so the add-on saved me from potential eavesdropping.

As for Stack Exchange, the situation may have changed now.