CloudFlareが潜在的に安全でない無料のSSLをすべてのユーザーに提供するようになったので、新しいHTTPヘッダーが役立つでしょうか？
これをどこに投稿すればよいかわからないので、ここに投稿するだけだと思いました。
CloudFlareは現在 すべてのサイトに無料のSSL を提供しています。ただし、SSL接続には2つの異なるタイプがあります。クライアント<=> CloudFlare接続でHTTPSを実行する「Flexible SSL」がありますが、CloudFlare <=>サーバー接続では通常のHTTPです。これは確かに何もしないよりはましですが、自分のデータがネットワーク上にある限り完全に暗号化されていると考えるユーザーを誤解させるものです。
ユーザー<=> CloudFlare <=>サーバー接続全体に対して安全な「フルSSL」もあります。
したがって、X-Proxy-Securityのような名前の新しいHTTPヘッダーを提案します。これは、プロキシが安全な接続を処理する方法をユーザーエージェントに示すことができます。その値は、完全なエンドツーエンドの暗号化の場合はend-to-end、クライアントとプロキシの間でのみ保護される接続の場合はclient-to-proxyのようになります。 CloudFlareと同様のCDNやサービスなどのHTTPプロキシが多数あるため、ヘッダーには特定のCloudFlare参照が含まれていないことが理想的です。
それが実装された場合、ブラウザは最初はそれを処理する方法を知らないため、何も変更されません。ただし、ステータスをユーザーに中継するためのブラウザ拡張機能を開発することもできます。ブラウザは最終的に、混合コンテンツまたは現在のコンテンツを示す方法と同様の何らかの形のインジケーターを実装できます。
これはうまくいくでしょうか？それを実装するためにどのようにプッシュしますか？
これは、SSL証明書の発行元を確認する理由の一部です。それがあなたがアクセスしようとしているサイトでないなら、地獄を避けなさい。 cloudslがオンサイトで各サイトの証明書を生成するなどの安全でない方法でルート証明書を使用している場合、人々はそのルート証明書の承認を拒否することができます。問題が解決しました。
このための新しいhttpヘッダーは役に立たず、やり過ぎであり、誰かが適切に設定することを保証するものは何もないため、乱用される可能性があります。新しいヘッダーを必要とせずに、同じレベルの詳細を証明書自体に簡単に含めることができます。
ヘッダーは、この状況でわずかに役立つだけで、他のほとんどの状況ではまったく役に立ちません。ちょうどいくつかの例のために：
Cloudflareがhttps経由で実際のサイトをロードしたが、自己署名された未確認の証明書にあった場合、それでもエンドツーエンドのヘッダーは取得されますか？
自己署名証明書であるが、証明書のフィンガープリントがサイトに属するものとしてcloudflareによって手動で検証された場合、エンドツーエンドヘッダーが取得されますか？
cloudflareとは関係ありませんが、SSL終端ロードバランサーはどうですか？技術的には「クライアントからプロキシ」へのヘッダー設定である必要がありますが、率直に言って、ユーザーとして、サーバーが直接接続されているロードバランサーでSSLが終了することに気をつけたのはなぜですか。 SSL終端ロードバランサーが安全でないネットワークを介して残りの接続を転送していた場合、「安全なネットワーク」を定義する必要があるかもしれません。nginxがvpn経由でhttp経由で接続を転送している場合はどうなりますか？
ネットワークを構成する方法は多すぎますが、クライアントが気にする理由がたくさんあります。
Cloudflareがやっていることはここでは問題ないと思います。はい、安全な接続を介してサイトをプルする必要がありますが、他のSSLサイトと変わらない場合でも同様です。
たとえば、フォーラムまたはスタックオーバーフローを見た場合、SSL経由でロードすると、暗号化されたリンクを介して送信されますが、すべてのコンテンツを保持するデータベースへの暗号化されていない接続を介してコンテンツがプルされたことがわかります。そのうち、httpリクエストで送信された可能性があります。