Perché utilizzare HTTPS Everywhere quando disponiamo di browser supportati da HSTS?

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

Ho fatto una richiesta di curl a http://www.facebook.com e questo è quello che ho ottenuto:

< 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

Come puoi vedere non c'è un'intestazione HSTS qui, perché in base alla sua specifica (RFC6797) :

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

I browser Web ignorano anche le intestazioni HSTS nelle risposte http://

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.

Lo scopo di HSTS è di dire al client di NON passare a HTTP dopo che ha effettuato l'accesso a un sito web su HTTPS, e non viceversa. Da Wikipedia :

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

Attacco di downgrade del protocollo :

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.

Quindi un'intestazione HSTS non viene utilizzata per reindirizzare una nuova connessione HTTP a HTTPS, ma piuttosto per impedire a un browser di effettuare richieste HTTP a un sito HTTPS esistente.

Il plug-in HTTPS Everywhere d'altra parte garantisce che il browser Web effettui connessioni HTTPS a siti Web che supportano HTTPS, ma sono accessibile anche via 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 utilizza un modello Trust for First Use . Se la prima connessione al sito è già stata compromessa, potresti non ricevere un errore HSTS sulle richieste successive.

L'HTTPS Everywhere chiude questo buco, facendo sapere al tuo browser che il sito è un sito HTTPS solo dalla prima connessione.

Inoltre, alcuni siti Web non pubblicizzano un header HSTS anche se supportano HTTPS. Oppure potrebbero avere il proprio HTTPS in un dominio / percorso diverso (ad esempio http://www.example.com ma https://secure.example.com ), HTTPS Everywhere tenta di aiutare con queste situazioni riscrivendo gli URL del sito.

HTTPS Ovunque è lato client e HSTS è lato server.

Quindi la risposta è che HTTPS Everywhere è da difendere nei casi in cui il server non imposta un'intestazione HSTS.

HSTS è a discrezione dell'operatore del sito web. Devono decidere se i benefici di sicurezza dell'HTTPS obbligatorio valgono il carico extra del server, il blocco degli utenti che non possono utilizzare HTTPS e rendere inefficaci i proxy di memorizzazione nella cache. L'HTTPS obbligatorio è un prerequisito per HSTS.

Molti siti offrono HTTPS facoltativamente, ma il fatto di usarlo o meno viene normalmente scelto non dall'utente finale ma dalla persona che fornisce un link o un URL. HTTPS Everywhere consente agli utenti di utilizzare HTTPS su tali siti, anche quando il link o l'URL digitato utilizzato HTTP.

Poiché più siti rendono HTTPS obbligatorio e introducono HSTS per ridurre il rischio di sicurezza dai reindirizzamenti in testo chiaro, sarà necessario meno "HTTPS Everywhere", ma fino a quando non tutti i siti che offrono HTTPS lo faranno sarà comunque un utile plugin.

La domanda si basa su false premesse.

...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://...

non è vero *. Sebbene l'intestazione Strict-Transport-Security sia un'intestazione HTTP, la specifica HSTS richiede ai server di includerla solo nelle risposte inviate su un canale crittografato e richiede ai client di ignorarla se inviata su un canale non crittografato. Da 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, escludo la possibilità che sia il server di Facebook sia il tuo browser violino le specifiche HSTS. Ed è vero che un server ben configurato con HSTS sarà in genere anche configurato per non ascoltare sulla porta 80 o inviare un reindirizzamento permanente a un URL HTTPS. Ma vedi la sezione 7.2 della RFC sui limiti di ciò.

Vedo che nessuna delle risposte è stata applicata al precaricamento dell'HSTS. Per riassumere: le avvertenze citate nelle risposte esistenti, come ad esempio @ Lie Ryan :

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.

non si applicano ai siti web che sono precaricati ; cioè, sono su una lista che è integrata nel browser web. I siti di questo elenco, come con HTTPS Ovunque, verranno sempre riscritti su HTTPS, anche durante la prima visita.

Per questo motivo, i maintainer di HTTPS Everywhere hanno deciso che i siti web nell'elenco di precaricamento non vengono aggiunti a (e può essere rimosso da) il database degli URL di HTTPS Everywhere da riscrivere.

Molti domini non hanno HSTS configurato correttamente. Ad esempio, Google ha HSTS su www.google.com e i suoi sottodomini, ma non su google.com e sui relativi sottodomini. Pertanto, HSTS non viene applicato su mail.google.com o su drive.google.com a seguito della visita del link o link

Il motivo per cui Google ha una tale configurazione è complesso. I requisiti per ottenere l'elenco precarico Chrome HSTS sono che hai HSTS per un dominio e relativi sottodomini. Presumo che Google abbia alcuni servizi interni e, forse, rivolti al pubblico che non funzionano su HTTPS. Quindi gli HSTS per tutti i sottodomini di Google.com interromperanno tali servizi. HSTS per tutti i domini www.google.com copre solo www.google.com, in quanto non ha alcun sottodominio in * .www.google.com.

Tuttavia, HTTPS Everywhere può disporre di regole molto più complesse rispetto all'HSTS che consentono casi d'uso complessi.

Uso HTTPS Ovunque specificamente per Stack Exchange. L'ultima volta che ho controllato (diversi mesi fa) non ha usato HSTS e non ho nemmeno reindirizzato da HTTP a HTTPS. Tuttavia, forniva HTTPS, quindi il componente aggiuntivo mi ha salvato da potenziali intercettazioni.

Come per Stack Exchange, la situazione potrebbe essere cambiata ora.