静的コンテンツにHTTPSが必要なのはなぜですか？最後に秘密鍵で署名されたチェックサムを取得できる場合、それは有効性を証明しませんか？
私が話しているこの方法は、ブラウザのキャッシュに依存するだけでなく、ISPによる画像、ビデオ、CSSのキャッシュを改善することができます。また、送信者の有効性も証明します。このセミHTTPが考慮されない理由はありますか？
非対称署名のコストは、私が考えることができる1つのことです。しかし、静的コンテンツのチャンクをグループ化し、sha256チェックサムをバッチで計算する場合、ブラウザーでの署名の検証は、ブラウザーキャッシュにない各リクエストのエンドツーエンドのネットワークコストよりも優れたトレードオフになる可能性があります。
静的コンテンツにHTTPSが必要なのはなぜですか？秘密鍵で署名されたチェックサムを最後に持つことができる場合、それは有効性を証明しませんか？
あなたはその質問でストローマンを設置していると思います。実際、静的コンテンツにHTTPSは必要ありません。HTTPSの目的は、コンテンツの有効性を証明することだけではありません。それはいくつかの目的のoneです。過去数年で膨大な数のサイトをHTTPS（ウィキペディアなどの無害な静的コンテンツを提供するサイトも含む）に切り替える動きは、人々が間違ったコンテンツを取得することを心配していたため、主に起こりませんでした。それは、3文字のエージェンシーがユーザーをスパイするのを心配しているからです。例えばHTTPSへの大規模な移行は、主にプライバシー上の理由で発生しました（たとえば、 RFC 7258、Pervasive Monitoringは攻撃です -これを指摘してくれたMichaelKjörlingのおかげです）。
署名付きチェックサムを使用するというあなたのアイデアは、すでにインターネット全体で生産されています。ダウンロードするソフトウェアは、そのように検証されることがよくあります。ほとんどのオペレーティングシステムのパッケージマネージャー/更新システムがこれを行います。個々のソフトウェアプロジェクトは、ソフトウェアダウンロードと共にpgp/gpg署名を発行することにより、小規模でこれを行います。
これはすべて、これらのダウンロードがhttps経由で配信されるかどうかに関係なく機能しますが、httpsはよく使用されますさらに。
Httpおよびhttps以外の3番目のプロトコルを追加することをお勧めします。「検証済み」の場合はhttpvと呼ばれるもので、プロトコルにコンテンツ検証を構築しますが、残りのsslは除外します。
キャッシュできるように、いくつかの静的コンテンツを平文で提供することには利点があることに同意します。しかし、すべてのコミュニケーションをスパイするインテリジェンスコミュニティのプログラムに照らしてプライバシーの問題を心配している場合、これはオプションではありません。
このセミHTTPが考慮されない特別な理由は何ですか？
だから私はあなたの3番目のプロトコルが多くのSteamを集めることができないと思います
コンテンツを検証する必要がある場合に機能するソリューションがすでにあります。
プライバシーを保護するためにインターネットの多くが暗号化されるようになったため、保護しなかった別のプロトコルはあまり使用されないようですスパイに対して。
あなたの提案は、基本的にHTTPSを2つに分割することです：署名のみと暗号化：署名のみは、途中のアクティブな人が自分のコンテンツ（スクリプトタグなど）を注入することを防ぎ、暗号化は機密データを保護します。
しかし、機密データが何で何がそうでないかは誰が決めるのでしょうか。これは時間がかかり、エラーが発生しやすいようです。
もちろん、画像、CSS、ビデオ、JSファイルを機密ではないと自動的に宣言することもできます。しかし、そうでしょうか？
- JSファイルはデータ交換に使用されます
- 画像や動画には機密性の高いデータが含まれている可能性があります
- CSSファイルは、ユーザーがどの特定のページを表示しているかについての洞察を提供する場合があります
- すべてのリクエストには、HTTPヘッダー応答に機密データが含まれている可能性があります（設定されているCookieなど）
あなたのアイデアには、他にもいくつかの変更が必要です。
- HSTSについてはどうですか？ HTTPS経由のすべてのトラフィックを強制するため、強くお勧めします。サインオンリーHTTPはカウントされますか？実際にはどのように機能しますか？
- 使いやすさはどうですか？ブラウザインターフェイスは、現在使用されている「モード」をユーザーに示す必要があります。そして、それは、モードが何を意味するのか、そしてどのモードが適切であるのかについて、ユーザーのさらなる教育を必要とするでしょう。これは多くの混乱を招きます（ユーザーは、南京錠やさまざまな警告など、現在のインターフェースのすべての要素さえ理解していません）。
- どういうわけか、このファイルを要求していることをISPキャッシングサーバーに通知する必要があります。 HTTP経由でサーバーにリクエストを送信するだけでは、Cookieやその他の機密データが漏洩するためです。または、Cookieがこれらの機密性の低いファイルに送信されないように指定する必要があります。しかし、どのようにしてそれを確実に実行しますか？もちろん、別のドメインから提供することもできますが、既存のWebサイトを大幅に再設計する必要があります。そして、これらの機密性の低いファイルをある種の認証によって保護する必要がある場合はどうなりますか？
それとは別に、このアプローチの利点は低いようです。私が読んでいることから、CDNはすでにそれを処理しているので、ISPはもうほとんど何もキャッシュしません。
tl; dr：このアプローチはユーザーのプライバシーを侵害し、開発者だけでなくエンドユーザーの使いやすさの問題のためにセキュリティの問題を引き起こします。
はい、ある種のチェックサムを実装すればうまくいきます。ただし、TLSを使用する方がはるかに簡単です。
また、本当に正当な理由がない限り、通常は標準プロトコルを使用することをお勧めします。
最後に、httpsには他にもさまざまな利点があります。 CAシステムの境界内では、自分が思っているファイルを受け取っていることがわかります。また、ユーザーにプライバシーを提供し、オブザーバーが要求する特定のURLを確認できないようにします。
私が考えることができるいくつかのセキュリティ問題があります。
リプレイと置換
途中の人が署名済みのリソースを別の署名済みのリソース（以前に取得したもの）に置き換えるのを妨げるものは何もありません。たとえば、緑のGOボタンをSTOPボタンのある場所に表示して、崖から車を走らせることができます。または、私があなたの現金送金が失敗したように見せて、何度もそれを提出して、私は何度も支払われるようにすることもできます。
サイトの静的コンテンツの一部がJavaScriptファイルである場合は、同じサイトの別のJavaScriptファイルと交換できます。もし私が賢いなら、たぶん同じ関数名を持っているが違うことをするか、特定の検証を欠いているものを見つけることができます。
リダイレクション
画像のリクエストを傍受し、クエリ文字列パラメータがXSRF攻撃を構成するURLへの302リダイレクトで返信できます。
プライバシーの喪失
トラフィックを監視しているハッカーは、静的リソースに対するHTTPリクエストのパターンを調べることにより、どのページにアクセスしているかを特定できる可能性があります。
キャッシュポイズニングによるDoS
真ん中の男を働いているハッカーは、応答の1つを無効なファイルに置き換えます。プロキシはファイルをキャッシュします。キャッシュされたリソースを使用しようとするブラウザーは、検証に失敗し、エラーを表示します。問題を回避する簡単な方法はありません。
PSパフォーマンスの問題
また、パフォーマンスの問題もあります。チェックサムの計算にはBLOB全体が必要なため、チェックサムの対象となるリソースは段階的にレンダリングできません。したがって、画像が遅く表示され、すべてがパイプを通過するまで、ムービーは開始されません。
これは サブリソースの整合性 によって部分的に解決されます。 HTTPSを介してメインページを提供し、これにサブリソースメタデータ/ハッシュが含まれている場合、サブリソースはHTTPを介してフェッチされ、ISPプロキシによってキャッシュされるか、HTTPSを介してCDNによってキャッシュされ、リソースが改ざんされていないことを確信できます。ハッシュが一致する限り、仲介者によって。
ただし、ISPキャッシュを許可するモデルには機密性がないため、ブラウザーはこの方法で配信されたサブリソースを混合コンテンツと見なします。代わりに、現在プッシュされているモデルは、サイト所有者がCDNをセットアップしてエッジネットワークキャッシュを実行するため、エッジキャッシュはユーザーではなくサイト所有者によって支払われます。これはまた、ネットワーク中立性のダムパイプモデルとしてのISPの前兆です。
秘密鍵で署名されたチェックサムを最後に持つことができる場合、それは有効性を証明しませんか？ ...このセミHTTPが考慮されない特別な理由は何ですか？
おそらく、署名を取り除くことは簡単であり、署名されていないコンテンツにフォールバックするでしょう。一方、SRIモデルでは、サブリソースが保護されることが予想される時期を示すメインドキュメントが必要です。
ブラウザベンダーは「ミドルボックス」の使用経験がなく、干渉を防ぐための最良の方法としてエンドツーエンドの暗号化を採用していることを理解する必要があります。これが、たとえば、クリアテキストHTTP/2.0の実装を拒否する理由です。同じ理由で、あなたの考えに沿ったものはどれも採用される可能性はほとんどありません。
静的なWebサイトコンテンツ、特にHTMLに署名するための手法が存在します。例：
- http://www.sanface.com/pgphtml.html
- https://web.archive.org/web/20080725190448/http://members.aol.com/EJNBell/pgp-www.html
このようなイニシアチブはまだ普及していません。これには3つの理由があると思います。
- 彼らは実装するのが面倒です。
- より安全なWeb開発（HTTPSの広範な使用がその一面である）への文化的シフトは、それらが最初に提案されたとき、まだ初期の段階でした。
- 多くのWeb開発者はOpenPGPツールの使い方を知らず、安全に生成され、安全に保存されたOpenPGP署名鍵を持っていることは言うまでもありません。
それにもかかわらず、これらの手法は原則として、Webサイト上の静的リソースの整合性を検証するための優れたメカニズムを構成します。
ただし、静的Webリソースのこのような署名が一般的であったとしても、HTTPSを実装することには利点があります：機密性。署名だけではこれは提供されませんが、HTTPSによって提供される暗号化によって提供されます。 （少なくとも、HTTPSの該当する仕様に重大なバグがなく、適切に実装されている限り、HTTPSは機密性を提供します。）