We will be closed Monday, September 1st in observance of the U.S. Labor Day holiday. More info »

Blog

  • 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 web site.

    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.

    Thanks to all for following our SSL: Beyond the Basics posts! Get more security information by subscribing to our blog and following us on LinkedIn and Twitter, where we keep you updated on the latest IT security trends and Thycotic product updates.

    Leave a reply →

Leave a reply

Cancel reply