Transitioning to HTTPS and HTTP/2 – Preparing the Stack

STH Main Site 2016 HTTP2 Validation
STH Main Site 2016 HTTP2 Validation

This weekend we finally tackled a project that we have been dreading, re-platforming the STH WordPress stack. This provided an opportunity to move towards using HTTPS with HTTP/2 support. As of this weekend, we are now re-directing all HTTP links to HTTPS. Google has announced that starting with Chrome 56 in January 2017 the company is taking an even more aggressive stance against HTTP websites. Chrome will be marking them insecure in user’s browsers.

From the recent announcement:

Beginning in January 2017 (Chrome 56), we’ll mark HTTP sites that transmit passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.

This means that all of those sites that are currently being served via HTTP are likely going to have to move to HTTPS over the next three or four months. On the STH WP site we handle neither user logins nor credit card information, but many HTTP sites today do. Swapping to HTTPS does mean that there is a significant performance overhead attached which is why HTTP/2 is being adopted to speed up browsing.

STH Q3 2016 HTTPS and HTTP/2 Web Stack Update

Although there are plenty of guides that talk about WordPress day 1, few touch on longer-term deployments. The STH WordPress instance was originally from early 2008 (although we started STH formally in June 2009.) As an example of why that is important, WordPress 2.3 still used Latin-1 encoding in the database. Which broke in the new stack so we had to go through the extra step of converting the entire database to UTF8. Here is an example of what we saw on the development site:

STH WP Latin-1 artifact in database
STH WP Latin-1 artifact in database

As applications age, things break. It is also why we tell people that a fresh WordPress install is worthless for benchmarking purposes since most installations have gremlins working behind the scenes.

Here is a list of some of the changes we made:

  • Nginx update from 1.4 to 1.10
  • OpenSSL Update
  • Ubuntu 14.04 LTS to 16.04.1 LTS
  • MariaDB 5.5 cluster to 10
  • Varnish -> Removed
  • PHP -> php7-fpm
  • HTTP -> HTTPS and HTTP/2

We have a few more performance tweaks to make, namely in the caching and enabling Intel QuickAssist Technology support for OpenSSL and streamlining downloaded resources. We did take a snapshot at this point to start developing into a potential benchmarking instance. The transition to HTTPS and HTTP/2 is going to add a significant performance overhead and we have content planned to show the impact of acceleration technologies from several vendors.

For those wondering here is the SSL validation:

STH Main Site 2016 HTTPS Check
STH Main Site 2016 HTTPS Check

Here is the HTTP/2 validation:

STH Main Site 2016 HTTP2 Validation
STH Main Site 2016 HTTP2 Validation

We are constantly making changes to the hosting stack at STH that often go unnoticed. These changes will mean that we are now redirecting all STH main site and STH forums links to HTTPS. At STH, the same folks doing reviews are also the folks maintaining the infrastructure. This practical experience is constantly pushing us to test practical use cases. If one were to look at major tech review sites today (September 12, 2016), the vast majority are still running HTTP only. STH is clearly ahead of the trend.

HTTPS and HTTP/2 Transition Key Takeaway

The key takeaway here is that if you have pages still serving HTTP content it is time to start working on a transition to HTTPS and HTTP/2. Our next project is transitioning the forums to the new Ubuntu 16.04 LTS stack and swapping Google’s SPDY for HTTP/2 (apt-get upgrade failed miserably.) As part of this we are creating VMs that we can use to test new hardware and technologies like Intel QuickAssist to accelerate OpenSSL.