Technical And Webmaster Guidelines For HTTPS

August 22, 2014 | Sean McQuaide

blog-https-large

Spurred on by the Edward Snowden revelations, Google has begun taking security more seriously. After the revelations came out, Google quickly secured and patched their own weaknesses. Now they are pushing to encrypt all internet activity by incentivizing websites that use SSL certificates by giving them a boost in rankings.

During a Google I/O presentation this year called HTTPS Everywhere, speakers Ilya Grigorik and Pierre Far made it clear that this move is not just about encrypting the data being passed between server to browser, but also to protect users from having the meta data surrounding those requests collected.

Though the meta data collected by visiting a single unencrypted website is benign, when you aggregate that data it can pose serious security risk for the user. Thus by incentivizing HTTPS, Google has begun to eliminate instances on the web where users could be vulnerable to having information unknowingly collected about them.

I will give you the spark notes version of the HTTPS Everywhere presentation, but even that will warrant a TL;DR stamp. My hope is that this outline and the resource links contained within it give you a hub you can use when evaluating and implementing HTTPS on your site.

What is Internet Security

When Google talks about securing websites and users with HTTPS, they are really talking about three things: Authentication, Data Integrity, and Encryption

Authentication involves making sure the site you are visiting is who they say they are.

Data Integrity revolves around protecting the data from being modified while in transit.

Encryption, probably what you first think of, is about making data unreadable if someone does get ahold of your data.

Together this trio works to prevent passive attackers from listening in on user activity, prohibits attackers from tampering with data while in transit, and inhibits attackers from impersonating the destination site. In the past implementing this level of protection was met with some resistance because of the cost and latency added to running a website.

Ilya and Pierre acknowledge this in their HTTPS presentation and present us with a process of implementing HTTPS in a way that reduces the cost and latency traditionally associated with adding a TLS layer to your site. Their recommendations come straight from Google’s own HTTPS implementations which saw double digit page load improvements over their HTTP counterparts.

There are two checklists, first is the System Admin Checklist; second is the Webmaster checklist. The System Admin checklist should be followed in order.

It’s important to note that as of right now HTTPS as a ranking factor is only affecting 1% of sites in search results. So making this change is not urgent. I assume if you are selling things online then you already have HTTPS set up on your site, in which case you’re ahead of the curve.

If you already have HTTPS, I would suggest you use the Qualys SSL Tool to evaluate the level of security your certificate is offering you, talk to your developers about how they’re leveraging keep-alives and session resumption, and ask them if SPDY implemented on your server. Note: SPDY is currently only available on Apache servers.

Webmasters, consistency is very important when moving a site to HTTPS. Any link or 301 that could direct a user to an HTTP version of the site opens a hole in the security you invested so much time setting up. So take protocol relative URLs seriously and monitor webmaster tools following implementation.

System Admin Checklist: Configuring the Transport Layer Security (TLS) and making it fast.

1. Get a 2048-bit TLS certificate

  • Presentation Start: 10:03
  • Must be 2048-bit, sites using 1024-bit certificates should upgrade
  • You must decide between single domain(example.com), multi-domain(example.com, cdn.example.com, example.us), or wild card(*.example.com) certificate
  • Cost depends on use case
    1. Non-commercial: Free certificates for non-commercial use from StartSSL
    2. Open-Source Project: Free certificate from GlobalSign
    3. Commercial multi-domain certificates for $30+

2. Configure TLS on your server

3. Verify your configuration

  • Presentation Start: 13:20
  • Use Qualys SSL Labs SSL Report Tool to test that your server has been configured correctly

4. Monitor Performance

  • Presentation Start: 14:42
  • Two steps: Asymmetric and symmetric cryptography
  • Asymmetric
    1. Optimize keep-alives
    2. Utilize session resumption
    3. These two work together to eliminate the need for a full authentication handshake which reduces your CPU usage.

5. Tune your server configuration

6. Enable SPDY HTTP2

Webmaster Checklist: Making HTTPS search engine friendly

1. Update site content to request HTTPS resources

  • Fix hardcoded URLs by implementing protocol relative URLs
  • “Protocol relative URLs” just means that your links will adopt the https header automatically when moving the site from the development server to the live site. Protocol relative URLs are also used to prevent security gaps from cropping up by making sure all links on the site are pointing to https versions of a page. It saves both the developer and SEOs a lot of headaches.
  • These links should be implemented across the entire site, including resource links. If resources like javascript or css files have an http link on an https page, the browser will not load those pages.

2. Set up redirects from http to https, add HSTS, set up rel=canonical, and robots.txt

  • Make sure your reducing redirect or eliminating redirect chains, they make latency much worse for mobile users.
  • Eliminate redirects by using HTTP Strict Transport Security (HSTS)
    1. Presentation Start: 26:39
    2. Using HSTS, the browser remembers that it should automatically request HTTPS resources for this site and its subdomains.
    3. Here’s the HSTS Documentation by Mozilla
  • Rel=canonical
    1. Make sure https pages contain self-referencing canonicals as a means of reinforcing the signal sent to Google with the redirect
    2. Canonical URLs should be hard coded as opposed to protocol relative
    3. Here is the Google Documentation about using canonical URLs
  • Robots.txt
    1. Make sure you are not blocking the http version of the website with robots.txt
    2. If you block the http version of the site then search engines will be unable to crawl the 301s redirecting users from http to https

3. Verify robots.txt, rel=canonical, and 301 redirects are correct

  • Verify all variants. This includes http & https for all www, non-www, and mobile sites.
  • Check the index status of each http and https site. After launching https, HTTP should drop to zero and HTTPS should spike to the HTTP’s previous version. If not, then you have probably missed some redirects, hard coded URLs, or have accidentally blocked something in robots.txt
  • Check Crawl Errors. Check the webmaster tools crawl error report for additional monitoring of the site move. Google recommends you check out this documentation about site moves to help smooth out the process.