Using SSL on WordPress? Not All Hosting is the Same

Introduction

I'm a huge fan of WordPress, and I've had this blog hosted on WordPress for many years. Given my security background, I always try and make my site as secure as possible, while not breaking functionality. One important feature, both for SEO and security is SSL. All you need a SSL certificate, right? Nope! And that's the basis of this post.

Not all SSL Configurations are the Same

Under the hood of SSL are a number of configuration options that you are probably not even aware of. Most of these relate to the supported protocols and cipher suites that can be negotiated with your site. These are generally web server back-end settings. A lot of SSL protocols and cipher suites have not lasted the test of time and are deemed flat out insecure or weak. For example, RC4, is pathetically insecure and should never be used. 

Most quality WordPress hosting companies provide free SSL certificates. So many people think it's just a single click (or even automated) to get your site secure with SSL. Not so! Your hosting company configured which protocols and cipher suites are available. And if your hoster isn't security conscious they can leave your website vulnerable and degrade your site's security. Never for a second think just because you have a SSL certificate that you are secure! 

How to test your SSL

Fortunately, it's dead easy even for a non-techie to test the SSL security of your site. All you need to do is go over to SSL labs and run a test against your domain. After a couple of minutes it will give your site a letter grade, and a lot of tech details about what it found. For example, on my WP Engine hosted WordPress sites I have an A+ rating. With a shared hosting plan with another company I got a poor B score with numerous security warnings. Take a minute and check your site now so you can see a full report.

The "A+" SSL Lab Report

First let me start with a site that passes with flying colors, this blog site. As you can see in the graphic below, it scores an A+ and also uses HSTS. HSTS is a super-strict form of TLS/SSL that you can read more about how to configure in a blog post I wrote here. This test result is from my current provider, WP Engine, using their managed WordPress offering. It's not cheap by any means, but frankly you get what you pay for with hosting, in most cases. 

As you scroll down the report you also get a list of protocols and cipher suites that your site supports. Looking at the report below, you see that none of the cipher suites are tagged as insecure or weak. That is good! Looks exactly like what we want it to. Thank you WP Engine! 

The "B" SSL Lab Report

Recently I got an economical (entry level, shared plan) WordPress hosting account with InMotion hosting, just for experimentation purposes. I could try out new tools, check out another hoster's performance, and see if there was any compelling reason to consider a future move away from WP Engine to something less expensive. 

I stood up a new domain, got their free SSL certificate, and then ran a SSL Lab report scan. I was horrified to see the results. Overall it got a "B" which may not sound bad, but digging into the details really made me uneasy. And I had to contact their tech support, but more about that later in this post.

Looking into the details of the "B" grade you can see that RC4 is supported (very, very insecure) and that forward secrecy is not supported. But let's dig deeper into the cipher suites to see what's going on.

Right off the bat you can see three cipher suites are enabled that use RC4. Really bad! And another three cipher suites are labled 'weak'. Also not good, but not as bad as 'insecure'. Clearly, this is significantly worse than the WP Engine scan. 

Fixing the Issues

Because the protocols and cipher suites are back-end configuration settings, I contacted InMotion tech support to see what they could do. And there was bad news, and good news. Firstly, for the shared plan I was using NOTHING could be done. As the TLS/SSL configuration is set across numerous customers. However, if one went with their VPS plans, individual sites can be configured per customer requirements. If I was on a VPS plan, then the hoster would take care of all the configuration. You should then re-test, and see if the security holes were plugged. An A+ rating is not to hard and doesn't require techie level skills. 

Summary

Even if you have an SSL certificate on your site, that does NOT mean you are optimally configured. Your hoster could be using very insecure settings, but you'd never know without testing it. So if you have never tested your website's SSL, do it immediately. You may be shocked with what is lurking in the results. On the flip side, most of the work is done by your hosting service so you don't need to know what files to configure. I'd just send them a screenshot of the 'bad' results and tell them to fix it. 

You also need to be conscious of which plan you are using with a provider, and how that impacts security. For example, my shared plan with InMotion doesn't allow them to tweak the SSL security whereas their VPS plan would. Whether you want to spend the additional money for VPS (or find another provider that's more secure by default), that's your call. 

Knowledge is power, and knowing where your site's SSL stands is important. It's up to you whether you want to fix it and get an A+ rating or not. If you are running any type of security sensitive transactions like payments or storing personal information, I'd urge you to configure your site for an A+ SSL labs rating. 

Create Trusted Remote Desktop Services (RDP) SSL Certificate

For Windows environments that want extra security, one of the features that has been around for ages is requiring TLS 1.0 for Windows RDP (Remote Desktop) connections. This functionality requires a certificate on the server, since TLS is based on the usage of X.509 certificates. Installing a RDP SSL certificate is easy.

By default Windows will create a self-signed certificate automatically for use with RDP. But as we all know, self-signed certificates are nearly worthless, and could easily be intercepted for man-in-the-middle attacks. So one should reconfigure Windows to use a trusted certificate. Thankfully this is fairly easy, and once configured, pushed down to all servers via GPO for automated deployment.

I’ve validated that this procedure works both on Windows Server 2008 R2 and Windows Server 2012. It may work on Windows Server 2008.It requires the use of a Microsoft enterprise online certificate authority. Again, I’ve used both Windows Server 2008 R2 and Windows Server 2012 CAs with success. Not surprising, since certificates are industry standard. For the purposes of this article I’ll use Windows Server 2008 R2 CA, and Windows Server 2012 “target” server.

The general process is first creating a new Certificate Authority certificate template that has an extended key usage to limit its use to only Remote Desktop TLS sessions. Second, we configure a GPO setting to automatically configure servers to request a certificate via this template, and use it for RDP TLS. Refresh GPO on the target server, and finally we attempt to connect via a stand-alone computer to verify it sees the certificate that we deployed.

Installing a RDP SSL Certificate

1. On your Microsoft certificate authority server open the Certificate Templates console.

2. Duplicate the Computer template and use the Windows Server 2003 Enterprise format (Server 2008 v3 templates will NOT work).

3. Change the template display name to RemoteDesktopComputer (no spaces). Verify the Template Name is exactly the same (no spaces). You can use a different name if you want, but both fields must match exactly.

4. Now we need to create an application policy to limit the usage to RDS authentication, then remove the other application uses for the certificate. On the extensions tab click on Application Policies then click on Edit.

5. Click on Add, then click on New.  Set the value of Name to Remote Desktop Authentication. Change the object identifier to 1.3.6.1.4.1.311.54.1.2.

6. From the Application Policies list, select Remote Desktop Authentication.
7. Back on the certificate template properties, remove all other entries. Only Remote Desktop Authentication should be present.
8. If you wish, you can modify the validity period of the certificate, making it say two years instead of the default of one.
9. You probably want to secure your domain controllers as well, so for that we need to modify the security setting on the template. Open the Security tab and add the group Domain Controllers and give the group Read and Enroll (not Autoenroll).
10. Open the MMC snap-in for managing your Certificate Authority and locate the Certificate Templates node. Right click, select New, then Certificate Template to Issue. Choose the RemoteDesktopComputer template.
11. Next up is configuring the GPO to utilize the new template. You can modify any GPO you wish, or create a new one. Obviously the scope of the GPO should cover any servers that you want to secure with TLS. This could be a server baseline GPO, domain GPO, or whatever you want.
12. In the GPO editor locate the node Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session HostSecurity. Modify the Server Authentication Certificate Template setting. Enable the policy and enter the certificate template name that exactly matches what you created in your CA.

13. In the same GPO node, configure the Require use of specific security layer for remote (RDP) connections to use SSL (TLS 1.0).

14. Wait for the GPO to replicate, then refresh the GPO on a test server. Wait a minute, then open the Certificates MMC snap-in for the computer account. Look in the PersonalCertificates store for a certificate that has the Intended Purposes of Remote Desktop Authentication. If it’s not there, wait a minute, and refresh. If it never appears, something is wrong. Look at the gpresult to make sure your GPO is being applied to the server.

15. Once the certificate appears, double click on the certificate to open it. On the Details tab look at the first few characters of the thumbprint value and remember them.

16. To make sure the RDP service is aware of the new certificate, I restart the Remote Desktop Services service.

17. Open an elevated PowerShell prompt and run this command:

Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

Validate that the Security Layer value is 2 and that the thumbprint matches the certificate. If both of those settings are correct, then you are good to go!

As a quick test I attempted to connect to this server from a non-domain joined computer that did not have the root certificate for my CA. I configured the RDP client to warn on any security issues. As expected, the client threw errors about the CRL not being available, and that it didn’t trust the chain. I also viewed the certificate and verified it was the correct one.

It seems Windows 8 has much more stringent certificate checking than Windows 7. The screenshots below are from Windows 7, in case you didn’t recognize the chrome. When using a Windows 7 non-domain joined computer to access the same TLS protected server, I got NO certificate warnings. That was even with the RDP 8 add-on hotfix. I’m glad to see Win8 does thorough certificate validation.

Connecting to the same server from a domain-joined computer that trusted the root CA resulted in no security warnings and a successful connection. If you look at a Wireshark capture you can also validate that CRL information is being exchanged between the computers, which means TLS is being used.

Enable TLS 1.2 Ciphers in IIS 7.5, Server 2008 R2, Windows 7

Some industries, like Government, require the use of certain cryptography algorithms. One of the great features of Windows Server 2008 R2 and Windows 7 is the support for TLS 1.2 ciphers. TLS 1.2 ciphers support AES-256 encryption with SHA-256 hashes. Unfortunately, Microsoft did not enable these protocols out of the box. I wanted IIS 7.5 to negotiate TLS 1.2 connections with my Windows 7 clients. After some registry hacking I was successful, as shown by a Wireshark trace.

I created a simple PowerShell script that enables TLS 1.2 for both client and server communications. It also disables SSL 2.0 server responses, in case you need to be PCI compliant. The lines are pretty long, so pay attention to the wrapping. After you run the PS script (with elevated rights) you must reboot the client and server.

Please note that all values must be DWORD. This is very important, as any other value type will NOT work and you may be pulling your hair out wondering why it’s not working.

# Enables TLS 1.2 on Windows Server 2008 R2 and Windows 7

# These keys do not exist so they need to be created prior to setting values.
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client"

# Enable TLS 1.2 for client and server SCHANNEL communications
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -name "DisabledByDefault" -value 0 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -name "DisabledByDefault" -value 0 -PropertyType "DWord"

# Disable SSL 2.0 (PCI Compliance)
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" -name Enabled -value 0 -PropertyType "DWord"

After you run the PowerShell script, you should see DWORD entries like those shown below. Also, go into the Advanced properties of IE and check the box next to TLS 1.2.

If you start a WireShark capture on a TLS session you will know it’s v1.2 by two easy methods. First, the Protocol column will show TLSV1.2. Secondly, if you open the ServerHello packet you should see burried in the packet:

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)

You can also configure the advanced settings in IE8 on Windows 7 or Server 2008 R2 to only use TLS 1.2 by de-selecting all other SSL/TLS options. If your browser can connect with just TLS 1.2 selected, then you are golden. But for 100% verification, use a packet sniffer.

Another tweak you can do to your system is change the order of the cipher suites that Windows negotiates. This is possible in Windows Vista and higher. I changed the order such that TLS_RSA_WITH_AES_256_CBC_SHA256 is at the top of the list. Next to elliptical curve ciphers, this is the strongest that Windows offers.

To change the cipher suite order, open the GPMC on a Server 2008 or higher DC and navigate to: Computer\ Configuration\Policies\Administrative Templates\Network\SSL Configuration Settings. Enable the policy, then copy the cipher suites to Notepad and change the order as you wish. I just flipped the first two entries. So my first two entries look like:

TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256

I haven’t done extensive testing to know what types of compatibility problems enabling TLS 1.2 may create. So as always, test, test, test! I confirmed with WireShark that the Windows RMS client in Windows 7 will use TLS v1.2 to contact the root Windows Server 2008 R2 RMS server.

During my research I stumbled upon a cool Microsoft web site that lets you test various cipher suites with your browser. If you click on the cipher suites on the server authentication line you can see what your browser will support.

Lastly, Microsoft has a good reference of which cipher suites are associated with which protocols.