Skip to content

SSL beyond the basics part 4: Strict transport security


In our previous post, we discussed SSL certificates and new cryptographic functionality that can be used with modern SSL certificates. Next, we are going to look at how to make sure SSL is always used for web clients in a browser.

SSL doesn’t do much for securing browsers if it isn’t used, which is why most web applications, including Secret Server, automatically redirect browsers to the SSL-secured version of the application.

Secret Server currently handles redirects like this:

Secret Server Redirect

The server checks to see if SSL is enabled, and if it’s not, instructs the browser to go to the SSL-enabled site. However, this poses one potential risk. Suppose there is a man-in-the-middle attack, where an attacker intercepts the server’s response and instead of redirecting to the SSL-enabled site, sends them somewhere else that looks like Secret Server.

Man-in-the-middle attack

Since there is still a small window in which an attacker can intercept a non-SSL request, they can redirect the browser to a URL that might look very similar to Secret Server’s URL but displays a fake login form to steal credentials.

To mitigate this, modern browsers support Strict Transport Security or HSTS. HSTS is where the server can inform the browser that the site should always be accessed over SSL. From that point on, the client does the redirect to SSL, not the server, which removes the opportunity for a man-in-the-middle attack.

HSTS is accomplished by the web server by including an HTTP header with a name of “Strict-Transport-Security” and a value of “max-age=n” where n is a numeric value that indicates how long the browser should remember to always redirect to SSL.

support Strict Transport Security, or HSTS

While “Assign HSTS Policy” and “Display Login Page” are the same step, this illustrates the benefit of HSTS. This makes the window of opportunity for attackers much smaller. The attacker must now make the interception before the HSTS policy has been established, or between valid re-establishments. Configure HSTS with a very high max-age to establish how long the policy is valid for in seconds. For example, you might configure HSTS with a max-age of 31536000 seconds, which is one year.

Configuring HSTS in Internet Information Services (IIS) is possible with no additional software, given a little bit of additional configuration. One requirement of the HSTS specification is that the HTTP header is only sent by the server if the connection is on SSL. This can be done in IIS with a proxy website.

Typically, customers configure their Secret Server’s website to bind on ports 80 (HTTP) and 443 (HTTPS). When Secret Server sees that the request came in over HTTP, it redirects to HTTPS.

To configure HSTS for Secret Server, use IIS to configure the Secret Server website to only accept HTTPS connections. Next, create a website that listens only for HTTP connections. This HTTP-only website will redirect to the HTTPS Secret Server using IIS’s HTTP Redirection feature. Finally, the HTTPS-only website is configured to send the HTTP header in IIS’s “HTTP Response Headers” by setting the Strict-Transport-Security header with a maximum age. This achieves having the header only sent when HTTPS is being used.

Read All Parts:

SSL: Beyond the Basics
SSL: Beyond the Basics Part 2: Ciphers
SSL: Beyond the Basics Part 3: Certificates
SSL: Beyond the Basics Part 4: Strict Transport Security

Secret Server Trial

IT security should be easy. We'll show you how

Try Secret Server and experience how fast and easy IT security products can be.