https://en.wikipedia/wiki/HTTP_Strict_Transport_Security


HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

The HSTS Policy[2] is communicated by the server to the user agent via an HTTP response header field named "Strict-Transport-Security". HSTS Policy specifies a period of time during which the user agent should only access the server in a secure fashion.

Contents

   [hide] 
  • 1Specification history
  • 2HSTS mechanism overview
  • 3Applicability
  • 4Limitations
  • 5Privacy issues
  • 6Browser support
  • 7Deployment best practices
  • 8See also
  • 9References
  • 10External links

Specification history[edit]

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 Proposed Standard RFC.[3] 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.[4] 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.[5]

The original draft specification by Jeff Hodges[6] from PayPal, Collin Jackson[7] and Adam Barth[8] was published on 18 September 2009.[9]

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”.[10]

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).[11]

HSTS mechanism overview[edit]

A server implements an HSTS policy by supplying a header over an HTTPS connection (HSTS headers over HTTP are ignored).[12] 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: Strict-Transport-Security: max-age=31536000.

When a web application[13] issues HSTS Policy to user agents, conformant user agents behave as follows:[14]

  1. Automatically turn any insecure links referencing the web application into secure links. (For instance, http://example/some/page/ will be modified to https://example/some/page/ beforeaccessing the server.)
  2. If the security of the connection cannot be ensured (e.g. the server's TLS certificate is not trusted), show an error message and do not allow the user to access the web application.[15]

The HSTS Policy helps protect web application users against some passive (eavesdropping) and active network attacks.[16] A man-in-the-middle attacker 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[edit]

The most important security vulnerability that HSTS can fix is SSL-stripping man-in-the-middle attacks, first publicly introduced by Moxie Marlinspike in his 2009 BlackHat Federal talk "New Tricks For Defeating SSL In Practice".[17][18] The SSL stripping attack works (on TLS as well) 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. Many websites do not use TLS/SSL, therefore there is no way of knowing (without prior knowledge) whether the use of plain HTTP is due to an attack, or simply because the website hasn't 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.

HSTS addresses this problem[16] 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,Mozilla Firefox, Internet Explorer and Microsoft Edge attempt to limit this problem by including a "pre-loaded" list of HSTS sites.[19][20][21] Unfortunately this solution cannot scale to include all websites on the internet. See limitations, below.

HSTS can also help to prevent having one's cookie-based website login credentials stolen by widely available tools such as Firesheep.[22]

Because HSTS is time limited, it is sensitive to attacks involving shifting the victim's computer time e.g. using false NTP packets.[23]

Limitations[edit]

The initial request remains unprotected from active attacks if it uses an insecure protocol such as plain HTTP or if the URI for the initial request was obtained over an insecure channel.[24] The same applies to the first request after the activity period specified in the advertised HSTS Policy max-age (sites should set a period of several days or months depending on user activity and behavior). Google Chrome, Mozilla Firefoxand Internet Explorer/Microsoft Edge address this limitation by implementing a "STS preloaded list", which is a list that contains known sites supporting HSTS.[19][20][21] 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 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 issues).[25]

Even with a "STS preloaded list", HSTS can't prevent advanced attacks against TLS itself, such as the BEAST or CRIME attacks introduced by Juliano Rizzo and Thai Duong. Attacks against TLS itself are orthogonalto HSTS policy enforcement.

See RFC 6797 for a discussion of overall HSTS security considerations.[26]

Privacy issues[edit]

HSTS can be used to near-indelibly tag visiting browsers with recoverable identifying data (Supercookies) which can persist in and out of browser "incognito" modes, by creating a web page that makes multiple HTTP requests to selected domains; if (for example) 20 different requests/domains are used, one million visitors can be distinguished (binary, e.g., 2^20) on account of which resulting requests arrive via HTTP .vs. HTTPS, the latter being the previously recorded binary "bits" established earlier via HSTS headers.[27]

Browser support[edit]

  • Chromium and Google Chrome since version 4.0.211.0[28][29]
  • Firefox since version 4;[30] with Firefox 17, Mozilla integrates a list of websites supporting HSTS.[20]
  • Opera since version 12[31]
  • Safari as of OS X Mavericks[32]
  • Internet Explorer 11 on Windows 8.1 and Windows 7 when KB 3058515 is installed (Released on Windows Update in June 2015)[33]
  • Microsoft Edge and Internet Explorer 11 on Windows 10 support HSTS.[34][35]

Deployment best practices[edit]

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 https://sub.example should also answer with the HSTS header at https://example. The header should specify the includeSubDomains directive.
  • In addition to HSTS deployment, a host for https://www.example should include a request to a resource from https://example 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 http://nonexistentpeer.example), which the attacker then would answer.

See also[edit]

  • Internet portal
  • Content Security Policy
  • Extended Validation Certificate
  • HTTP Public Key Pinning
  • HTTPsec

References[edit]

  1. Jump up^ HTTPS refers to HTTP layered over Transport Layer Security(TLS/SSL). Such secured HTTP connections are denoted by the URIscheme name of "https", and this protocol stack is often colloquially referred to as the "HTTPS protocol".
  2. Jump up^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012)."Section 5.2. HSTS Policy". RFC 6797. IETF. Retrieved21 November 2012.
  3. Jump up^ "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)". 2 Oct 2012. Retrieved 2 Oct 2012.
  4. Jump up^ Jeff Hodges (30 June 2010). "Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)". Retrieved 22 July2010.
  5. Jump up^ "Strict Transport Security -06". 18 December 2009. Retrieved23 December 2009.
  6. Jump up^ "Jeff Hodges's homepage". Retrieved 26 Aug 2011.
  7. Jump up^ "Collin Jackson's homepage". Retrieved 8 Mar 2011.
  8. Jump up^ "Adam Barth's homepage". Retrieved 8 Mar 2011.
  9. Jump up^ "Strict Transport Security -05". 18 September 2009. Retrieved19 November 2009.
  10. Jump up^ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks". April 2008. Retrieved 19 November 2009.
  11. Jump up^ Hodges, Jeff; Steinguebl, Andy (29 October 2010). "The Need for Coherent Web Security Policy Framework(s)". Retrieved21 November 2012.
  12. Jump up^ "HTTP Strict Transport Security". Mozilla Developer Network. Retrieved 12 June 2015.
  13. Jump up^ Nations, Daniel. "Web Applications: What is a Web Application?". About. Retrieved 21 November 2012.
  14. Jump up^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012)."Section 5. HSTS Mechanism Overview". RFC 6797. IETF. Retrieved 21 November 2012.
  15. Jump up^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012)."Section 12.1. No User Recourse". RFC 6797. IETF. Retrieved30 June 2014.
  16. ^ Jump up to:a b Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012)."2.3. Threat Model". RFC 6797. IETF. Retrieved 21 November2012.
  17. Jump up^ "New Tricks For Defeating SSL In Practice" (PDF).
  18. Jump up^ Defeating SSL Using Sslstrip on YouTube
  19. ^ Jump up to:a b Adam Langley (8 July 2010). "Strict Transport Security". The Chromium Projects. Retrieved 22 July 2010.
  20. ^ Jump up to:a b c David Keeler (1 November 2012). "Preloading HSTS". Mozilla Security Blog. Retrieved 6 February 2014.
  21. ^ Jump up to:a b Bell, Mike; Walp, David (February 16, 2015). "HTTP Strict Transport Security comes to Internet Explorer". Retrieved16 February 2015.
  22. Jump up^ Jeff Hodges (31 October 2010). "Firesheep and HSTS (HTTP Strict Transport Security)". Retrieved 8 Mar 2011.
  23. Jump up^ Jose Selvi (2014-10-17). "Bypassing HTTP Strict Transport Security" (PDF). Retrieved 2014-10-22.
  24. Jump up^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012)."Section 14.6. Bootstrap MITM Vulnerability". RFC 6797. IETF. Retrieved 21 November 2012.
  25. Jump up^ Butcher, Simon (11 September 2011). "HTTP Strict Transport Security". Retrieved 27 March 2012.
  26. Jump up^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012)."Section 14. Security Considerations". RFC 6797. IETF. Retrieved21 November 2012.
  27. Jump up^ "The HSTS super cookie forcing you to choose: "privacy or security?" -". sophos. Retrieved 1 December 2015.
  28. Jump up^ The Chromium Developers (17 November 2010). "Strict Transport Security - The Chromium Projects". Retrieved 17 November 2010.
  29. Jump up^ Jeff Hodges (18 September 2009). "fyi: Strict Transport Security specification". Retrieved 19 November 2009.
  30. Jump up^ "HTTP Strict Transport Security". Mozilla. Retrieved 17 March2011.
  31. Jump up^ Opera Software ASA (23 April 2012). "Web specifications support in Opera Presto 2.10". Retrieved 8 May 2012.
  32. Jump up^ @agl__ (Adam Langley). "Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers.". on Twitter. Retrieved20 December 2013.
  33. Jump up^ "HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7". windows. Retrieved 12 June2015.
  34. Jump up^ "Internet Explorer Web Platform Status and Roadmap". Retrieved14 April 2014.
  35. Jump up^ "Project Spartan and the Windows 10 January Preview Build - IEBlog". Retrieved 23 January 2015.

External links[edit]

  • The State of HSTS Deployment: A Survey and Common Pitfalls provides an analysis of HSTS deployment statistics, patterns, mistakes, and best practices.
  • RFC 6797, HTTP Strict Transport Security (HSTS)
  • IETF WebSec Working Group
  • Security Now 262: Strict Transport Security
  • Open Web Application Security Project (OWASP): HSTS description
  • Online browser HSTS and Public Key Pinning test
  • HSTS Preload Submission for Google Chrome, Mozilla Firefox, Safari, IE 11, and Edge
[hide]
  • v
  • t
  • e
TLS and SSL
 
Protocols and technologies
  • Transport Layer Security / Secure Sockets Layer (TLS/SSL)
  • Datagram Transport Layer Security (DTLS)
  • DNS Certification Authority Authorization (CAA)
  • DNS-based Authentication of Named Entities (DANE)
  • HTTPS
  • HTTP Public Key Pinning (HPKP)
  • HTTP Strict Transport Security (HSTS)
  • OCSP stapling
  • Perfect forward secrecy
  • Server Name Indication (SNI)
  • STARTTLS
 
Public-key infrastructure
  • Automated Certificate Management Environment (ACME)
  • Certificate authority (CA)
  • CA/Browser Forum
  • Certificate policy
  • Certificate revocation list (CRL)
  • Domain-validated certificate (DV)
  • Extended Validation Certificate (EV)
  • Online Certificate Status Protocol (OCSP)
  • Public key certificate
  • Public-key cryptography
  • Public key infrastructure (PKI)
  • Root certificate
  • Self-signed certificate
 
See also
  • Domain Name System Security Extensions (DNSSEC)
  • Internet Protocol Security (IPsec)
  • Secure Shell (SSH)
 
History
  • Export of cryptography from the United States
  • Server-Gated Cryptography
 
Implementations
  • Bouncy Castle
  • BoringSSL
  • Botan
  • cryptlib
  • GnuTLS
  • JSSE
  • LibreSSL
  • MatrixSSL
  • NSS
  • OpenSSL
  • mbed TLS
  • RSA BSAFE
  • SChannel
  • SSLeay
  • stunnel
  • wolfSSL
 
Notaries
  • Certificate Transparency
  • Convergence
  • HTTPS Everywhere / SSL Observatory
  • Perspectives Project
 
Vulnerabilities
Theory
  • Man-in-the-middle attack
  • Padding oracle attack
  • Lucky Thirteen attack
 
Cipher
  • Bar mitzvah attack
 
Protocol
  • BEAST
  • BREACH
  • CRIME
  • DROWN
  • Logjam
  • POODLE (in regards to SSL 3.0)
 
Implementation
  • Certificate authority compromise
  • Random number generator attacks
  • FREAK
  • goto fail
  • Heartbleed
  • POODLE (in regards to TLS 1.0)
Categories: 
  • Computer security
  • Computer security standards
  • Cryptography
  • Hypertext Transfer Protocol
  • Hypertext Transfer Protocol headers
  • Transport Layer Security
  • Web security exploits

更多推荐

HSTS - HTTP Strict Transport Security