メインコンテンツまでスキップ

11. Server Implementation and Deployment Advice (サーバー実装と展開のアドバイス)

本セクションは非規範的である。

11.1. Non-Conformant User Agent Considerations (非準拠ユーザーエージェントの考慮事項)​

非準拠のUAはStrict-Transport-Securityヘッダーフィールドを無視する; したがって、非準拠のユーザーエージェントはセクション2.3.1 ("Threats Addressed") で説明されている脅威を解決しない。詳細については、セクション14.2 ("Non-Conformant User Agent Implications") を参照。

11.2. HSTS Policy Expiration Time Considerations (HSTSポリシー有効期限の考慮事項)​

サーバー実装およびWebサイトの展開では、有効期限を将来の一定値に設定するか、固定時点に設定するかを検討する必要がある。

"将来の一定値"アプローチは、同じmax-age値を継続的にUAに送信することで実現できる。

たとえば、max-age値7776000秒は90日である:

Strict-Transport-Security: max-age=7776000

UAがこのヘッダーフィールドを受信するたびに、この既知のHSTSホストに関する知識を削除しなければならない時刻の概念をUAが更新する必要があることに注意。

"固定時点"アプローチは、目的の有効期限までの残り時間を表すmax-age値を送信することで実現できる。これには、HSTSホストが各HTTPレスポンスで新しく計算されたmax-age値を送信する必要がある。

ここでの考慮事項の1つは、展開者がシグナルされたHSTSポリシーの有効期限をWebサイトのドメイン証明書の有効期限と一致させたいかどうかである。

さらに、サーバー実装者は、展開構成システムでデフォルトのmax-age値をゼロとして使用することを検討すべきである。これにより、展開者は意図的にmax-ageを設定してUAがホストに対してHSTSポリシーを実行する必要があり、任意の非ゼロ期間でHSTSを意図せずに有効にすることから保護される。

11.3. Using HSTS in Conjunction with Self-Signed Public-Key Certificates (自己署名公開鍵証明書と組み合わせたHSTSの使用)​

以下の4つの条件がすべて真である場合...

  • Webサイト/組織/企業がWebサイト用の独自のセキュアトランスポート公開鍵証明書を生成しており、かつ

  • その組織のルート認証局 (CA) 証明書が通常、ブラウザおよび/またはオペレーティングシステムのCA証明書ストアにデフォルトで埋め込まれておらず、かつ

  • 組織のCAによって署名された証明書 (つまり、"自己署名証明書") で自身を識別するホストでHSTSポリシーが有効になっており、かつ

  • この証明書が利用可能なTLS証明書関連付けと一致しない場合 (TLSAプロトコル仕様 [RFC6698] セクション4で定義されているように)、

...その場合、HSTS設計により、そのサイトへのセキュアな接続は失敗する。これは、上記のようなさまざまなアクティブ攻撃を防ぐためである。

ただし、組織が独自のCAと自己署名証明書をHSTSと組み合わせて使用したい場合は、ルートCA証明書をユーザーのブラウザまたはオペレーティングシステムのCAルート証明書ストアに展開することで実現できる。また、追加的または代替的に、特定のホストのエンドエンティティ証明書をユーザーのブラウザに配布することもできる。これを達成する方法はいくつかある (詳細は本仕様の範囲外)。ルートCA証明書がブラウザにインストールされると、サイトでHSTSポリシーを使用できる。

または、組織はTLSAプロトコルを展開することができる; TLSAも使用するすべてのブラウザは、TLSAを介して表現される利用可能なTLS証明書関連付けによって識別される証明書を信頼できる。

注 (NOTE): たとえば電子メールを介してユーザーにルートCA証明書を対話的に配布し、ユーザーにインストールさせることは、ユーザーを可能なフィッシング攻撃の形態に対して脆弱になるように訓練していると言える。セクション14.8 ("Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack") を参照。したがって、ユーザーのシステムとブラウザでそのような証明書を配布およびインストールする方法には注意が必要である。

11.4. Implications of includeSubDomains (includeSubDomainsの影響)​

includeSubDomainsディレクティブには、慎重に検討する価値のある実際的な影響がある; 2つの例のシナリオは:

  • HSTSホストが、HSTSホストドメイン名の代替ポートまたはさまざまなサブドメインで非セキュアなHTTPベースのサービスを提供している。

  • HSTSホストの異なるサブドメインで異なるWebアプリケーションが提供されており、UAは通常、HSTSホストのドメイン名で提供されるWebアプリケーション (ある場合) と必ずしも相互作用せずに、これらのサブドメインWebアプリケーションと直接相互作用する。

以下のサブセクションでは、これらの各シナリオについて順番に説明する。

11.4.1. Considerations for Offering Unsecured HTTP Services at Alternate Ports or Subdomains of an HSTS Host (HSTSホストの代替ポートまたはサブドメインで非セキュアHTTPサービスを提供する際の考慮事項)​

たとえば、認証局は通常、CRL配布およびOCSPサービス [RFC2560] をプレーンHTTPを介して提供し、時にはTLS/SSLで保護される可能性のある公開Webアプリケーションのサブドメインで提供する。

HSTSホストがincludeSubDomainsディレクティブを含むHSTSポリシーを発行する場合、そのホストのサブドメインで提供されるHTTPベースのサービスもTLS/SSL経由で統一的に提供されるようにするか、別のドメイン名でプレーンHTTPベースのサービスを提供する必要がある。

11.4.2. Considerations for Offering Web Applications at Subdomains of an HSTS Host (HSTSホストのサブドメインでWebアプリケーションを提供する際の考慮事項)​

この場合、HSTSホストはincludeSubDomainsディレクティブを含むHSTSポリシーを宣言し、HSTSホストの異なるサブドメインにも異なるWebアプリケーションが存在し、UAは通常、HSTSホストと必ずしも相互作用せずに、これらのサブドメインWebアプリケーションと直接相互作用する。この場合、UAはHSTSポリシーを受信または実行しない。

この問題を解決するには、HSTSホストを構成して、includeSubDomainsディレクティブを採用するかどうかに関係なく、Webアプリケーションを構成する既知の"エントリポイント"である各HSTSホストドメインまたはサブドメイン名でSTSヘッダーフィールドが直接発行されるようにする必要がある。

に最終更新