RFC 6797 - HTTP Strict Transport Security (HSTS)
Internet Engineering Task Force (IETF)
Request for Comments: 6797
Category: Standards Track
ISSN: 2070-1721
Authors:
J. Hodges (PayPal)
C. Jackson (Carnegie Mellon University)
A. Barth (Google, Inc.)
Publication Date: November 2012
Abstract
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at:
````http://www.rfc-editor.org/info/rfc6797\````
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (````http://trustee.ietf.org/license-info\````) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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
- 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
- 9.1 ERU Fundamental Definitions
- 9.2 Determining the Effective Request URI
- 10. Domain Name IDNA-Canonicalization
- 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
- 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
- Appendix C. Acknowledgments
Related Resources
- Official Text: RFC 6797
- Official Page: RFC 6797 DataTracker
- Errata: RFC Editor Errata
- HSTS Preload List: hstspreload.org
Quick Reference
Core Value of HSTS
HSTS addresses the following critical web security issues by forcing HTTPS connections:
- SSL Stripping Attacks: Attackers replace HTTPS links with HTTP
- Man-in-the-Middle Attacks: Intercepting and modifying unencrypted traffic
- Session Hijacking: Stealing cookies transmitted over HTTP
- Mixed Content Issues: HTTPS pages loading HTTP resources
Basic Usage
Server Configuration Example (Nginx):
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Browser Behavior:
User visits: http://example.com
Browser automatically converts to: https://example.com
Certificate error: Direct block, no bypass allowed
Deployment Recommendations
- Testing Phase:
max-age=300(5 minutes) - Initial Deployment:
max-age=86400(1 day) - Stable Operation:
max-age=31536000(1 year) - Preload List Entry:
max-age=63072000; includeSubDomains; preload
Important Considerations
⚠️ Important Warnings:
- HSTS is difficult to quickly revoke once set
- Ensure all subdomains support HTTPS before using
includeSubDomains - Do not send HSTS headers in HTTP responses (they will be stripped)
- Avoid using long-term max-age values in development environments
This RFC is one of the cornerstones of modern web security and is supported by all major browsers. Properly deploying HSTS can significantly enhance website security.