CloudFlare as a Registrar, Part II

I received notification of early entry to the CloudFlare registrar service. I transferred a domain (this one) for a test drive. My initial impression … pretty awesome!

The process of transferring the domain was less time consuming and onerous than I expected. It required actions at both CloudFlare and NameSilo, as well as email. The steps at CloudFlare were a bit confusing, not always clear what was happening or where and when to click, and instructions seemed lacking. I almost gave up a couple of times. But the CF registrar service is in its infancy and I’m sure the user experience will improve. There were several delays while things got sorted out. Overall the process took maybe an hour of work over the course of a couple of days.

And … I think I’m going to really, really like CF as a registrar. In a nutshell, it is the exact opposite of GoDaddy:

  • The CF registrar service is bare bones. The full extent of the CF domain manager (see image) is a small section of the site’s Overview page. That’s it. Just the essentials. Everything I need with nothing extra to get in my way.
  • Absolutely no obnoxious up-selling. Maybe because there is nothing to up-sell.
  • My concerns over extra-cost services appear to be groundless.
    • Whois Privacy is included for free, by default.
    • Two-Factor Authentication is the existing, free service that CF has long offered, and which I already use.
  • As an unexpected bonus, DNSSEC is not only free, but setup automatically if I already was using it.

CF as a registrar has a lot going for it. But, I can think of a couple of good reasons to stick with NameSilo. First, NameSilo is also awesome, has provided me superb service, and is just slightly more expensive than CF. Also, I really like keeping my registrar service separate from all other services. So, I will likely stick with NameSilo for most of my domains. That said, CF as a registrar is absolutely worthy of consideration. If I ever have a need to move on from NameSilo, it gives me great peace of mind to know that CF is waiting patiently as a safety net.

Coming Soon: CloudFlare as a Registrar

For awhile now, CloudFlare has been quietly advertising “coming-soon” no-added-fees registrar services for CloudFlare customers – even those like me on the free tier. According to the sales pitch, CF will charge exactly $0 for this service, adding no fee at all to the Wholesale Registry fee (currently $7.85 for dot com) + the $0.18 ICANN fee. So, CF will register a dot com domain for the bargain annual cost of $8.03.

 

I have been extremely happy with my current registrar, NameSilo. They charge $8.99 per year per dot com, almost a full dollar more than CloudFlare. So, CF is – or will be – a better deal, right? I’m not so sure.

First, transferring domains is a time-consuming and complicated royal pain in the rear. Even for a notorious cheapskate like me, it may not be worth all the hassle to save a buck/domain/year.

Second, I really like the concept of keeping my registrar services separate from other web services. CF is planning to offer registrar services only for domains already on CF – including, very generously, on the free tier. But if I ever decide to move on from CF, I would have to once again endure the time-consuming and complicated process to transfer my domains back to NameSilo. Or, if CF fell out of love with me, they could conceivably hold my domain names hostage. I have no reason to suspect the good people at CF would do such a thing, but it has happened to many domain owners when dealing with less ethical web companies.

Third, there are some troubling ambiguities and seeming contradictions in the CF sales pitch:

  • The sales pitch clearly states … “we promise to never charge you anything more than the wholesale price each TLD charges. That’s true the first year and it’s true every subsequent year. If you register your domain with Cloudflare Registrar you’ll always pay the wholesale price with no markup.”
    • All well and good for the registration fee. What about for associated support services? CF is much more ambiguous. The sales pitch lists the following services – note that only DNSSEC is explicitly listed as free: “Two-factor authentication; Multi-user support; WHOIS management; Automatic domain renewal; Registrar Locking; DNSSEC (free); Bulk Domain Transfers; Developer-friendly API.”
    • Will the other services be free, or $1 each/year, or $10 each/month? Who knows? CF doesn’t say.
    • What is clear is that NameSilo offers most of these services – including: Two-factor authentication; WHOIS management; Automatic domain renewal; Registrar Locking; DNSSEC; and Bulk Domain Transfers – as well as others not mentioned by CF, like Domain Defender and Domain Parking (with my advertisements) – absolutely for free.
  • There is also a disconcerting disconnect between CF’s sales pitch … “we promise to never charge you anything more than the wholesale price each TLD charges”, and the fine-print legal language in their Domain Registration Agreement … “Cloudflare expressly reserves the right to change or modify its prices and fees for the Registrar Services at any time”.

So, I think I’ll stick with NameSilo. For now at least. When CF’s registrar service is actually offered, no longer “coming soon” for an unknown period, I’ll probably move a domain over and try it out, and update this post with my experience.

Update 2019-01-20: I received notification of early entry to the CF registrar service. I transferred a domain (this one) for a test drive. My initial impression … pretty awesome! See CloudFlare as a Registrar, Part II.

WP Contact Form Security

There are a couple of aspects to the security of my Contact Kenny page.

WP Contact Form Security

  1. Protecting my visitors: I need to make sure the data my visitors enter on my contact form is safe and not intercepted in transit. Just as important – or perhaps even more important – my visitors must have confidence that their data is safe and will not be intercepted in transit.
  2. Protecting me: I really effing hate contact form spam. Actually, I really effing hate all spam, but I’ve kinda gotten used to a certain amount of email and certain other spam being inevitable. But not contact form spam. I want exactly zero contact form spam.

#1 is pretty straightforward. SSL solves the problem. And SSL is now free and relatively easy provided that my hosting provider offers Let’s Encrypt. If my hosting provider does not offer Let’s Encrypt – time to switch hosting providers. Which I did. Sorry LunarPages. You were otherwise a solid host – which is why I stayed with you for roughly a decade and a half – but Let’s Encrypt became essential.

#2 is a little trickier. Most WP contact form plugins support recaptcha and/or a honeypot. Or I could use a CloudFlare page rule to turn on ‘Browser Integrity Check’ and set the security level to ‘I’m Under Attack’. Any one of these measures will stop the vast majority of spam bots – but a few extra-smart bots will still slip through. Any two of these measures, working together, will stop all bots. ‘All’ is probably an exaggeration, but I have never seen a bot slip through when I use two separate bot stoppers.

Update: Drat, I spoke too soon. It doesn’t happen much, but maybe once every couple of days a spam bot will slip through both my CloudFlare page rule and honeypot to kindly inform me about sexy singles in my area.

Honeypot

I was using both a recaptcha and a honeypot, but a plugin update at some point broke my recaptcha. So, I switched to a CloudFlare page rule paired with a honeypot. This method has the huge advantage of blocking the vast majority of bots at the reverse proxy level – keeping them completely off my site. It has the huge disadvantage of using up one of my three precious page rules.

To free up a page rule for contact form bot-blocking, I reluctantly gave up my ‘Cache Everything’ page rule. My sites are still speedy since I use a quality host and the excellent LiteSpeed cache. Also CloudFlare by default still globally caches images, CSS, and JavaScript – just not html. Site speed decreased by only about 2% in North America, but about 10% in Europe and Asia. For me, that’s a small price to pay for my obsessive hatred of spam bots.

Web Cache Deception Hacks

Web Cache Deception Hacks

Web cache deception hacks are a fairly recent threat, first described by Omer Gil in February 2017. In certain situations a hacker could leverage a misconfiguration between a web server and a proxy cache like CloudFlare to reveal sensitive information that could help the hacker takeover my account. To be honest, this seems like a very unlikely threat. The situations that could cause it seem complex and obscure, and large scale attacks of this sort have not been observed in the wild.

But, I never know when a brilliant bad guy or gal could find a way to expand a tiny, obscure threat into a great big nasty one. So, it makes sense to do what I can to prevent it. CloudFlare initially recommended that each and every CloudFlare user carefully check his or her server and CloudFlare configurations, and fix anything amiss. Kinda wishful thinking there on CloudFlare’s part. This is sure to be over the head of most users, and even those tech-savy enough to do it probably won’t get the word, this being an obscure threat.

Fortunately CloudFlare introduced a more practical solution about a few months later, in January 2018. The Cache Deception Armor page rule promises protection from Web Cache Deception hacks while still allowing static assets to be cached. It makes sense to include this new rule with my ‘Cache Everything’ rule.

Allowing only CloudFlare traffic

No piratesIn other posts I give my point of view on the security advantages of using CloudFlare. But what’s to stop a bad guy, gal, or bot from accessing my site directly by IP address? I can try to keep my IP address secret, but a determined hacker will find it without too much trouble. He or she or his/her robot minions could then avoid CloudFlare security by attacking my site directly – unless I take explicit measures by allowing only CloudFlare traffic.

CloudFlare advises using directives in my htaccess file to allow traffic only from CloudFlare IPs. Problem is – that doesn’t work for me. My server is configured to see each visitor’s origin IP, not the CF IP, so that my visitor analytics make sense. I googled my fingers blue and could not find a solution.

In desperation – because I am a stereotypical guy who hates asking for directions – I asked for directions. A kind and knowledgeable person using the moniker sdayman came immediately to my rescue. It turns out he is a very prolific good Samaritan in the CloudFlare community.

Sdayman’s solution is elegant – three lines of code – and in my experience it works great:

RewriteEngine On
RewriteCond %{HTTP:CF-IPCountry} ^$
RewriteRule ^ - [F,L]

It checks to see if the CloudFlare IP Country header is present. If not, it serves a 403 error. Traffic bypassing CloudFlare will not have the header.

One small gotcha – I have to make sure I turn on the CloudFlare IP Geolocation feature. Easy-breezy. It’s on the Network screen.

Allowing only CloudFlare traffic

Rocket Loader rocks! (finally)

Since 2011 CloudFlare, even on their free tier, has offered a very promising, very frustrating feature called Rocket Loader. Rocket Loader promises to greatly accelerate the loading of JavaScript, turbocharging JavaScript-heavy sites like those that use WP.

Rocket Loader rocks

At the beginning, Rocket Loader was labeled ‘beta’ – meaning buggy – and gained an unfortunate reputation for causing wonky behavior, especially with WP sites. In my case Rocket Loader broke the sliders on my WP sites. So, I patiently waited for the bugs to be eradicated and the ‘beta’ moniker to be banished. The years crawled by. 2012 – still beta, still wonky. 2013 to almost half way through 2018 – still beta, still wonky. I had almost given up. I don’t mean to unduly criticize the good people at CloudFlare – they provide a truly awesome service of which I take full advantage of the free tier.  I benefit tremendously and they make not a penny from me. I owe them immense gratitude and they owe me absolutely nothing. Still, I was selfishly irritated waiting years for Rocket Loader to finally work right.

My irritation ended today. Rocket Loader graduated from beta and entered prime time on June 1, 2018 – but I just noticed today. In my admittedly so-far brief testing it works perfectly – it no longer breaks my sliders. And it significantly speeds up my sites. Using my favorite website speed test – GiftOfSpeed.com – on this site before Rocket Loader:

Load time 1.5 seconds, faster than 90% of tested sites. Pretty good. Maybe I don’t need Rocket Loader after all.

With Rocket Loader:

Wow! All metrics are improved. Load is time less than half, at 580 milliseconds – faster than 95% of tested sites. Rocket Loader rocks! Very much worth the wait.

CloudFlare Speed Settings

miscellaneous CloudFlare speed settingsIn another post I cover a CloudFlare page rule for blazing site speed. This post discusses miscellaneous CloudFlare speed settings. CloudFlare, even at the free tier, offers a plethora of speed and security settings that seem daunting at first. Most of them work fine using the default setting, and I can adjust settings at my own pace as I am able to make time to learn and optimize.

Crypto

The first CloudFlare performance setting is Opportunistic Encryption, on the Crypto page.

CloudFlare speed settings

 

Opportunistic Encryption provides performance and security benefits over HTTP. I use HTTPS exclusively, so as far as I know Opportunistic Encryption does nothing for me. The default setting is ‘On’, and I leave it that way.

Speed

Auto Minify removes unnecessary characters like whitespace, lowering the amount of data that needs to be transferred to visitors and improving page load times.

I have to be cautious to minify only once. Since I use CloudFlare to minify, I must not also minify using a WP plugin. Multiple minifies break stuff.


Rocket Loader optimizes JavaScript resources.

Unfortunately Rocket Loader is in Beta (i.e. Buggy), and CloudFlare acknowledges “… not all scripts work with this feature.” Rocket Loader intermittently stops my sliders from sliding, or sometimes even loading. I use it only on slider-less sites. I am keeping an eye on it though, and will retry it when the Beta label vanishes.

Update: After seven years in Beta, CloudFlare announced the General Availability (GA, e.g. production operation) of Rocket Loader on June 1, 2018. In my initial brief testing it seems to not break sliders now, and provides a significant speed boost. I am turning it on for a trial run.

Caching

The Caching Level setting only goes up to Standard. For more aggressive caching I use a page rule for blazing site speed on relatively static sites like this one.


Browser Cache Expiration specifies how long cached resources will remain in the visitor’s browser cache.

Browser Cache Expiration: Respect Existing Headers

WordPress presumably does a good job of determining the optimal browser cache duration of various resources – e.g. longer for static resources, shorter for dynamic resources – so I don’t want CloudFlare to mess with this. I leave this setting at the default “Respect Existing Headers”.

Update: I changed the ‘Browser Cache Expiration’ setting to 1 month, to bump up my speed scores in services like Pingdom, GTmetrix and PageSpeed. Surprisingly, it seems to have bumped up my actual site speed a bit as well.

CloudFlare Security Settings

miscellaneous CloudFlare security settingsIn another post I cover CloudFlare page rules for login security. This post discusses miscellaneous CloudFlare security settings. CloudFlare, even at the free tier, offers a plethora of speed and security settings that seem daunting at first. Most of them work fine using the default setting, and I can adjust settings at my own pace as I am able to make time to learn and optimize.

DNS

On the CloudFlare DNS page, I follow CloudFlare’s advice for A (IPv4), AAAA (IPv6), and CNAME (alias) records:

A, AAAA, and CNAME records can have their traffic routed through the Cloudflare system … click the cloud next to each record to toggle Cloudflare on or off.

CloudFlare Security Settings: DNS

Among other advantages, this hides my IP address so that bad bots can’t as easily launch a denial of service attack.


Further down the CloudFlare DNS page, I find the DNSSEC setting.

DNSSEC

DNSSEC is a bit of a pain to set up, requiring configuration of a DNS record called a DS at my domain registrar. CloudFlare provides detailed instructions for popular registrars. If I turn this on – and I do – I have to remember to turn it off before I move to a new web host or otherwise change my IP address.

Crypto

The first setting on the CloudFlare Crypto page is SSL.

It gives me four choices – in order from worst to best: Off, Flexible, Full, and Full (strict). SSL provides security and SEO benefits. It is a bit of a process to set up requiring configuration in CloudFlare, WordPress, and my cPanel. I use Full (strict) whenever practical.


The next Crypto setting that I can change on the free tier is Always use HTTPS: “Redirect all requests with scheme “http” to “https”. This applies to all http requests to the zone.” HTTPS provides better security for user data in transit. In addition, HTTPS enables CloudFlare to use HTTP2 and SPDY, which speed up my site.

Always use HTTPS: On


Further down is the HSTS setting. I hesitated to enable HSTS but eventually took the plunge for my business sites.

According to CloudFlare, HSTS “… protects secure websites from downgrade attacks, SSL stripping, and cookie hijacking.” But there is a downside: “… once HSTS is turned on, your website must continue to have a valid HTTPS configuration conforming with the HSTS header to avoid making the website inaccessible to users.”


Another crypto setting is Transport Layer Security (TLS), a more secure cryptographic protocol compared to its predecessor, Secure Sockets Layer (SSL).

Downside? CloudFlare currently labels TLS as Beta, which in my experience sometimes translates as “buggy”.

Firewall

The first Firewall setting is Security Level. I can choose Essentially Off, Low, Medium, High, or I’m Under Attack. This is a trade off. The higher the setting the safer my site is, but more users will be challenged before being allowed access. ‘Medium’ strikes a balance between user-friendly and secure. I can use page rules to select the highest security level for logins and the WP admin area.

Security Level: Medium


Further down I find Access Rules. Here if I need to I can block a pesky abusive IP address, IP address range, or even an entire country, France maybe.

Caching

If my site is down, Always Online will allow users to see a limited, cached version of my site content.

The Always Online cache will usually include the one, two, or three most popular pages from my site. On these pages visitors see a message at the top of the page telling them that they are in offline browsing mode. On other pages visitors see an error page.

Scrape Shield

On the Scrape Shield tab, the first setting is Email Address Obfuscation.

According to CloudFlare …

Email harvesters and bots are roaming the Internet looking for email addresses to add to their spam lists. Cloudflare’s Email Address Obfuscation encrypts email addresses on your web pages. This means that email addresses are hidden from harvesters and bots, but still visible to human visitors.


Hotlink Protection prevents images stored on my site from being displayed on other sites, sucking up my bandwidth.

Caching Plugin

LiteSpeed cache logoI chose my web host carefully. My sites are hosted on a LiteSpeed web server, so I am able to use the remarkable free LiteSpeed Cache (LSC) plugin. LSC provides much more than just lightning-fast server-side caching. In also includes a suite of optimization tools such as: Database optimization; Image optimization – which seems to be equal to or better than the paid/premium versions of competing plugins; Connection to CloudFlare so I can put CF in development mode or purge the CF cache; and Miscellaneous settings like ‘Remove query strings from static resources’.

Using my two favorite website speed checkers, WebPageTest.org and GiftOfSpeed.com

  1. LSC Off | CF in Development Mode (baseline site)
  2. LSC On | CF in Development Mode (significant speed increase over baseline)
  3. LSC Off | CF Caching On (a significant speed increase over LSC)
  4. LSC On | CF Caching On (no significant speed change over CF alone)

A few observations:

  • On my relatively static sites like this one, I use a CloudFlare page rule for blazing site speed. On these sites I am not able to squeeze out any more speed by using a caching plugin – even an exceptional one like LSC. So why run LSC on these sites? Because of the other optimization features that LSC offers, and because it boosts site speed when CF is in development mode or doesn’t have a page cached for some reason.
  • On sites with dynamic content, I use CF with default cache settings. On those sites, I do get a nice increase in speed by using LSC in addition to CF.
  • Kinda funny how my Compress Images grade on WebPageTest jumped between A and B even though all tests used the same images. I guess my images must be borderline A- / B+.
  • Strait A’s on the final test. Yea me!

Many LSC features only work on sites hosted on LiteSpeed web server. For sites hosted on Apache, I like Comet Cache for its plug-and-play simplicity as well as performance. The very popular W3 Total Cache (W3TC) is another excellent choice.

CloudFlare page rule for blazing site speed

CloudFlare page rule for blazing site speedCloudFlare, even the free tier, improves my site speed and security – so much so that I use it for all my sites. The default settings boost site speed by global distributed caching of static content. Static content, by CloudFlare’s definition, excludes HTML. This makes sense for dynamic sites with frequent new posts and user comments. For my sites like this one, that have less frequent new posts and do not allow user comments or other dynamic content, I can dramatically increase site speed using a page rule. The free tier gives me three page rules, and I need the first two for login security. The third – and order is important, it needs to be after my login security rules – supercharges my site speed.

CloudFlare page rules for login security

*wppov.com/*
Cache Level: Cache Everything, Edge Cache TTL: a month

Kinda obvious but worth stating – replace “wppov.com” with your site URL. With this setting, HTML is globally cached along with ‘static’ content.

Example speed tests using tools.pingdom.com

1. Baseline site, CloudFlare paused – my web host is already pretty speedy, Faster than 64% of tested sites:

Site speed check baseline

2. CloudFlare using default cache settings – Faster than 88% of tested sites:

Speed test, CloudFlare default setttings

3. CloudFlare using blazing fast page rule – Faster than 99% of tested sites:

Site speed test blazing fast
For my relatively static sites I use the blazing fast page rule and no caching plugin. For my dynamic sites, I use the CloudFlare default cache settings pared with the excellent Comet Cache plugin.

Update: My host uses LiteSpeed web server. I switched from the excellent Comet Cache to the even more excellent – if hosted on LiteSpeed – LiteSpeed Cache plugin.

Site speed has many variables, some of which I can’t influence, and the variability is reflected in pingdom test results at different times. I don’t always hit 99%, but I am tickled when I do.