Content

 

Overview

HSTS (HTTP Strict Transport Security) is a policy mechanism that helps protect websites from man-in-the-middle attacks, such as protocol downgrade or cookie hijacking. Allows websites to require web browsers (and other web client applications) to automatically only HTTPS they use relationships that are SSL / TLS with the help of which strong encryption is implemented. HSTS is a 2012 IETF standard that it is RFC 6797 determines.

The server communicates the HSTS policy to the client program via an HTTP response header field called "Strict-Transport-Security". HSTS also defines a time period during which client programs can only connect to the server in a secure manner. Websites using HSTS often do not accept HTTP connections in plain text, either rejecting them or systematically redirecting users to HTTPS (although this is not required by the specification). The downside to this is that clients that don't support HTTPS cannot connect to the site. Of course, as time progresses, the number of these devices decreases.

The protection is only valid if the user has already visited the site at least once based on the principle of trust during the first use. This protection works so that if a user loads a URL that is specified with plain HTTP but HSTS is configured on the server, the client will automatically upgrade to HTTPS without making a single HTTP request. would also send it. This prevents an HTTP-in-the-middle attack from occurring. Assuming the visitor has visited that site once and their browser has already noted the existence of HSTS and its duration for that site. These websites can be managed in your browser settings. For Chrome, for example, the chrome://net-internals/#hsts these stored web addresses can be managed by loading an internal url address.

HSTS also provides additional protection regarding website certificate validity. For example, if a browser visits a website that already uses HSTS and whose certificate is not valid, the browser will terminate the connection and not allow the user to visit the website.

 

 

Header definitions

The HSTS header can be defined in the web server settings in the following ways:

Alap

The simplest header setup for HSTS:

Strict-Transport-Security: max-age=31536000

The web server setting indicates to the clients to connect to the given website via HTTPS connection by default for 31536000 seconds from the visit, i.e. - in this case - for one year, if it is visited again within this period.

Subdomain

This setup does the same thing as the first one, but it also includes the subdomains available on your site:

Strict-Transport-Security: max-age=31536000; includesubdomains

So, for example, if a website has several language subdomains, they are also automatically included in this definition.

Preload

Specifying the preload option:

Strict-Transport-Security: max-age=31536000; includesubdomains; preload

There is also HSTS preload which means website and/or domain it will be added to an approved HSTS list that is actually built into the browser. This list is officially compiled by Google and used by Chrome, Firefox, Opera, Safari, IE11, and Edge. This list can be viewed using the website search function here:

• hstspreload.org

Of course, only sites that meet all HSTS requirements will be included in the list. Examples include:

• The HSTS option above must be present in the HTTP headers and include the "includesubdomains" and "preload" options
• Must be a valid certificate chain issued to the domain name
• All website traffic must be redirected to HTTPS, i.e.:
• The website must not contain insecure (plain HTTP) redirects to itself
• All subdomains must communicate over an HTTPS connection
• The max-age value must be at least 31536000, i.e. at least 1 year.

If a website is added to this preload list, it can also have some positive effects from an SEO point of view.

 

Limits

The very first request remains vulnerable to active attacks if the connection is made over a plain HTTP connection or if the initial request URL is obtained over an insecure channel. The same applies to the first request after the activity period specified in the published HSTS Policy max-age (websites must set a period of at least 1 year).

HSTS is ineffective against DNS-based attacks because it allows a Man-in-the-Middle packet interceptor to serve traffic from an artificial domain that is not on the HSTS Preload list, which DNS spoofing attacks can do possible. Or simply a domain name that looks misleadingly similar to the real domain name, such as www.example.org instead of www.example.com, could be a threat.