HTTP Strict Transport Security

From Wikipedia, the free encyclopedia
  (Redirected from Strict Transport Security)
Jump to: navigation, search

HTTP Strict Transport Security (HSTS) is a web security policy mechanism whereby a web server declares that complying user agents (such as a web browser) are to interact with it using only secure HTTPS connections (i.e. HTTP layered over TLS/SSL[1]). 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 a HTTP response header field named "Strict-Transport-Security". HSTS Policy specifies a period of time during which the user agent shall access the server in only secure fashion.

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. It was with the conversion to an Internet-Draft that the specification name was altered from "Strict Transport Security" (STS) to "HTTP Strict Transport Security". The reason for this name change was given as being due to the specification being specific to HTTP.[4] (Note: the HTTP response header field defined in the HSTS specification 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 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.com/some/page/ will be modified to https://example.com/some/page/ before accessing the server.)
  2. If the security of the connection cannot be ensured (e.g. the server's TLS certificate is self-signed), 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.[15] 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".[16] The SSL stripping attack works (on both SSL and TLS) 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[15] 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 and Mozilla Firefox attempt to limit this problem by including a "pre-loaded" list of HSTS sites.[17][18] Unfortunately this solution cannot scale to include all websites on the internet; 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 (although DNSSEC will have secure last mile issues for the foreseeable future[19]).[20] HSTS can also help to prevent having one's cookie-based website login credentials stolen by widely available tools such as Firesheep.[21]

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.[22] 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 and Mozilla Firefox address this limitation by implementing a "STS preloaded list", which is a list that contains known sites supporting HSTS.[17][18] This list is distributed with the browser so that it uses HTTPS for the initial request to the listed sites as well.

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 orthogonal to HSTS policy enforcement.

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

Browser support[edit]

Implementation[edit]

Strict-Transport-Security headers should be sent via HTTPS responses only.[31] Client implementations must not respect STS headers sent over non-HTTPS responses, or over HTTPS responses which are not using properly configured, trusted certificates. The following server configuration snippets should be within the context of an SSL site configuration block, and the code examples are intended to be within the context of HTTPS responses only.

Note that the max-age is provided in seconds. The 31536000 seconds (12 months) in the examples below can be changed, depending on how long the web server operator is willing to commit to using HTTPS only. It is recommended to set the max-age to a big value like 31536000 (12 months) or 63072000 (24 months).

Implementation in Apache.

# load module (example using [RHEL])
LoadModule headers_module modules/mod_headers.so
 
<VirtualHost 10.0.0.1:443>
      # Use HTTP Strict Transport Security to force client to use secure connections only
      Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

Implementation in lighttpd.

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header  = ("Strict-Transport-Security" => "max-age=31536000; includeSubDomains")
}

Implementation in nginx.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

In addition to the code below,[32] an open source module is available for implementation in Internet Information Services.

protected void Application_BeginRequest(Object sender, EventArgs e)
{
  switch (Request.Url.Scheme)
  {
    case "https":
      Response.AddHeader("Strict-Transport-Security", "max-age=31536000");
      break;
    case "http":
      var path = "https://" + Request.Url.Host + Request.Url.PathAndQuery;
      Response.Status = "301 Moved Permanently";
      Response.AddHeader("Location", path);
      break;
  }
}

Implementation as an iRule for F5_Networks#BIG-IP.

### iRule "hsts_insert" for HTTPS Virtuals
when HTTP_RESPONSE {
   HTTP::header insert Strict-Transport-Security "max-age=31536000 ; includeSubDomains"
}

See also[edit]

References[edit]

  1. ^ Such secure HTTP connections are denoted by the URI scheme name of "https", and this protocol stack is often colloquially referred to as the "HTTPS protocol". also known as HTTP Secure.
  2. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (Nov 2012). "Section 5.2. HSTS Policy". RFC 6797. IETF. Retrieved 21 Nov 2012. 
  3. ^ "[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. ^ Jeff Hodges (30 June 2010). "Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)". Retrieved 22 July 2010. 
  5. ^ "Strict Transport Security -06". 18 December 2009. Retrieved 23 December 2009. 
  6. ^ "Jeff Hodges's homepage". on-going. Retrieved 26 Aug 2011. 
  7. ^ "Collin Jackson's homepage". on-going. Retrieved 8 Mar 2011. 
  8. ^ "Adam Barth's homepage". on-going. Retrieved 8 Mar 2011. 
  9. ^ "Strict Transport Security -05". 18 September 2009. Retrieved 19 November 2009. 
  10. ^ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks". April 2008. Retrieved 19 November 2009. 
  11. ^ Hodges, Jeff; Steinguebl, Andy (29 October 2010). "The Need for Coherent Web Security Policy Framework(s)". Retrieved 21 Nov 2012. 
  12. ^ https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
  13. ^ Nations, Daniel. "Web Applications: What is a Web Application?". About.com. Retrieved 21 Nov 2012. 
  14. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (Nov 2012). "Section 5. HSTS Mechanism Overview". RFC 6797. IETF. Retrieved 21 Nov 2012. 
  15. ^ a b c Hodges, Jeff; Jackson, Collin; Barth, Adam (Nov 2012). "Section 12.1. No User Recourse". RFC 6797. IETF. Retrieved 30 Jun 2014. 
  16. ^ https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
  17. ^ a b Adam Langley (8 July 2010). "Strict Transport Security". The Chromium Projects. Retrieved 22 July 2010. 
  18. ^ a b c David Keeler (1 November 2012). "Preloading HSTS". Mozilla Security Blog. Retrieved 6 February 2014. 
  19. ^ Cricket Liu (11 February 2010). "Securing DNSSEC's "Last Mile"". Retrieved 18 Apr 2014. 
  20. ^ Butcher, Simon (11 September 2011). "HTTP Strict Transport Security". Retrieved 27 March 2012. 
  21. ^ Jeff Hodges (31 October 2010). "Firesheep and HSTS (HTTP Strict Transport Security)". Retrieved 8 Mar 2011. 
  22. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (Nov 2012). "Section 14.6. Bootstrap MITM Vulnerability". RFC 6797. IETF. Retrieved 21 Nov 2012. 
  23. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (Nov 2012). "Section 14. Security Considerations". RFC 6797. IETF. Retrieved 21 Nov 2012. 
  24. ^ The Chromium Developers (17 November 2010). "Strict Transport Security - The Chromium Projects". Retrieved 17 November 2010. 
  25. ^ Jeff Hodges (18 September 2009). "fyi: Strict Transport Security specification". Retrieved 19 November 2009. 
  26. ^ "HTTP Strict Transport Security". Mozilla. Retrieved 17 March 2011. 
  27. ^ Opera Software ASA (23 April 2012). "Web specifications support in Opera Presto 2.10". Retrieved 8 May 2012. 
  28. ^ @agl__ (Adam Langley). "Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers.". on Twitter. Retrieved 20 December 2013. 
  29. ^ "Low adoption rate of HSTS website security mechanism is worrying, EFF says". April 8, 2014. Retrieved 14 April 2014. 
  30. ^ "Internet Explorer Web Platform Status and Roadmap". Retrieved 14 April 2014. 
  31. ^ "HTTP Strict Transport Security (HSTS), 7.2. HTTP Request Type". 29 September 2012. Retrieved 12 November 2012. 
  32. ^ "OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection". 16 April 2013. Retrieved 16 April 2013. 

External links[edit]