View source for HTTP Strict Transport Security

{{short description|Website protection mechanism}}
{{Use dmy dates|date=January 2018}}
'''HTTP Strict Transport Security''' ('''HSTS''') is a policy mechanism that helps to protect websites against [[man-in-the-middle attack]]s such as [[protocol downgrade attack]]s<ref name="mdn-security">{{Cite web |title=Strict-Transport-Security |url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security |url-status=live |archive-url=https://web.archive.org/web/20200320021752/https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security |archive-date=20 March 2020 |access-date=31 January 2018 |website=[[MDN Web Docs]] |publisher=[[Mozilla]] |language=en-US}}</ref> and [[session hijacking|cookie hijacking]]. It allows [[web server]]s to declare that web browsers (or other complying [[user agent]]s) should automatically interact with it using only [[HTTPS]] connections, which provide [[Transport Layer Security]] (TLS/SSL), unlike the insecure [[HTTP]] used alone. HSTS is an [[Internet Engineering Task Force|IETF]] [[Internet Standard|standards]] track protocol and is specified in {{IETF RFC|6797}}.

The HSTS Policy is communicated by the server to the user agent via an HTTP response [[List of HTTP header fields|header]] field named <code><nowiki>Strict-Transport-Security</nowiki></code>. HSTS Policy specifies a period of time during which the [[user agent]] should only access the server in a secure fashion.{{Ref RFC|6797|rsection=5.2}} Websites using HSTS often do not accept clear text HTTP, either by rejecting connections over HTTP or systematically redirecting users to HTTPS (though this is not required by the specification). The consequence of this is that a user-agent not capable of doing TLS will not be able to connect to the site.

The protection only applies after a user has visited the site at least once, relying on the principle of "[[trust on first use]]". The way this protection works is that when a user entering or selecting an HTTP (not HTTPS) URL to the site, the client, such as a Web browser, will  automatically upgrade to HTTPS without making an HTTP request, thereby preventing any HTTP man-in-the-middle attack from occurring.

== Specification history ==
The HSTS specification was published as RFC 6797 on 19 November 2012 after being approved on 2 October 2012 by the [[IESG]] for publication as a [[Internet Standard|Proposed Standard]] [[Request for Comments|RFC]].<ref name="hsts-ps-rfc-approval-iesg-msg">{{cite web
| url = https://www.ietf.org/mail-archive/web/websec/current/msg01401.html
| title = [websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)
| date = 2 Oct 2012
| access-date = 2 Oct 2012
| archive-date = 29 January 2017
| archive-url = https://web.archive.org/web/20170129010418/https://www.ietf.org/mail-archive/web/websec/current/msg01401.html
| url-status = live
}}</ref> The authors originally submitted it as an [[Internet Draft]] on 17 June 2010. With the conversion to an Internet Draft, the specification name was altered from "Strict Transport Security" (STS) to "HTTP Strict Transport Security", because the specification applies only to [[HTTP]].<ref>{{cite web
| url = http://www.ietf.org/mail-archive/web/hasmat/current/msg00025.html
| first = Jeff
| last = Hodges
| title = Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)
| date = 30 June 2010
| access-date = 22 July 2010
| archive-date = 2 February 2017
| archive-url = https://web.archive.org/web/20170202023740/https://www.ietf.org/mail-archive/web/hasmat/current/msg00025.html
| url-status = live
}}</ref> The HTTP response header field defined in the HSTS specification however remains named "Strict-Transport-Security".

The last so-called "community version" of the then-named "STS" specification was published on 18 December 2009, with revisions based on community feedback.<ref name="STS-draft-spec-2">{{cite web
| url = http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html
| title = Strict Transport Security -06
| date = 18 December 2009
| access-date = 23 December 2009
| archive-date = 21 February 2017
| archive-url = https://web.archive.org/web/20170221200316/http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html
| url-status = live
}}</ref>

The original draft specification by Jeff Hodges from [[PayPal]], Collin Jackson, and Adam Barth was published on 18 September 2009.<ref name="draft-spec">{{cite web
| url = http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html
| title = Strict Transport Security -05
| date = 18 September 2009
| access-date = 19 November 2009
| archive-date = 24 February 2020
| archive-url = https://web.archive.org/web/20200224205710/https://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html
| url-status = live
}}</ref>

The HSTS specification is based on original work by Jackson and Barth as described in their paper "ForceHTTPS: Protecting High-Security Web Sites from Network Attacks".<ref name="forcehttps-paper">{{cite web
| url = https://crypto.stanford.edu/forcehttps/
| title = ForceHTTPS: Protecting High-Security Web Site from Network Attacks
| date = April 2008
| access-date = 19 November 2009
| archive-date = 28 February 2020
| archive-url = https://web.archive.org/web/20200228030854/https://crypto.stanford.edu/forcehttps/
| url-status = live
}}</ref>

Additionally, HSTS is the realization of one facet of an overall vision for improving web security, put forward by Jeff Hodges and Andy Steingruebl in their 2010 paper ''The Need for Coherent Web Security Policy Framework(s)''.<ref name="web-sec-policy-frmwk">{{cite web
| url = http://www.thesecuritypractice.com/the_security_practice/2010/10/the-need-for-coherent-web-security-policy-frameworks.html
| title = The Need for Coherent Web Security Policy Framework(s)
| last = Hodges
| first = Jeff
| author2 = Steinguebl, Andy
| date = 29 October 2010
| access-date = 21 November 2012
| archive-date = 14 August 2017
| archive-url = https://web.archive.org/web/20170814175208/http://www.thesecuritypractice.com/the_security_practice/2010/10/the-need-for-coherent-web-security-policy-frameworks.html
| url-status = live
}}</ref>

== HSTS mechanism overview ==
A server implements an HSTS policy by supplying a header over an HTTPS connection (HSTS headers over HTTP are ignored).<ref name="mdn-security"/> For example, a server could send a header such that future requests to the domain for the next year (max-age is specified in seconds; 31,536,000 is equal to one non-leap year) use only HTTPS: <code>Strict-Transport-Security: max-age=31536000</code>.

When a web application issues HSTS Policy to user agents, conformant user agents behave as follows:{{Ref RFC|6797|rsection=5}}

# Automatically turn any insecure links referencing the web application into secure links (e.g. <code><nowiki>http://example.com/some/page/</nowiki></code> will be modified to <code><nowiki>https://example.com/some/page/</nowiki></code> {{Em|before}} accessing the server).
# If the security of the connection cannot be ensured (e.g. the server's [[Transport Layer Security|TLS]] [[Public key certificate|certificate]] is not trusted), the user agent must terminate the connection{{Ref RFC|6797|rsection=8.4}} and should not allow the user to access the web application.{{Ref RFC|6797|rsection=12.1}}

The HSTS Policy helps protect web application users against some passive ([[eavesdropping]]) and active network [[Attack (computing)|attacks]].{{Ref RFC|6797|rsection=2.4}} A [[man-in-the-middle attack]]er has a greatly reduced ability to intercept requests and responses between a user and a web application server while the user's browser has HSTS Policy in effect for that web application.

== Applicability ==
The most important security vulnerability that HSTS can fix is SSL-stripping [[man-in-the-middle attack]]s, first publicly introduced by [[Moxie Marlinspike]] in his 2009 BlackHat Federal talk "New Tricks For Defeating SSL In Practice".<ref>{{cite conference |url=https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf |title=New Tricks For Defeating SSL In Practice |last=Marlinspike |first=Moxie|conference=[[Black Hat Briefings]] |location=Washington, DC |year=2009 |access-date=15 March 2012 |archive-date=30 December 2014 |archive-url=https://web.archive.org/web/20141230024722/http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf |url-status=live }}</ref><ref>{{YouTube|MFol6IMbZ7Y|Defeating SSL Using Sslstrip}}</ref> The SSL (and [[Transport Layer Security|TLS]]) stripping attack works by transparently converting a secure [[HTTPS]] connection into a plain HTTP connection. The user can see that the connection is insecure, but crucially there is no way of knowing whether the connection ''should'' be secure. At the time of Marlinspike's talk, many websites did not use TLS/SSL, therefore there was no way of knowing (without prior knowledge) whether the use of plain HTTP was due to an attack, or simply because the website had not implemented TLS/SSL. Additionally, no warnings are presented to the user during the downgrade process, making the attack fairly subtle to all but the most vigilant. Marlinspike's sslstrip tool fully automates the attack.{{citation needed|date=July 2020}}

HSTS addresses this problem{{Ref RFC|6797|rsection=2.4}} by informing the browser that connections to the site should always use TLS/SSL. The HSTS header can be stripped by the attacker if this is the user's first visit. [[Google Chrome]], [[Firefox|Mozilla Firefox]], [[Internet Explorer]], and [[Microsoft Edge]] attempt to limit this problem by including a "pre-loaded" list of HSTS sites.<ref name=preloading_hsts_chromium>{{cite web
| url = https://www.chromium.org/sts
| first = Adam
| last = Langley
| title = Strict Transport Security
| work = The Chromium Projects
| date = 8 July 2010
| access-date = 22 July 2010
| archive-date = 1 September 2019
| archive-url = https://web.archive.org/web/20190901122419/http://www.chromium.org/sts
| url-status = live
}}</ref><ref name=preloading_hsts_mozillla>{{cite web
| url = https://blog.mozilla.org/security/2012/11/01/preloading-hsts/
| first = David
| last = Keeler
| title = Preloading HSTS
| date = 1 November 2012
| access-date = 6 February 2014
| work = Mozilla Security Blog
| archive-date = 24 February 2020
| archive-url = https://web.archive.org/web/20200224205730/https://blog.mozilla.org/security/2012/11/01/preloading-hsts/
| url-status = live
}}</ref><ref name="iepreload" /> Unfortunately this solution cannot scale to include all websites on the internet. See [[HTTP Strict Transport Security#Limitations|limitations]], below.

HSTS can also help to prevent having one's cookie-based website login credentials stolen by widely available tools such as [[Firesheep]].<ref>{{cite web
| url = http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/
| first = Jeff
| last = Hodges
| title = Firesheep and HSTS (HTTP Strict Transport Security)
| date = 31 October 2010
| access-date = 8 Mar 2011
| archive-date = 23 June 2016
| archive-url = https://web.archive.org/web/20160623191633/http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/
| url-status = live
}}</ref>

Because HSTS is time limited, it is sensitive to attacks involving shifting the victim's computer time e.g. using false [[Network Time Protocol|NTP]] packets.<ref>{{cite conference |conference=[[Black Hat Briefings]] |location=Amsterdam |last=Selvi |first=Jose| url=https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf | title=Bypassing HTTP Strict Transport Security | date=2014-10-17 | access-date=2014-10-22  | archive-date=22 October 2014 | archive-url=https://web.archive.org/web/20141022112001/https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf | url-status=live }}</ref>

== Limitations ==
The initial request remains unprotected from active attacks if it uses an insecure protocol such as plain HTTP or if the [[Uniform Resource Identifier|URI]] for the initial request was obtained over an [[insecure channel]].{{Ref RFC|6797|rsection=14.6}} The same applies to the first request after the activity period specified in the advertised HSTS Policy <code><nowiki>max-age</nowiki></code> (sites should set a period of several days or months depending on user activity and behavior).

=== Solutions with preload list ===
[[Google Chrome]], [[Firefox|Mozilla Firefox]], and [[Internet Explorer]]/[[Microsoft Edge]] address this limitation by implementing a "HSTS preloaded list", which is a list that contains known sites supporting HSTS.<ref>{{Cite web|url=https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json|title=Chromium HSTS Preloaded list|website=cs.chromium.org|access-date=2019-07-10|archive-date=18 February 2020|archive-url=https://web.archive.org/web/20200218174855/https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json|url-status=live}}</ref><ref name=preloading_hsts_chromium /><ref name=preloading_hsts_mozillla /><ref name="iepreload">{{cite web |url=http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx |title=HTTP Strict Transport Security comes to Internet Explorer |access-date=16 February 2015 |author1=Bell, Mike |author2=Walp, David |date=16 February 2015 |archive-date=15 November 2015 |archive-url=https://web.archive.org/web/20151115035120/http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx |url-status=live }}</ref> This list is distributed with the browser so that it uses HTTPS for the initial request to the listed sites as well. As previously mentioned, these pre-loaded lists cannot scale to cover the entire Web. A potential solution might be achieved by using [[Domain name system|DNS]] records to declare HSTS Policy, and accessing them securely via [[DNSSEC]], optionally with certificate fingerprints to ensure validity (which requires running a validating resolver to avoid [[Last mile (telecommunications)|last mile]] issues).<ref>{{cite web | title=HTTP Strict Transport Security | url=https://simon.butcher.name/archives/2011/09/11/HTTP-Strict-Transport-Security | author=Butcher, Simon | date=11 September 2011 | access-date=27 March 2012 | archive-date=26 April 2019 | archive-url=https://web.archive.org/web/20190426183544/https://simon.butcher.name/archives/2011/09/11/HTTP-Strict-Transport-Security | url-status=live }}</ref>

Junade Ali has noted that HSTS is ineffective against the use of false domains; by using DNS-based attacks, it is possible for a man-in-the-middle interceptor to serve traffic from an artificial domain which is not on the HSTS Preload list,<ref name="auto">{{cite web|last1=Ali|first1=Junade|title=Performing & Preventing SSL Stripping: A Plain-English Primer|url=https://blog.cloudflare.com/performing-preventing-ssl-stripping-a-plain-english-primer/|website=Cloudflare Blog|date=20 October 2017|access-date=7 December 2017|archive-date=14 December 2019|archive-url=https://web.archive.org/web/20191214182725/https://blog.cloudflare.com/performing-preventing-ssl-stripping-a-plain-english-primer/|url-status=live}}</ref> this can be made possible by DNS Spoofing Attacks,<ref>{{cite conference|last1=Maksutov|first1=A. A. | title=Detection and prevention of DNS spoofing attacks|conference=2017 Siberian Symposium on Data Science and Engineering (SSDSE)|last2=Cherepanov|first2=I. A.|last3=Alekseev|first3=M. S.|pages=84–87|doi=10.1109/SSDSE.2017.8071970|date=2017|isbn=978-1-5386-1593-5|s2cid=44866769}}</ref> or simply a domain name that misleadingly resembles the real domain name such as ''www.example.org'' instead of ''www.example.com''.

Even with an HSTS preloaded list, HSTS cannot prevent advanced attacks against TLS itself, such as the [[BEAST (computer security)|BEAST]] or [[CRIME (security exploit)|CRIME]] attacks introduced by Juliano Rizzo and Thai Duong. Attacks against TLS itself are [[Orthogonal#Computer science|orthogonal]] to HSTS policy enforcement. Neither can it protect against attacks on the server - if someone compromises it, it will happily serve any content over TLS.

=== Privacy issues ===
HSTS can be used to near-indelibly tag visiting browsers with recoverable identifying data ([[HTTP cookie#Supercookie|supercookies]]) which can persist in and out of browser "[[Privacy mode|incognito]]" privacy modes. By creating a web page that makes multiple HTTP requests to selected domains, for example, if twenty browser requests to twenty different domains are used, theoretically over one million visitors can be distinguished (2<sup>20</sup>) due to the resulting requests arriving via HTTP vs. HTTPS; the latter being the previously recorded binary "bits" established earlier via HSTS headers.<ref>{{cite web|url=https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/|title=The HSTS super cookie forcing you to choose: "privacy or security?" -|work=sophos.com|date=2 February 2015|access-date=1 December 2015|archive-date=11 February 2020|archive-url=https://web.archive.org/web/20200211175612/https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/|url-status=live}}</ref>

== Browser support ==
[[File:Chromium HSTS settings screenshot.png|alt=Settings page Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org".|border|right|428x428px|Settings page for HTTPS Strict Transport Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org".]]

* [[Chromium (web browser)|Chromium]] and [[Google Chrome]] since version 4.0.211.0<ref name="chromium_sts">{{cite web
| url = https://dev.chromium.org/sts
| author = The Chromium Developers
| title = Strict Transport Security - The Chromium Projects
| date = 17 November 2010
| access-date = 17 November 2010
| archive-date = 20 March 2020
| archive-url = https://web.archive.org/web/20200320021003/http://dev.chromium.org/sts
| url-status = live
}}</ref><ref>{{cite web
| url = http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html
| first = Jeff
| last = Hodges
| title = fyi: Strict Transport Security specification
| date = 18 September 2009
| access-date = 19 November 2009
| archive-date = 29 February 2020
| archive-url = https://web.archive.org/web/20200229020216/https://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html
| url-status = live
}}</ref>
* [[Firefox]] since version 4;<ref name="mdn-security" /> with Firefox 17, [[Mozilla]] integrates a list of websites supporting HSTS.<ref name=preloading_hsts_mozillla />
* [[Opera (web browser)|Opera]] since version 12<ref name="opera_presto">{{cite web
 |url          = http://www.opera.com/docs/specs/presto2.10/#m210-244
 |author       = Opera Software ASA
 |title        = Web specifications support in Opera Presto 2.10
 |date         = 23 April 2012
 |access-date  = 8 May 2012
 |archive-date = 20 June 2018
 |archive-url  = https://web.archive.org/web/20180620002005/https://www.opera.com/docs/specs/presto2.10/#m210-244
 |url-status   = live
}}</ref>
* [[Safari (web browser)|Safari]] since [[OS X Mavericks]] (version 10.9, late 2013)<ref>{{cite tweet
 |number = 414112266938617856
 |first       = Adam
 |last       = Langley
 |user = agl__
 |title        = Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers.
 |access-date  = 20 December 2013
 |archive-date = 9 May 2019
 |url = https://twitter.com/agl__/status/414112266938617856
 |archive-url = https://web.archive.org/web/20190509013208/https://twitter.com/agl__/status/414112266938617856
 |url-status   = dead
}}</ref>
* [[Internet Explorer 11]] on [[Windows 8.1]] and [[Windows 7]] with [https://support.microsoft.com/kb/3058515 KB3058515] installed (Released as a Windows Update in June 2015)<ref>{{cite web|url=http://blogs.windows.com/msedgedev/2015/06/09/http-strict-transport-security-comes-to-internet-explorer-11-on-windows-8-1-and-windows-7/|title=HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7|work=windows.com|access-date=12 June 2015|archive-date=27 November 2019|archive-url=https://web.archive.org/web/20191127121246/https://blogs.windows.com/msedgedev/2015/06/09/http-strict-transport-security-comes-to-internet-explorer-11-on-windows-8-1-and-windows-7/|url-status=live}}</ref>
* [[Microsoft Edge]] and [[Internet Explorer 11]] on [[Windows 10]]<ref>{{cite web
| url=https://status.modern.ie/httpstricttransportsecurityhsts
| title=Internet Explorer Web Platform Status and Roadmap
| access-date=14 April 2014
| archive-date=29 June 2015
| archive-url=https://web.archive.org/web/20150629110718/https://status.modern.ie/httpstricttransportsecurityhsts
| url-status=live
}}</ref><ref>{{cite web
| url=https://blogs.msdn.microsoft.com/ie/2015/01/22/project-spartan-and-the-windows-10-january-preview-build/
| title=Project Spartan and the Windows 10 January Preview Build - IEBlog
| date=22 January 2015
| access-date=23 January 2015
| archive-date=29 November 2019
| archive-url=https://web.archive.org/web/20191129035641/https://blogs.msdn.microsoft.com/ie/2015/01/22/project-spartan-and-the-windows-10-january-preview-build/
| url-status=live
}}</ref>
* [[BlackBerry 10]] Browser and [https://developer.blackberry.com/native/reference/cascades/bb__cascades__webview.html WebView] since BlackBerry OS 10.3.3.

== Deployment best practices ==
Depending on the actual deployment there are certain threats (e.g. cookie injection attacks) that can be avoided by following best practices.

* HSTS hosts should declare HSTS policy at their top-level domain name. For example, an HSTS host at <nowiki>https://sub.example.com</nowiki> should also answer with the HSTS header at <nowiki>https://example.com</nowiki>. The header should specify the <code>includeSubDomains</code> directive.{{Ref RFC|6797|rsection=6.1.2}}
* In addition to HSTS deployment, a host for <nowiki>https://www.example.com</nowiki> should include a request to a resource from <nowiki>https://example.com</nowiki> to make sure that HSTS for the parent domain is set and protects the user from potential cookie injection attacks performed by a MITM that would inject a reference to the parent domain (or even <nowiki>http://nonexistentpeer.example.com</nowiki>), which the attacker then would answer.{{Ref RFC|6797|rsection=11.4}}

== See also ==
{{Portal|Internet}}
* {{IETF RFC|6797}} - a discussion of overall HSTS security considerations
* [[Content Security Policy]]
* [[.app (top-level domain)|.app TLD]] – a Google-operated TLD included in the HSTS preload-list by default
* [[.dev|.dev TLD]] – a Google-operated TLD included in the HSTS preload-list by default
* [[HTTP Public Key Pinning]]

== References ==
{{reflist}}

== External links ==
* [https://tools.ietf.org/wg/websec/charters IETF WebSec Working Group]
* [https://www.twit.tv/shows/security-now/episodes/262 Security Now 262: Strict Transport Security]
* [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet Open Web Application Security Project (OWASP): HSTS description]
* [https://projects.dm.id.lv/Public-Key-Pins_test Online browser HSTS and Public Key Pinning test]
* [https://hstspreload.org/ HSTS Preload Submission] for Google Chrome, Mozilla Firefox, Safari, IE 11, and Edge
*[https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json Chromium HSTS Preloaded list]
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security Strict-Transport-Security] on [[MDN Web Docs]]

{{SSL/TLS}}

[[Category:Computer security standards]]
[[Category:Cryptography]]
[[Category:Hypertext Transfer Protocol headers|Strict Transport Security]]
[[Category:Transport Layer Security]]