There’s a lot of hype in the SEO industry at the moment regarding Google’s recent announcement about giving higher ranking to websites forcing HTTPS by default. After watching the Google I/O video, I jotted down a few notes to help you get started.
Systems Admin Checklist
- Get a 2048-bit TLS certificate
- Configure TLS on your server(s)
- Verify TLS server configuration
- Monitor performance: resumption rates, etc.
- Tune server configuration: cache sizes, etc.
- Investigate SPDY & HTTP 2.0
Get a 2048-bit TLS Certificate
When choosing a TLS certificate, there are three types of cert options: single host (site.com), multi-domain (sub.site.com, cdn.site.com, site.us), and wildcard (*.site.com). The most common TLS purchased is multi-domain since most of the time you know exactly what subdomains you manage.
Pricing options vary by the type of website you own. For example:
- Free certificates for non-commercial use from StartSSL
- Free certificates for open-source projects from GlobalSign
- Commercial multi-domain certificates for $30+
- Commercial wildcard certificates for $100+
Configure TLS on Your Server
Refer to Mozilla “Service Side TLS” wiki for configuration best practices for Apache, Nginx, HAProxy, AWS, and other popular servers.
Verify TLS Server Configuration
To verify that you’ve configured TLS correctly, use the Qualys SSL tool to quickly identify misconfigurations. You’ll want to test with this tool every time you change your configuration.
Monitor Performance: Resumption Rates, etc.
What about the CPU resources on the server? A common hangup developers (and us SEO’s) have about using HTTPS by default is load time issues, probably the reason you’re reading this post to begin with, right?
So apparently there are two steps to establishing the TLS tunnel:
- Asymmetric cryptography – where we verify the certificate and do the public crypo
- Symmetric cryptography – where and how we actually encrypt the application data
The overhead comes from asymmetric cryptography, which can be reduced using keepalives and session resumption. Keepalives allow you to use the same connection between different requests, which means you only need to do a handshake once.
Session resumption actually means that you can reuse the negotiator parameters of our secure session from a previous session when we establish a new one. So once again we skip that handshake and significantly reduce the overhead.
In the old days of the Internet, you’d need specialized hardware to handle HTTPS, where modern day servers have specialized CPU’s optimized to handle this type of work that we do in the TLS stack.
Investigate SPDY & HTTP 2.0
You can see significant differences in load time by installing SPDY, but it also creates a scenario that uses a single connection, resulting in fewer handshakes, resources, memory and Apache worker threads.
What are you waiting for? I’m on a mission to start working toward HTTPS everywhere. Google I/O folks created a site to help you at isTLSfastyet.com that you may also find interesting. Are you going HTTPS? If not, what’s your hangup?
