1. 導入 (Introduction)
HTTP [RFC2616]は、通常は伝送制御プロトコル(TCP)を使用して、さまざまなトランスポート上で動作できます。ただし、TCPはチャネル整合性保護、機密性、または安全なホスト識別を提供しません。したがって、Secure Sockets Layer(SSL)プロトコル[RFC6101]とその後継であるTransport Layer Security(TLS) [RFC5246]が、チャネル指向のセキュリティを提供するために開発され、通常はアプリケーションプロトコルとTCPの間に層化されます。[RFC2818]は、HTTPがTLSの上にどのように層化されるかを指定し、"https" Uniform Resource Identifier(URI)スキームを定義します(実質的に、HTTP UAは通常、サーバーとネゴシエートされるものとユーザー設定の組み合わせに応じて、TLSまたはSSL3を使用します)。
UAは、Webリソースと対話する際にさまざまなローカルセキュリティポリシーを使用します。その特性は、HTTPまたはHTTP-over-Secure-Transportのいずれかを使用して、特定のWebリソースのホストと通信しているかどうかに部分的に依存します。たとえば、Cookie([RFC6265])はSecureとしてフラグを立てることができます。UAは、このようなSecure Cookieを、安全なトランスポート経由でのみアドレス指定されたホストに送信する必要があります。これは、トランスポートに関係なく(ただし他のルールの対象)ホストに返される非Secure Cookieとは対照的です。
UAは通常、TLSサーバー証明書信頼チェーンを検証できない、TLSサーバー証明書の有効期限が切れている、またはTLSホストのドメイン名がTLSサーバー証明書に正しく表示されていないなど、接続を安全に確立する際の問題をユーザーに通知します([RFC2818]のセクション3.1を参照)。多くの場合、UAはこのような問題に直面しても、Webリソースのホストと対話を続けることをユーザーが選択できるようにします。この動作は非公式に「セキュリティをクリックスルーする」[GoodDhamijaEtAl05] [SunshineEgelmanEtAl09]と呼ばれており、したがって「クリックスルー不安全性」と説明できます。
クリックスルー不安全性によって可能になる主な脆弱性は、Webリソースがユーザーのセッションを管理するために使用している可能性のあるCookieの漏洩です。ここでの脅威は、攻撃者がCookieを取得し、ユーザーになりすましながら正規のWebリソースと対話できることです。
JacksonとBarthは、[ForceHTTPS]で、Webリソースが、UAとWebリソースとのすべての対話が安全に実行されなければならないこと、および安全なトランスポートセッションを確立する際の問題は致命的として扱われ、直接的なユーザーの手段がないことを宣言できるようにするアプローチを提案しました。目的は、クリックスルー不安全性を防ぎ、他の潜在的な脅威に対処することです。
この仕様は、[ForceHTTPS]で提案されたアプローチを具体化し、洗練しています。たとえば、WebリソースのホストからUAにポリシーを伝えるためにCookieを使用するのではなく、この目的のためのHTTP応答ヘッダーフィールドを定義します。さらに、Webリソースのホストは、そのポリシーがホスト名をルートとするドメイン名サブツリー全体に適用されることを宣言できます。これにより、HTTP Strict Transport Security(HSTS)は、特定のWebリソースのホスト名のすべてのサブドメインに適用される、いわゆる「ドメインCookie」を保護できます。
この仕様には、ホストがUAにHSTSポリシーを明示するStrict-Transport-Security HTTP応答ヘッダーフィールド構文([JacksonBarth2008]で定義)も組み込まれています。
さらに、この仕様には、[JacksonBarth2008]で定義されている、ポリシーが「ホスト全体」ベースで適用されるという概念が組み込まれています。つまり、発行ホストの任意のTCPポート上のHTTP(HTTPのみ)に適用されます。
この仕様で定義されているポリシーは、"The Web Origin Concept" [RFC6454]で定義されている「同一オリジンポリシー」とは明確に異なることに注意してください。これらの違いは、付録Bに要約されています。
1.1 本仕様の構成 (Organization of This Specification)
この仕様は、HSTSのユースケース、ポリシー効果、脅威モデル、および要件の概要から始まります(セクション2)。次に、セクション3で適合性基準を定義します。セクション4では、このドキュメントに関連する用語を定義します。HSTSメカニズム自体は、セクション5から15で正式に指定されています。
1.2 ドキュメント規則 (Document Conventions)
注記: これは読者への注意事項です。これらは心に留めておくべき、および/または考慮すべき点です。