HTTP Strict Transport Security

Last updated

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks [1] and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) 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 IETF standards track protocol and is specified in RFC   6797.

Contents

The HSTS Policy 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. [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 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 from PayPal, Collin Jackson, and Adam Barth was published on 18 September 2009. [6]

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". [7]

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

HSTS mechanism overview

A server implements an HSTS policy by supplying a header over an HTTPS connection (HSTS headers over HTTP are ignored). [1] 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 issues HSTS Policy to user agents, conformant user agents behave as follows (RFC 6797): [9]

  1. Automatically turn any insecure links referencing the web application into secure links (e.g. 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 not trusted), the user agent must terminate the connection (RFC 6797 section 8.4, Errors in Secure Transport Establishment) and should not allow the user to access the web application (section 12.1, No User Recourse).

The HSTS Policy helps protect web application users against some passive (eavesdropping) and active network attacks. [10] 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

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". [11] [12] The SSL (and 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 ]

HSTS addresses this problem [10] 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. [13] [14] [15] 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. [16]

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

Limitations

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. [18] 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 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. [19] [13] [14] [15] 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). [20]

Junade Ali has noted that HSTS is ineffective against the use of phony 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, [21] this can be made possible by DNS Spoofing Attacks, [22] 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 or CRIME attacks introduced by Juliano Rizzo and Thai Duong. Attacks against TLS itself are 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.

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

Privacy issues

HSTS can be used to near-indelibly tag visiting browsers with recoverable identifying data (supercookies) which can persist in and out of browser "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 (220) due to the resulting requests arriving via HTTP vs. HTTPS; the latter being the previously recorded binary "bits" established earlier via HSTS headers. [23]

Browser support

Settings page for HTTPS Strict Transport Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org". Chromium HSTS settings screenshot.png
Settings page for HTTPS Strict Transport Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org".

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.

See also

Related Research Articles

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of ID and password joined by a single colon :.

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP), the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP it avoids the TCP meltdown problem when being used to create a VPN tunnel.

<span class="mw-page-title-main">HTTP cookie</span> Small pieces of data stored by a web browser while on a website

HTTP cookies are small blocks of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session.

<span class="mw-page-title-main">HTTP referer</span> HTTP header field

In HTTP, "Referer" is an optional HTTP header field that identifies the address of the web page from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

SPDY is an obsolete open-specification communication protocol developed for transporting web content. SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY. After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

POODLE is a security vulnerability which takes advantage of the fallback to SSL 3.0. If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages. Bodo Möller, Thai Duong and Krzysztof Kotowicz from the Google Security Team discovered this vulnerability; they disclosed the vulnerability publicly on October 14, 2014. On December 8, 2014, a variation of the POODLE vulnerability that affected TLS was announced.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

<span class="mw-page-title-main">HTTP Public Key Pinning</span> Obsolete Internet security mechanism

HTTP Public Key Pinning (HPKP) is an obsolete Internet security mechanism delivered via an HTTP header which allows HTTPS websites to resist impersonation by attackers using misissued or otherwise fraudulent digital certificates. A server uses it to deliver to the client a set of hashes of public keys that must appear in the certificate chain of future connections to the same domain name.

A downgrade attack, also called a bidding-down attack, or version rollback attack, is a form of cryptographic attack on a computer system or communications protocol that makes it abandon a high-quality mode of operation in favor of an older, lower-quality mode of operation that is typically provided for backward compatibility with older systems. An example of such a flaw was found in OpenSSL that allowed the attacker to negotiate the use of a lower version of TLS between the client and server. This is one of the most common types of downgrade attacks. Opportunistic encryption protocols such as STARTTLS are generally vulnerable to downgrade attacks, as they, by design, fall back to unencrypted communication. Websites which rely on redirects from unencrypted HTTP to encrypted HTTPS can also be vulnerable to downgrade attacks, as the initial redirect is not protected by encryption.

Token Binding is a proposed standard for a Transport Layer Security (TLS) extension that aims to increase TLS security by using cryptographic certificates on both ends of the TLS connection. Current practice often depends on bearer tokens, which may be lost or stolen. Bearer tokens are also vulnerable to man-in-the-middle attacks or replay attacks. In contrast, bound tokens are established by a user agent that generates a private-public key pair per target server, providing the public key to the server, and thereafter proving possession of the corresponding private key on every TLS connection to the server.

Version history for TLS/SSL support in web browsers tracks the implementation of Transport Layer Security protocol versions in major web browsers.

References

  1. 1 2 3 "Strict-Transport-Security". MDN Web Docs . Mozilla. Archived from the original on 20 March 2020. Retrieved 31 January 2018.
  2. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). "HSTS Policy". HTTP Strict Transport Security (HSTS). IETF. sec. 5.2. doi: 10.17487/RFC6797 . RFC 6797.
  3. ↑ "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)". 2 October 2012. Archived from the original on 29 January 2017. Retrieved 2 October 2012.
  4. ↑ Hodges, Jeff (30 June 2010). "Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)". Archived from the original on 2 February 2017. Retrieved 22 July 2010.
  5. ↑ "Strict Transport Security -06". 18 December 2009. Archived from the original on 21 February 2017. Retrieved 23 December 2009.
  6. ↑ "Strict Transport Security -05". 18 September 2009. Archived from the original on 24 February 2020. Retrieved 19 November 2009.
  7. ↑ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks". April 2008. Archived from the original on 28 February 2020. Retrieved 19 November 2009.
  8. ↑ Hodges, Jeff; Steinguebl, Andy (29 October 2010). "The Need for Coherent Web Security Policy Framework(s)". Archived from the original on 14 August 2017. Retrieved 21 November 2012.
  9. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 5. HSTS Mechanism Overview. IETF. sec. 5. doi: 10.17487/RFC6797 . RFC 6797.
  10. 1 2 Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). 2.4. Threat Model. IETF. sec. 2.3. doi: 10.17487/RFC6797 . RFC 6797.
  11. ↑ Marlinspike, Moxie (2009). New Tricks For Defeating SSL In Practice (PDF). Black Hat Briefings. Washington, DC. Archived (PDF) from the original on 30 December 2014. Retrieved 15 March 2012.
  12. ↑ Defeating SSL Using Sslstrip on YouTube
  13. 1 2 Langley, Adam (8 July 2010). "Strict Transport Security". The Chromium Projects. Archived from the original on 1 September 2019. Retrieved 22 July 2010.
  14. 1 2 3 Keeler, David (1 November 2012). "Preloading HSTS". Mozilla Security Blog. Archived from the original on 24 February 2020. Retrieved 6 February 2014.
  15. 1 2 Bell, Mike; Walp, David (16 February 2015). "HTTP Strict Transport Security comes to Internet Explorer". Archived from the original on 15 November 2015. Retrieved 16 February 2015.
  16. ↑ Hodges, Jeff (31 October 2010). "Firesheep and HSTS (HTTP Strict Transport Security)". Archived from the original on 23 June 2016. Retrieved 8 March 2011.
  17. ↑ Selvi, Jose (17 October 2014). Bypassing HTTP Strict Transport Security (PDF). Black Hat Briefings. Amsterdam. Archived (PDF) from the original on 22 October 2014. Retrieved 22 October 2014.
  18. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 14.6. Bootstrap MITM Vulnerability. IETF. sec. 14.6. doi: 10.17487/RFC6797 . RFC 6797.
  19. ↑ "Chromium HSTS Preloaded list". cs.chromium.org. Archived from the original on 18 February 2020. Retrieved 10 July 2019.
  20. ↑ Butcher, Simon (11 September 2011). "HTTP Strict Transport Security". Archived from the original on 26 April 2019. Retrieved 27 March 2012.
  21. ↑ Ali, Junade (20 October 2017). "Performing & Preventing SSL Stripping: A Plain-English Primer". Cloudflare Blog. Archived from the original on 14 December 2019. Retrieved 7 December 2017.
  22. ↑ Maksutov, A. A.; Cherepanov, I. A.; Alekseev, M. S. (2017). Detection and prevention of DNS spoofing attacks. 2017 Siberian Symposium on Data Science and Engineering (SSDSE). pp. 84–87. doi:10.1109/SSDSE.2017.8071970. ISBN   978-1-5386-1593-5. S2CID   44866769.
  23. ↑ "The HSTS super cookie forcing you to choose: "privacy or security?" -". sophos.com. 2 February 2015. Archived from the original on 11 February 2020. Retrieved 1 December 2015.
  24. ↑ The Chromium Developers (17 November 2010). "Strict Transport Security - The Chromium Projects". Archived from the original on 20 March 2020. Retrieved 17 November 2010.
  25. ↑ Hodges, Jeff (18 September 2009). "fyi: Strict Transport Security specification". Archived from the original on 29 February 2020. Retrieved 19 November 2009.
  26. ↑ Opera Software ASA (23 April 2012). "Web specifications support in Opera Presto 2.10". Archived from the original on 20 June 2018. Retrieved 8 May 2012.
  27. ↑ Langley, Adam [@agl__] (20 December 2013). "Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers" (Tweet). Archived from the original on 9 May 2019. Retrieved 20 December 2013– via Twitter.
  28. ↑ "HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7". windows.com. Archived from the original on 27 November 2019. Retrieved 12 June 2015.
  29. ↑ "Internet Explorer Web Platform Status and Roadmap". Archived from the original on 29 June 2015. Retrieved 14 April 2014.
  30. ↑ "Project Spartan and the Windows 10 January Preview Build - IEBlog". 22 January 2015. Archived from the original on 29 November 2019. Retrieved 23 January 2015.
  31. ↑ Hodges; et al. "HTTP Strict Transport Security (HSTS) 6.1.2". ietf.org. Archived from the original on 22 July 2019. Retrieved 11 November 2016.
  32. ↑ Hodges, J.; Jackson, C.; Barth, A. (2012). "RFC 6797 - HTTP Strict Transport Security (HSTS) 11.4 Implications of includeSubDomains". IETF Tools. sec. 11.4. doi: 10.17487/RFC6797 . RFC 6797.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.