All HTTPS all the time, With HSTS to boot

1 minute, 54 seconds

I’ve been brushing up on my web security best practices recently.  OWASP is a great resource for this!  One of their recommended best practices is to use HTTP Strict Transport Security (HSTS).  This involves redirecting traffic from unencrypted HTTP to HTTPS.  However to ensure that no future Man in the Middle attacks happen with the redirect, it’s best to tell the browser to always go directly to HTTPS regardless of the protocol.  This, in a nutshell is the HSTS solution.

I’ve updated plip.com and blog.plip.com to be served over exclusively over HTTPS.  This is thanks to a *.plip.com wildcard certificate from Global Sign. After setting up Apache to use the certs on the SSL vhosts, I then needed to redirect all traffic away from HTTP.  For plip.com, this was a simple Apache rule in the HTTP vhost:

# send everything to HTTPS
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

And then for the blog.plip.com, iThemes had this codex entry about a simple plugin to rewrite HTTP to HTTPS, following the second option on their page.  They do caution that this plugin might have performance drawbacks as you’re parsing every post on the fly.  You can fix this if you’re running a caching system, like W3 Total Cache, which I am! W3TC recommends you fix slow HTTPS calls by enabling caching of HTTPS: Go to Performance -> Page Cache and check “Cache SSL (https) requests.” Easy peasy!

Now to add the HSTS to the HTTP header.  For plip.com this is easy as I have a single PHP header file for the entire site. I just added this line:

header('Strict-Transport-Security: max-age=31536000');

For the blog, I extended the simple iThemes plugin by adding these lines:

add_action( 'send_headers', 'add_header_hsts');
function add_header_hsts(){
        header('Strict-Transport-Security: max-age=31536000');
}

Special thanks to the WordPress Codex on how to set headers as well as a random post over at Hakre on WordPress on how to format the HTTP header in PHP for HSTS.

Plip.com has absolutely zero affect on the big players, and the EFF would never care about giving me a report, but I’m scoring 4 out of 5 on EFFs encrypt the web report:

  1. Plip doesn’t have a data center, but all connections for administration are encrypted.
  2. Plip now, of course, supports HTTPS
  3. Plip now supports HSTS
  4. Plip does not support Forward Secrecy
  5. As Plip uses Google Apps, it supports STARTTLS

Looking at what it takes to set up my ciphers, I’m still gonna shoot for getting a perfect 5 of 5!

4 thoughts on “All HTTPS all the time, With HSTS to boot

  1. James C

    Very nice, I’ve been using HSTS for some time, here’s a tip for the future, no matter how tempting, don’t use the “includeSubDomains” option :)

    This is a great resource for evaluating your ciphers list to make sure you’re not using any old crypto options vulnerable to known attacks: https://www.ssllabs.com/ssltest/

    And your first link to OWASP is actually linking to ithemes.com :)

    Reply
    1. mrjones Post author

      James – thanks for the tip about the wrong link – it’s fixed now. I’ll check out the ssllabs.com site as I definitely need to brush up on my ciphers!

      I wasn’t sure about the subdomains for HSTS. The OWASP page says, “Before enabling includeSubDomains, also consider the impact of any existing DNS CNAME records for CDNs, email services, or other 3rd party services. Since includeSubDomains will force such CNAME subdomains to https:// it’s likely the browser will throw a domain-mismatch error, which is hard to reverse because of the browser caching nature of HSTS.” I take it you’ve had problems along these lines?

      Reply
      1. James C

        Yeah, you may not realize all the places you use the base domain plip.com (development, test, at home, Google Apps, other services) and the includeSubdomains option really breaks things across the board without any clear way to fix it except to touch every browser that has ever visited plip.com :)
        For your personal stuff, or a new site, it’s not a problem, but could be a big one if you use it on a busy established domain.

        Reply
  2. Pingback: Let’s Encrypt TLS & A+ on SSL Labs

Leave a Reply

Your email address will not be published. Required fields are marked *