Picture of Brian Love wearing black against a dark wall in Portland, OR.

Brian Love

HTTPS Everywhere

You might have heard this past summer that Google has made a slight (less than 1% of sites will be affected) modification to their algorithm to give more value to those sites that use HTTPS than those sites that do not. This is a result of Google’s push for HTTPS Everywhere. You can watch a presentation from Google I/O 2014 where they explain the need for HTTPS, the type of risks and attacks that can result from not having HTTPS, how to implement HTTPS on your website, and some tips on maintaining your ranking in the SERPs.

As part of a new series, I am going to cover the basic steps that I took to migrate to HTTPS.

Enable HTTPS

You must first purchase and install a 2048-bit SSL certificate and enable HTTPS on your web server. I will cover the following topics for enabling HTTPS:

Configure Protocols and Ciphers

The next step is to configure the SSL engine’s supported protocols and ciphers. If you have been following along with the security news this year you have likely heard of some high profile security flaws, namely, the Heartbleed and POODLE flaws.

I will cover the following topics for cryptography configuration and testing:

Enable HTTP Keep-Alive header

The keep alive header enables us to set the protocols for the HTTP connection that is established between a server and client, as well as the intermediaries along the way. It basically tells the server:

“Hey, I am going to do a bunch of work here, why don’t we leave the connection open for awhile so I can get things done.”

By default the HTTP connection is closed after each request has completed. This header allows us to keep the connection open between the client and server for multiple requests.

Why is this important?

Well, one of the myths of using HTTPS is that it is slower. And, there is good reason for this. When using HTTPS there is an additional handshake that is required to secure the connection between the client and server. Every time we establish a new HTTP connection using HTTPS the handshake process has to happen. We can avoid this by simply opting to leave the connection open longer.

I will cover this in detail in an article on enabling the Keep-Alive header

Enable HTTP Strict Transport Security (HSTS)

Similar to our Keep-Alive header, HSTS is a response header that our server sends back to our client notifying the user’s browser that we use HTTPS everywhere. This means that there is no need for the browser to try to request insecure content, and that it should always use HTTPS on our website.

Why is this important?

Again, you might be asking yourself why this is important, and again, the answer is for performance reasons. In the next section on enabling permanent (301) redirects to our HTTPS website we will learn how to redirect all traffic to our new secure website. However, we are always seeking to reduce the number of redirects — as a redirect takes time.

Implementing the HSTS header avoids any redirect penalties. I will cover this in detail in an article on Enabling Strict Transport Security (HSTS).

Permanent redirects to HTTPS

The next step is to redirect all of our traffic from the insecure website to the new HTTPS URL. We will a rewrite rule to direct all traffic to our HTTPS website.

The important thing to note here is that I will redirect all non-secure HTTP requests to the full HTTPS URL. For example, if a user enters: http://www.example.com/contact-us?tracking=123 Then, we want to be sure that the user is redirected to the full URL with the query string attached: https://www.example.com/contact-us?tracking=123

I have heard of some instances where the site was redirecting all insecure pages to the new HTTPS home page. We don’t want to do that, we want to ensure that the Googlebot can follow the old backlinks to our insecure site to the same page on our secure site.

We want to send a consistent message to the Googlebot:

“Our site is now secure, here are the new URLs.”

In order to accomplish this we want to ensure our internal links are all correct. I won’t go into any more detail on this, as this will be based on your framework and language.

Update canonical tag URLs

As a follow up to the previous step, we want to continue to send the correct signals to Google. As such, we want to verify that all of our canonical tags include the full HTTPS address to our pages.

Update XML sitemap

In continuation of the theme of sending the right signals to Google, we will also want to update our site’s XML sitemap to use our new HTTPS URLs. We also want to be sure to modify our robots.txt file to reference the new sitemap that is being delivered via HTTPS.

Sitemap: https://www.example.com/sitemap.xml

Setup Google Webmasters

This one caught me by surprise. But, one important part of moving your website from HTTP to HTTPS is to ensure that you have set up and configured your new website in Google Webmaster Tools (GWT). GWT recognizes an HTTPS site as a different website from your HTTP site. So, be sure that you have created the new profile for the http-site and that you have copied over the setting to the new profile.

Some of the items that you should verify are: