HSTS mechanism activating the forced secure connection via the HTTPS protocol

HSTS (abbr. From the English. HTTP Strict Transport Security ) - a mechanism that activates the forced secure connection via the HTTPS protocol. This security policy allows you to immediately establish a secure connection, instead of using the HTTP protocol. The mechanism uses a special Strict-Transport-Security header to force the browser to use the HTTPS protocol even if you follow links with an explicit indication of the HTTP protocol (http: //). The mechanism is specified in RFC6797 in November 2012.

HSTS helps to prevent some of the attacks aimed at intercepting the connection between the user and the website, in particular attacks with a decrease in the degree of protection and theft of cookies.

Additional protection for https connections is provided by the Certificate pinning methods (storing the list of allowed certificates for a domain or CA in browser source texts) and HTTP Public Key Pinning (Eng.) Russian. They prevent many https-server tls-certificates spoofing options.

Specification

The specification was developed and proposed by Jeff Oge (= JeffH, Paypal), Adam Barth (University of Berkeley), Colin Jackson (Carnegie University - Mellon). After discussion in the IETF WebSec working group, the specification was adopted as RFC on November 19, 2012.

Mechanism

The server reports HSTS policies using a special header when connecting via encrypted HTTPS (the HSTS header is ignored when connecting via unencrypted HTTP). ^[1] For example, Wikipedia servers send an HSTS header with a validity of 1 year, extending to all subdomains (The max-age field indicates the validity period in seconds, the value 31536000 approximately corresponds to one year): Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Strict-Transport-Security: max-age=31536000; includeSubDomains; preload .

When the site applies the HSTS policy, user browsers correctly perceiving the HSTS header should: ^[2]

1. Automatically autonomously convert all http links to this site to https links. (For example, instead of http://ru.wikipedia.org/wiki/HSTS the browser will use https://ru.wikipedia.org/wiki/HSTS , the conversion will occur before the actual access to the server.)
2. If the https connection security cannot be verified (in particular, if the server’s TLS certificate is not signed by a trusted key), an error message will be displayed and the user will be denied access to the site. ^[3]

Existing HSTS policies help protect site users from some passive and active attacks. ^[4] MiTM class attacks are significantly more complex.

HSTS static list

The original HSTS does not protect the first user connection to the site. An attacker can easily intercept the first connection if it is using the http protocol. To combat this problem, most modern browsers use an additional static list of sites ( HSTS preload list ) that require the use of the https protocol. Such a list is compiled by the authors of Google Chrome / Chromium since 2010 ^{[5] [6]} , based on it, such lists are compiled for Microsoft browsers (Edge and Internet Explorer, since 2015) ^[7] , Safari ^[8] and in Mozilla Firefox ( since 2012) ^[9] . Such a list includes, on request, sites that use the HSTS header with the maximum term and the preload flag, and do not plan to refuse https ^[9] , but the technology does not scale well ^[8] .

As of the end of 2014, more than a thousand domains were in the static list, of which about a quarter were Google domains ^[10] .

Using

HSTS and HPKP Debugging Page (English) Russian. in the Chromium browser for the site en.wikipedia.org (before listing on HSTS preload , dynamic HSTS; HPKP is not applied).

• On the client side
  • Chromium 4 and all browsers based on it ^[11] .
  • Firefox 4 ^[12]
  • NoScript ^[13]
• On the site side (all listed in the HSTS preload list ): ^[14]
  • Google
  • Paypal
  • Wikipedia
  • Twitter

see also

• HTTPS Everywhere ^[ru]