「HTTPS Everywhere」はまだ関連していますか？
HTTPS Everywhere はブラウザの拡張機能であり、Tor ProjectとElectronic Frontier Foundationの間のコラボレーションであり、HTTP URLのリクエストを安全なHTTPS代替（可能な場合）に書き換えることを自動化します。およそ10年前から存在しているようですが、最近誰かが質問するまで私のレーダーにはありませんでした。それを研究しようとすると、情報の混合バッグが生成されました。
必要性に関係なく、「すぐに使える」ことの有用性が明確ではありません。さまざまな記事で、完全なメリットを得るために、デフォルトをホワイトリストとルールで補足する必要性について言及しています。そのため、実装は簡単な作業ではないようです。
少なくとも一度は、Webサイトのかなりの部分がHTTP専用であったため、そのようなソフトウェアを使用してもメリットは限定的でした。機密の個人データを扱うサイトは、ほとんどHTTPSのみに移行しているようです。 Googleは、HTTPSに変換するようにWebサイトにインセンティブを与えるためのさまざまな手段を実装しました。 HTTPの問題の大きさがまだはっきりしていない（まだ問題がある場合は、問題がすぐに消えるのかどうか）。
HTTPSに変換するサイトがレガシービジターのためだけにHTTPリンクを保持していて、自動的にHTTPSサイトにリダイレクトするかどうかも明確ではありません。
主要なブラウザはすべて、利用可能な場合にHTTPSサイトを優先するロジックが組み込まれているか、または実装のプロセスに進んでいるようです。少なくともGoogle（他の検索エンジンについては何も見ていません）には、同じ名前のプログラム（実際に同じ製品かどうかは不明）があり、検索時にHTTPS接続を自動的に試行します。
3年ほど前、「HTTPS Everywhereをインストールする必要がある理由」に関する記事がありました。最近の記事の多くは、人々がこのソフトウェアをインストールすることを提案するのをやめるべきだと示唆しています。 Gistは、すでに機能を複製しているブラウザーに関連しているようです。
したがって、HTTPが依然として解決策を必要とする実質的な問題であるかどうか、また、そうである場合、HTTPSリンクを最初に試行するソフトウェアが残りの問題を解決できるかどうかは不明です。この問題全体がイベントに追い越されていますか？
私は意見ではなく文脈を探しています（つまり、それがどれほど良いか悪いか、またはソフトウェアが必要かどうかについての意見ではなく、現在の状況を説明する事実）。たとえば、主要なブラウザは現在、HTTPS Everywhereが開発されたための救済策を提供していますか？現在、HTTPは実質的に個人データのないサイトに限定されていますか？これを問題としないことを目的とした政府または業界の規制はありますか？言い換えれば、私（および他の人）が自分の意見を形成し、自分との関連性を判断するために現在の状況を理解できるような客観的な情報。
HTTPS Everywhereは、混合コンテンツや中途半端なWebサイト構成の時代には、より必要でした。 [〜＃〜] hsts [〜＃〜] のようなテクノロジーはどのサイトでも使用でき、 public key pinning より大きなプレーヤー（現在は非推奨 Certificate Transparency -通知してくれたJustinに感謝）.
したがって、拡張機能が役立つかどうかは、個々のユースケースに大きく依存します。 HTTPとHTTPSの両方を提供するWebサイト用にカスタムルールを作成することは、拡張機能が優れている点であり、同様の仕事をする他の人には気づいていません。 WebサイトがHTTPSをサポートしていない状況でも、拡張機能により、元の参照がプロトコル中立であっても、CDNなどのサードパーティドメインへの参照がHTTPSにアップグレードされます。
HTTPS Everywhereの以前のルールセットコントリビューターと言えば、私は以下を提供できます。
HTTPS Everywhereプロジェクトは、定期的にすべての書き換えルールをテストし、何らかの理由で失敗したルールを無効にします。これにより、Webサイト構成の変更に対する比較的迅速な対応が保証されますが、大幅なメンテナンス作業を費やさない限り、ルールセットのかなりの部分が無効になる可能性があります。中央のルールセットが補足されるべきであるという提案は、主にこれらの中央のルールセットが修正可能であり、修正されるべきであるという無知から生じます。それはボランティアの可用性の問題です。
WebをHTTPSのみに移行することで大きな進歩がありましたが、多くのサイトは依然として誤って構成されており、多くのサイトは最初の接続攻撃を防ぐために必要な重要なHSTSプリロード保護を実装していません。この保護を実装するサイトはその後まもなくHTTPS Everywhereのルールセットから削除されます。
Webブラウザーテクノロジーは非常に便利ですが、HSTSプリロードリストを超えて何をするにしても、それは素晴らしいことです。 HTTPS Everywhereは、ブラウザーを介してHSTSを有効にしておらず、基本的にコミュニティが管理するカスタムHSTS構成を必要とするサイトに一時的なギャップを提供します。
要約すると、インストールしたままにしても害はありません。あと数年はそれに耐えて、うまくいけばこれがすべて冗長になるでしょう。
HTTPSとHSTSの認識が向上したことで、セキュリティ標準が前進したことは確かですが、HTTPS Everywhere拡張機能の使用は引き続き存在します。
HSTSはHTTPダウングレード攻撃からの保護に優れていますが、最初に使用するモデルへの信頼に基づいていることに注意してください。これは、サイトへの最初の接続がHTTPSを介する必要があることを意味します。そうしないと、HSTS保護が侵害される可能性があります（たとえば、HTTPからHTTPS 301へのリダイレクトは、攻撃の機会の窓です）。
HSTSは通常、これをHTSTプリロードリスト（ブラウザーに組み込まれたドメインのリスト）で保護します。これにより、最初の接続でこれらのサイトのHTTPSのみが使用されるようになります。ただし、リストに入る（およびブラウザーに変更が適用されるのを待つ）には時間がかかり、すべてのサイトが自分自身を登録する必要はありません。これは、すべての最初の接続がHTTPSのみを介して行われることを保証することにより、ブラウザ拡張機能が役立つ場所です。
もう1つの小さなケースは、WebサイトのHTTPSが通常とは異なるパスにある場合です。たとえば、Webサイトには http：//www.example があり、セキュアなサイトは https：//secure.example にある場合があります。 HTTPS Everywhereは、ドメインのデータベースを保持して、HTTPSの正しいURLにアクセスできるようにします。
脚注：公開鍵のピン留めも役立ちますが、Chrome=でさえ、採用率が低く、フットガンになる可能性があるため、削除することにしました。
Httpsをサポートしているが、httpトラフィックをhttpsにリダイレクトしないWebサイトがまだいくつかあることに気づきました。ただし、拡張機能は以前ほど便利ではありません。数年前のyoutube、wikipedia、redditなどのWebサイトでは、httpsがサポートされていましたが、デフォルトはhttpでした。 HTTPSはどこでもそれを解決し、まだデフォルトでhttpになっているがhttpsをサポートしている少数のWebサイトの問題を解決しています。
私はいつもHTTPS Everywhereが SSL-strip 攻撃を防ぐために開発されたと思っていましたが、これは副作用にすぎないかもしれません。ただし、SSLストリップは依然として問題であり、HTTPS Everywhereを使用すれば防止できます。
攻撃者がユーザーをだまして最初のリクエストにHTTPを使用するように仕向けると、通信を傍受し、HTTPSを使用してサーバーに接続し、応答を変更してユーザーに返すことができます。それは例えば結果のすべてのリンクを変更して、SSLを使用しないようにするか、攻撃者の制御下にあるHTTPS URLに接続するように書き換えることができます。
これがHTTPS-everywhereがジャンプする場所であり、この最初のHTTPリクエストはHTTPSとして実行されるため、攻撃者はトラフィックを傍受することができません。