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.
![](../../users/profiles/118511.webp)
- 882
- 1
- 7
- 16
-
29HTTPS Everywhere is older than HSTS. While the answers below do explain why it's still useful now, don't forget that it takes a long time for a proposal to be accepted and published, and then another long time for it to be widely used. – curiousdannii Apr 26 '17 at 13:22
-
4Because if someone links to an image on `http://not-safe-for-work.com` on the HTTPS site your on, and `not-safe-for-work.com` doesn't use HSTS, then bad things happen – Neil McGuigan Apr 26 '17 at 18:34
-
16HTTPS Everywhere was mostly designed around the use case of "websites which have a working HTTPS version but don't advertise it". Back in the day even Google served the HTTPS version on "encrypted.google.com". The number of websites having HTTPS enabled but not redirecting to it from HTTP/using HSTS is not exactly small, as evidenced by their commit logs and ruleset sizes. – Apr 27 '17 at 07:57
-
@user2064000 As I recall, `https://google.com` *did* redirect to `https://encrypted.google.com`; at that time I was so fresh to (and excited by) SSL, that I was manually typing all of my urls. – jpaugh Apr 27 '17 at 22:04
8 Answers
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.
![](../../users/profiles/13154.webp)
- 2,768
- 16
- 23
![](../../users/profiles/2755.webp)
- 31,089
- 6
- 68
- 93
-
How can a plugin rewrite a URL when it is not aware of the subdomains of the website the user is visiting? – GypsyCosmonaut Apr 26 '17 at 03:44
-
36@GypsyCosmonaut HTTPS Everywhere is connected with its database. Extensions can re-write & redirect URLs , add and remove scripts. That's why you have to be careful which extension to trust. – defalt Apr 26 '17 at 04:24
-
16HSTS preloading also plugs the trust on first use hole, but if a site isn't advertising HSTS, it *cannot* be a candidate for HSTS preloading. So that's another aspect covered by the HTTPS Everywhere browser extension not covered by HSTS. – user Apr 26 '17 at 09:08
-
1For the record, all entries of the HTTPS Everywhere database can be browsed at https://www.eff.org/https-everywhere/atlas/. An example for which "secure" is currently prepended to requests is https://www.eff.org/https-everywhere/atlas/domains/mbl.is.html – fuglede Apr 29 '17 at 20:14
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.
![](../../users/profiles/8754.webp)
- 29,018
- 7
- 95
- 119
-
2I believe HTTPS Everywhere also attempts to upgrade resources loaded by the page if they are using `http`. – IllusiveBrian Apr 26 '17 at 00:36
-
14Also, HSTS headers are ignored unless you're already visiting a site over HTTPS. – Sam Dufel Apr 26 '17 at 01:15
-
2To clarify, while HSTS is set from the server side, it is up to the client to respect it. – multithr3at3d Apr 26 '17 at 01:41
-
-
1@korockinout13 Yes, that is correct. My answer was mainly focused on "who employs this defense mechanism" as I think that that is the most relevant. – tim Apr 26 '17 at 09:43
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.
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.
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.
![](../../users/profiles/79347.webp)
- 4,918
- 1
- 21
- 26
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://
tohttps://
...
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.
![](../../users/profiles/20403.webp)
- 161
- 5
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.
![](../../users/profiles/1428.webp)
- 188
- 7
-
8Your first paragraph is covered by the accepted answer, your second paragraph hints at something but never explains it - can you expand on your last statement? – schroeder Apr 26 '17 at 06:34
-
1I disagree. That answer covers subdomains, and www isn't an normal subdomain in may respects. While I can improve my answer, both paragraphs are related. – seanieb Apr 27 '17 at 21:56
-
So, for instance, complex rules to redirect unconfigured subdomains? Your last statement just kinda hangs there ... – schroeder Apr 28 '17 at 06:19
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.
![](../../users/profiles/13154.webp)
- 2,768
- 16
- 23
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.
![](../../users/profiles/123693.webp)
- 211
- 1
- 8
-
Stack Exchange only uses HTTPS at login pages, not on the whole website. This saves extra overhead and therefore helps load pages faster. HTTPS Everywhere can't do anything in that. – GypsyCosmonaut Apr 26 '17 at 16:52
-
@GypsyCosmonaut I just checked, both http and https versions of stackoverflow.com main page are available. – Neith Apr 26 '17 at 16:55
-
4(@GypsyCosmonaut) Stack using https almost everywhere is recent: https://meta.stackexchange.com/questions/292058/network-wide-https-its-time – dave_thompson_085 Apr 27 '17 at 04:36
-
-
Just remember to disable HTTPS everywhere before logging in to Area51! For whatever reason, it's not supported there. – jpaugh Apr 27 '17 at 22:09