CloudFlare’s SSL

By Ipstenu (Mika Epstein)How It Works

CloudFlare’s been pushing SSL for a while as a new feature. We all know that SSL is a great idea, that any time you have someone logging in, it should be secure. If you’re handling money, it should be secure. If you’re taking any personal information, for god’s sack (sic), make it secure!

A major problem with this has often been the cost overhead. You can self-sign your certificates, but that pops up with other errors for people. Really what we want is a simple, non-super-expensive, way to have security where and when we need it. Until Let’s Encrypt gets its kick off later this year (and probably for another year after that), it’s complicated and expensive to set up shared hosts with certificates, even if you use SNI.

Enter CloudFlare and their bold proclamation that they’re going to provide free One-Click SSL for everyone, even their free-plan users. This is great! Except that it doesn’t work quite right.

First off, if you use the flexible SSL plan, the one that doesn’t change your URL to HTTPS, then you need to use a plugin line CloudFlare Flexible SSL. Or you can just toss this into your wp-config.php:

#SSL
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
	$_SERVER['HTTPS']='on';
} else {
	$_SERVER['HTTPS'] = false;
}

Secondly, if you’re not actually changing the URL to SSL, you’ve got a problem. I don’t want my users to hit https all the time, not for all my sites. And all the reasons we don’t use https everywhere aside, it’s something to keep my running costs down.

My rule is that SSL should be used anywhere where you are transmitting information that should not be public, and this suddenly was an issue when I looked at the levels of security. The one I’d want would be Full SSL, as it “Encrypts the connection between your site visitors and CloudFlare, and from CloudFlare to your server.”

And there are two types of Full SSL, one of which is ‘Strict’ and requires you to have your own SSL cert, be it purchased or self-signed.

CloudFlare SSL for everything? Not exactly: Full SSL (strict) is too strict.

The obvious implications here, however, are that everyone would see HTTPS in the URL, and I don’t really want that. Of course, that’s not what they meant. What they mean is that IF you use https in the domain, then CloudFlare double encrypts. Otherwise it remains http for the domain.

So basically normal SSL. And this is what I want, because I do have a purchased SSL cert for the domain in question and I do want to be secure all down the line. If I was using a self-signed certificate, I’d use the Full SSL (not strict) and that would work as well.

One important thing to keep in mind is that if you chose to use the Flexible SSL, you’re not giving yourself login protection! As they point out, this gives you an encrypted connection between your site visitors and CloudFlare, but not from CloudFlare to your server. This greatly reduces the possibility of being sniped or sniffed, but the content from CF to use isn’t secured, which means if you use Flexible SSL for your store, you’re a moron.

With that in mind, what good is it? Well you can be promised security throughput for your domain, and that, if you’re using CloudFlare, is a great thing.

11 thoughts on “CloudFlare’s SSL”

  3. Hey Ipstenu, this was a good article, thanks =)

    And there are two types of Full SSL, one of which is ‘Strict’ and requires you to have your own SSL cert, be it purchased or self-signed.

    It was my understanding that ‘SSL FULL’ requires you to have any SSL cert at server, validated (purchased) or self-signed. The ‘SSL STRICT’ CF setting requires that you have a validated (meaning purchased) certificate at your server. Is this not so?

    Also, I thought it’d nice to mention that CF also now supports HTST 🙂

    I am using CF with my multisite networks to great effect (I love running my own budget mirror CDNs through CF too!) in concert with SNI at server and the combo is quite flexible and allows for some very (imho) cool configurations =)

    Cheers, Max

    2. @Ipstenu (Mika Epstein):

      hmm… you know, I could CF intending to mean that ‘SSL Full’ requires that the server be able to handle requests using SSL

      In which case “valid” for ‘SSL Strict’ would mean a properly generated and installed certificate that is not expired… (meaning it is immaterial whether it is purchased or self-signed – perhaps the key is difference between terms “valid” and “validated” in this context).

      This especially makes sense knowing that CF reserves further services to their Business-grade plans for working with validated SSL (for if you need EV for instance).

      Thoughts? Cheers, Max

    4. @Ipstenu (Mika Epstein): they have clarified this nicely in the help section at Crypto>SSL>Help

      The difference between Full and Full (Strict) is that Full (Strict) checks for a valid certificate on your origin server, whereas Full checks for any certificate.

      For a Multisite w/ Domain Mapping this means that mapped domains can use CF SSL Full when only network primary has SSL at server (and that SSL can be either self-signed or purchased from CA).

      Also, using SSL Full means no more redirect loop w/o need for adding


      #SSL
      if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
      $_SERVER['HTTPS']='on';
      } else {
      $_SERVER['HTTPS'] = false;
      }

      to wp-config, though may need to do something similar for
      define('FORCE_SSL_ADMIN', true);

Comments are closed.