RFC 6797 - HTTP Strict Transport Security (HTTP厳格トランスポートセキュリティ, HSTS)
インターネット技術タスクフォース (IETF)
Request for Comments: 6797
カテゴリ: 標準化過程
ISSN: 2070-1721
著者:
J. Hodges (PayPal)
C. Jackson (Carnegie Mellon University)
A. Barth (Google, Inc.)
発行日: 2012年11月
概要 (Abstract)
本仕様は、ウェブサイトがセキュアな接続を介してのみアクセス可能であることを宣言できるメカニズム、および/またはユーザーが自身のユーザーエージェント (User Agent) に対して特定のサイトとセキュアな接続のみで対話するよう指示できるメカニズムを定義します。この全体的なポリシーは、HTTP厳格トランスポートセキュリティ (HTTP Strict Transport Security, HSTS) と呼ばれます。このポリシーは、Strict-Transport-Security HTTP応答ヘッダーフィールドおよび/またはその他の手段 (例えば、ユーザーエージェントの設定) を介してウェブサイトによって宣言されます。
このメモのステータス (Status of This Memo)
これはインターネット標準化過程文書です。
この文書は、インターネット技術タスクフォース (IETF) の成果物です。これはIETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネット技術運営グループ (IESG) によって発行が承認されています。インターネット標準に関する詳細情報は、RFC 5741のセクション2で入手できます。
この文書の現在のステータス、正誤表、フィードバックの提供方法に関する情報は、以下で入手できます:
http://www.rfc-editor.org/info/rfc6797
著作権表示 (Copyright Notice)
Copyright (c) 2012 IETF Trustおよび文書の著者として識別された者。全著作権所有。
この文書は、BCP 78およびIETF文書に関するIETF Trustの法的規定 (http://trustee.ietf.org/license-info) の対象となり、これらは本文書の発行日に有効です。この文書に関するあなたの権利と制限を説明しているため、これらの文書を注意深く確認してください。
目次 (Table of Contents)
- 1. Introduction (イントロダクション)
- 1.1 Organization of This Specification
- 1.2 Document Conventions
- 2. Overview (概要)
- 2.1 Use Cases
- 2.2 HTTP Strict Transport Security Policy Effects
- 2.3 Threat Model
- 2.4 Requirements
- 3. Conformance Criteria (適合基準)
- 4. Terminology (用語)
- 5. HSTS Mechanism Overview (HSTSメカニズムの概要)
- 5.1 HSTS Host Declaration
- 5.2 HSTS Policy
- 5.3 HSTS Policy Storage and Maintenance by User Agents
- 5.4 User Agent HSTS Policy Enforcement
- 6. Syntax (構文)
- 6.1 Strict-Transport-Security HTTP Response Header Field
- 6.2 Examples
- 7. Server Processing Model (サーバー処理モデル)
- 7.1 HTTP-over-Secure-Transport Request Type
- 7.2 HTTP Request Type
- 8. User Agent Processing Model (ユーザーエージェント処理モデル)
- 8.1 Strict-Transport-Security Response Header Field Processing
- 8.2 Known HSTS Host Domain Name Matching
- 8.3 URI Loading and Port Mapping
- 8.4 Errors in Secure Transport Establishment
- 8.5 HTTP-Equiv <Meta> Element Attribute
- 8.6 Missing Strict-Transport-Security Response Header Field
- 9. Constructing an Effective Request URI (有効なリクエストURIの構築)
- 9.1 ERU Fundamental Definitions
- 9.2 Determining the Effective Request URI
- 10. Domain Name IDNA-Canonicalization (ドメイン名IDNA正規化)
- 11. Server Implementation and Deployment Advice (サーバー実装と展開のアドバイス)
- 11.1 Non-Conformant User Agent Considerations
- 11.2 HSTS Policy Expiration Time Considerations
- 11.3 Using HSTS in Conjunction with Self-Signed Public-Key Certificates
- 11.4 Implications of includeSubDomains
- 12. User Agent Implementation Advice (ユーザーエージェント実装のアドバイス)
- 12.1 No User Recourse
- 12.2 User-Declared HSTS Policy
- 12.3 HSTS Pre-Loaded List
- 12.4 Disallow Mixed Security Context Loads
- 12.5 HSTS Policy Deletion
- 13. Internationalized Domain Names for Applications (IDNA): Dependency and Migration (国際化ドメイン名: 依存性と移行)
- 14. Security Considerations (セキュリティに関する考慮事項)
- 14.1 Underlying Secure Transport Considerations
- 14.2 Non-Conformant User Agent Implications
- 14.3 Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport
- 14.4 The Need for includeSubDomains
- 14.5 Denial of Service
- 14.6 Bootstrap MITM Vulnerability
- 14.7 Network Time Attacks
- 14.8 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack
- 14.9 Creative Manipulation of HSTS Policy Store
- 14.10 Internationalized Domain Names
- 15. IANA Considerations (IANAに関する考慮事項)
- 16. References (参考文献)
- 16.1 Normative References
- 16.2 Informative References
付録 (Appendices)
- Appendix A. Design Decision Notes (設計決定ノート)
- Appendix B. Differences between HSTS Policy and Same-Origin Policy (HSTSポリシーと同一オリジンポリシーの違い)
- Appendix C. Acknowledgments (謝辞)
関連リソース
- 公式原文: RFC 6797
- 公式ページ: RFC 6797 DataTracker
- 正誤表: RFC Editor Errata
- HSTSプリロードリスト: hstspreload.org
クイックリファレンス
HSTSのコア価値
HSTSは、HTTPS接続を強制することで、以下の重要なWebセキュリティ問題に対処します:
- SSL Stripping攻撃: 攻撃者がHTTPSリンクをHTTPに置き換える
- 中間者攻撃 (Man-in-the-Middle Attack): 暗号化されていないトラフィックを傍受および変更する
- セッションハイジャッキング: HTTP経由で送信されるCookieを盗む
- 混合コンテンツの問題: HTTPSページがHTTPリソースを読み込む
基本的な使用法
サーバー設定例 (Nginx):
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
ブラウザの動作:
ユーザーがアクセス: http://example.com
ブラウザが自動的に変換: https://example.com
証明書エラー: 直接ブロック、続行不可
展開の推奨事項
- テスト段階:
max-age=300(5分) - 初期展開:
max-age=86400(1日) - 安定運用:
max-age=31536000(1年) - プリロードリストへの追加:
max-age=63072000; includeSubDomains; preload
注意事項
⚠️ 重要な警告:
- HSTSを設定すると、迅速に取り消すことが困難です
includeSubDomainsを使用する前に、すべてのサブドメインがHTTPSをサポートしていることを確認してください- HTTP応答でHSTSヘッダーを送信しないでください (削除されます)
- 開発環境で長期的なmax-age値を使用しないでください
このRFCは、現代のWebセキュリティの基盤の一つであり、すべての主要なブラウザでサポートされています。HSTSを適切に展開することで、ウェブサイトのセキュリティを大幅に向上させることができます。