HTTPアプリケーション上のHSTSとの関連性は何ですか？
HSTSをHTTPSアプリケーションに実装する必要があることは誰もが知っています。最近、HTTPアプリケーションに実装されたHSTSアプリケーションに遭遇しました。
クライアントに答える必要があります。私によれば、HTTPに実装されたHSTSには利点がありません。私にお知らせください。
RFC 6796、8.1 で行われた決定は、HSTSヘッダーがある場合に何が起こるかを想像すれば、はるかに理解しやすくなります。 HTTP応答からは、HTTPSと同じ方法で処理されました。
サイトはHTTPのみであり、誤ってHSTSヘッダーを追加します。これでブラウザはHTTPSにアップグレードするように指示されますが、サイトはHTTPSバージョンをまったく提供しておらず、到達できなくなります。
Man-in-the-middle（MitM）がこのヘッダーを追加して、意図的にサイトに到達できないようにします。
仲介者もHTTPS接続で同じことを行うことができるため、ユーザーがセキュリティ例外を作成して警告をバイパスする場合、 RFC 6796、8.1 には2つの条件があります。
HSTSヘッダーは（プレーンHTTPではなく）安全なトランスポートを介して受信する必要があります。
基になる安全なトランスポートエラーまたは警告があってはなりません。施行後、HSTSは 8.4 で説明されているのと同じ条件を必要とするため、ヘッダーの読み取り中にエラーまたは警告が許可されると、偶発的であれ、MitMによるものであっても、サイトにアクセスできなくなります。
したがって、HSTSの合理的な使用法は次のとおりです
- 最初にHTTPをHTTPSにリダイレクトし、次にHTTPS経由でcanonical名にリダイレクトします。
- HSTSヘッダーを、正規のホスト名だけでなく、すべてのHTTPSホスト名に追加します。このようにして、すべてのホスト名を保護します。それ以外の場合は、保護されていないバージョンをMitMに引き続き使用できます。
- リダイレクトするすべてのホスト名が正規ホスト名のサブドメインであり、プレーンHTTP経由でサブドメインが必要ない場合は、
includeSubDomainsディレクティブを追加して、それらすべてを一度に保護します。 - HSTS preloading を検討してください。これには2つのフェーズがあります。リストにヘッダー＆ submitting を追加します。
あなたが言ったように、HTTPを介してHSTSを提供しても効果はありません。ヘッダーはブラウザによって無視されます。これは RFC6796 に記述されています
HSTSはHTTPS接続にのみ影響します。