HSTSがサポートされているブラウザーがあるのに、なぜHTTPS Everywhereを使用するのですか？
ブラウザにアクセスするためのデフォルトのプロトコルはhttp:// いつ https://は明示的に言及されていませんが、それでもウェブサイトを閲覧する場合はwww.facebook.com、Facebookサーバーからの応答ヘッダーには [〜＃〜] hsts [〜＃〜] が記載され、ブラウザはhttp://からhttps://では、ブラウザ自体がユーザーに対してこれを行うときに、なぜこれを行うために別のプラグインが必要なのでしょうか。 HTTPS Everywhere の目的は何ですか？私たちのブラウザーがデフォルトでそれを実行します。
それでも、www.facebook.comなどのWebサイトを参照した場合、Facebookサーバーからの応答ヘッダーにはHSTSが記載されます。
curlリクエストをhttp://www.facebook.comに送信しました。
< 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
ご覧のとおり、HSTSヘッダーはありません。仕様によると （RFC6797） ：
HSTSホストは、非セキュアなトランスポートを介して伝達されるHTTP応答にSTSヘッダーフィールドを含めてはなりません（MUST NOT）。
WebブラウザーもHSTSヘッダーを無視します HTTP応答：
注：Strict-Transport-Securityヘッダーは、サイトがHTTPを使用してアクセスされる場合、ブラウザーによって無視されます。これは、攻撃者がHTTP接続を傍受し、ヘッダーを挿入または削除する可能性があるためです。証明書エラーなしでHTTPS経由でサイトにアクセスすると、ブラウザーはサイトがHTTPS対応であることを認識し、Strict-Transport-Securityヘッダーを受け入れます。
HSTSの目的は、クライアントがHTTPS経由でWebサイトにアクセスしたときにHTTPに切り替えないようにクライアントに指示することであり、その逆ではありません。 Wikipedia から：
HTTP Strict Transport Security（HSTS）は、プロトコルのダウングレード攻撃やCookieハイジャックからWebサイトを保護するのに役立つWebセキュリティポリシーメカニズムです。
ダウングレード攻撃は、コンピュータシステムまたは通信プロトコルに対する攻撃の一種であり、高品質の動作モード（暗号化された接続など）を放棄し、古い低品質の動作モード（クリアテキストなど）を優先します。古いシステムとの下位互換性のためにあります。
そのため、HSTSヘッダーは、新しいHTTP接続をHTTPSにリダイレクトするために使用されるのではなく、ブラウザーが既存のHTTPSサイトにHTTPリクエストを送信しないようにするために使用されます。
一方、 HTTPS Everywhere プラグインは、WebブラウザーがHTTPSをサポートするWebサイトにHTTPS接続することを保証しますが、HTTP経由でもアクセスできます。
Web上の多くのサイトでは、HTTPSを介した暗号化のサポートが制限されていますが、使用が困難です。たとえば、暗号化されていないHTTPにデフォルト設定したり、暗号化されていないサイトに戻るリンクで暗号化されたページを埋めたりすることができます。 HTTPS Everywhere拡張機能は、巧妙な技術を使用してこれらのサイトへの要求をHTTPSに書き換えることにより、これらの問題を修正します。
HSTSは Trust on First Use モデルを使用します。サイトへの最初の接続が既に危険にさらされている場合、後続の要求でHSTSエラーを受信しない可能性があります。
HTTPS Everywhereは、最初の接続からサイトがHTTPS専用サイトであることをブラウザーに通知することにより、この穴をふさぎます。
また、一部のWebサイトは、HTTPSをサポートしている場合でもHSTSヘッダーをアドバタイズしません。または、HTTPSが別のドメイン/パスにある場合があります（例：http://www.example.com だが https://secure.example.com）、HTTPS Everywhereは、サイトのURLを書き換えることにより、これらの状況を解決しようとします。
HTTPS Everywhereはクライアント側であり、HSTSはサーバー側です。
したがって、答えは、サーバーがHSTSヘッダーを設定しない場合にHTTPS Everywhereが防御することです。
HSTSはウェブサイト運営者の裁量に任されています。彼らは、必須HTTPSのセキュリティ上の利点が追加のサーバー負荷に見合う価値があるか、HTTPSを使用できないユーザーをブロックし、キャッシュプロキシを無効にするかを決定する必要があります。必須HTTPSはHSTSの前提条件です。
多くのサイトはHTTPSをオプションで提供していますが、それを使用するかどうかは通常、エンドユーザーではなく、リンクまたはURLを提供する人が選択します。 HTTPS Everywhereでは、リンクまたは入力されたURLがHTTPを使用していても、ユーザーはそのようなサイトでHTTPSを使用できます。
より多くのサイトがHTTPSを必須にし、HSTSを導入してプレーンテキストリダイレクトからのセキュリティリスクを減らすにつれて、「HTTPS Everywhere」の必要性は少なくなりますが、HTTPSを提供するすべてのサイトがそうするまでは、有用なプラグインになります。
問題は誤った前提にあります。
... www.facebook.comなどのWebサイトを参照すると、Facebookサーバーからの応答ヘッダーにHSTSが表示され、ブラウザから
http://からhttps://...
真実ではない*。 Strict-Transport-SecurityヘッダーはHTTPヘッダーです。HSTS仕様では、サーバーは暗号化チャネルを介して送信される応答にのみヘッダーを含める必要があり、非暗号化チャネルを介して送信される場合はクライアントがヘッダーを無視する必要があります。から RFC 6797 ：
HTTP Strict Transport Security Host：HSTSポリシーのHTTPサーバーの側面を実装する適合ホストです。これは、HSTSホストがセキュアなトランスポートを介して送信されたHTTP応答メッセージで「Strict-Transport-Security」HTTP応答ヘッダーフィールドを返すことを意味します。
...
HTTPホストは、HSTSポリシーをUAに発行することにより、HSTSホストを宣言します。これは、セキュアなトランスポート（TLSなど）上のStrict-Transport-Security HTTP応答ヘッダーフィールドによって表され、伝えられます。
...
HSTSホストは、非セキュアなトランスポートを介して伝達されるHTTP応答にSTSヘッダーフィールドを含めてはなりません（MUST NOT）。
...
安全でないトランスポートを介してHTTP応答が受信された場合、UAは現在のSTSヘッダーフィールドを無視する必要があります。
* OK、Facebookのサーバーとブラウザの両方がHSTS仕様に違反している可能性を除外します。また、HSTSを備えた適切に構成されたサーバーは、通常、ポート80をリッスンしないか、永続的なリダイレクトをHTTPS URLに送信するようにも構成されます。ただし、その制限についてはRFCのセクション7.2を参照してください。
HSTSのプリロードについて触れた回答はまだありません。要約すると、@ Lie Ryan などの既存の回答で言及されている警告：
HSTSは Trust on First Use モデルを使用します。サイトへの最初の接続が既に危険にさらされている場合、後続の要求でHSTSエラーを受信しない可能性があります。
（…）
また、一部のWebサイトは、HTTPSをサポートしている場合でもHSTSヘッダーをアドバタイズしません。
preloaded であるWebサイトには適用されません。つまり、Webブラウザーに組み込まれているリストに含まれています。このリストにあるサイトは、HTTPS Everywhereと同様に、最初のアクセス時でも常にHTTPSに書き換えられます。
このため、HTTPS Everywhereのメンテナーは decided を持っています。これは、プリロードリストのWebサイトが、HTTPS EverywhereのURIデータベースに追加されない（また、削除される可能性がある）ことを示しています。
多くのドメインでHSTSが正しく構成されていません。たとえば、Googleではwww.google.comとそのサブドメインにHSTSがありますが、google.comとそのサブドメインにはありません。したがって、HSTSは https://google.com または https://www.google.comにアクセスした結果としてmail.google.comまたはdrive.google.comに適用されません。
Googleがこのような設定をしている理由は複雑です。Chrome HSTSプリロードリストを取得するための要件は、ドメインとそのサブドメインにHSTSがあることです。Googleにはいくつかの内部およびおそらくパブリックがあると思いますHTTPSを介して機能しないサービスに対応しているため、Google.comのすべてのサブドメインのHSTSはこれらのサービスを中断します。すべてのwww.google.comドメインのHSTSは、www.google.comのみをカバーします。 * .www.google.comのサブドメイン。
ただし、HTTPS Everywhereには、そのような複雑な使用例を可能にするHSTSよりもはるかに複雑なルールを設定できます。
私は特にStack Exchange自体にHTTPS Everywhereを使用しています。前回チェックしたとき（数か月前）はHSTSを使用せず、HTTPからHTTPSにリダイレクトすることもありませんでした。しかし、それはHTTPSを提供していたので、アドオンは潜在的な盗聴から私を救いました。
Stack Exchangeについては、状況が変わった可能性があります。