HTTP Strict Transport Security

from Wikipedia, the free encyclopedia

HTTP Strict Transport Security (HSTS) is a security mechanism for HTTPS connections that is designed to protect against the breakdown of connection encryption by a downgrade attack and session hijacking . For this purpose, a server can use the HTTP response header Strict Transport Security to inform the user's browser to use only encrypted connections for this domain for a defined period of time ( max-age ) . Optionally, this can be extended to all subdomains using the includeSubDomains parameter , not just to but also to . https://example.orghttps://subdomain.example.org

By one of Google Chrome supervised and the other major web browsers used HSTS list preload the limitations are of the " trust on first use " principle for a defined list of domains bypassed. The registration of additional domains is possible free of charge.

history

The standard was published by the IETF in 2012 as RFC 6797 and is supported by the latest versions of popular web browsers , among others . The reason for the development was Moxie Marlinspike's 2009 demonstration of attacks on encrypted connections by means of man-in-the-middle attacks that intervene before an encrypted connection was established.

functionality

To use HSTS, both the server and the browser of the user must behave according to the specifications.

server

With HTTPS connections, the server sends an additional header with the information that the requested page will only be available via an encrypted connection in the future. This header must then be interpreted accordingly by the user's browser. The header is Strict-Transport-Security. It also specifies how long the site will be accessible in encrypted form in the future. This time span is given in seconds. So the header

Strict-Transport-Security: max-age=31536000

the user's browser to only establish encrypted connections to this page for the duration of a common year .

Browser

If a browser receives an HSTS header, it must behave as follows for all future connections to this domain until the specified validity expires:

  • All unencrypted links to this page are automatically converted to encrypted: http://example.org/bild.jpgbecomes to https://example.org/bild.jpg.
  • If the security of the connection cannot be guaranteed, e.g. For example, if the server's certificate cannot be trusted, an error message is displayed and the connection is terminated. The user then no longer has the option of calling up the page with the browser.

If an HSTS header is transmitted over an unencrypted connection or if the connection's certificate is not valid, the browser must ignore it.

criticism

The storage of the HSTS information by the client can be a tracking advantage of users. In this context, it was discussed particularly critically that Google Chrome also takes over the HSTS information in the incognito mode, which is designed for special data protection. Web servers should still activate HSTS because, regardless of the data protection risk on the browser side, communication through HSTS becomes more secure, as data is not transmitted unencrypted. A mandatory SSL / TLS connection can also help to detect a man-in-the-middle attack more easily - even if it cannot rule it out.

Web links

Individual evidence

  1. ↑ Preloading HSTS . Mozilla Security Blog, November 1, 2012.
  2. ↑ HSTS preload submission .
  3. ↑ a b Reiko Kaps: HTTP Strict Transport Security as the Internet standard - heise Netze. In: Heise Online. November 21, 2012, accessed October 25, 2015 .
  4. ↑ See overview in the Browser compatibility section of the HTTP Strict Transport Security entry in the Mozilla Developer Forum.
  5. ^ Jeff Hodges: Section 5. HSTS Mechanism Overview . In: RFC 6797 . IETF. November 2012. Retrieved November 21, 2012.
  6. ↑ Ronald Eikenberg: Security function HSTS as supercookie - heise Security. In: Heise . January 6, 2015, accessed October 25, 2015 .