Cloudflare experiments

OK, I work for CloudFlare and I run this site.

Occasionally CloudFlare needs beta testers, and sometimes we need alpha testers (for highly experimental things we only enable on our own systems -- meaning there's only 3 LFGSS users who could possibly ever see them).

I've volunteered LFGSS to be used for testing a number of times, but because there is always the risk that we break something I am going to start announcing things in here.

Right now we are testing:

• HTTPS Everywhere
  
• Beacon - AdBlock status
  
• Beacon - Performance timings
  
  

HTTPS Everywhere finds images embedded from third-party sites using http:// links, and where possible (based on a very large set of rules) will change the link to use an alternate https:// link. i.e. if you embed an image from Flick, we'd rewrite the link to use one of their secure CDN endpoints. This will make you more secure without you doing anything.

Beacon - AdBlock status, means that I get to find out how many people use adblockers on here. I don't actually care, but it does offer some guidance as to just how bad my Google Analytics data is and how under-represented some browsers and devices are (the ones that adblock the most).

Beacon - Performance timings, means that I can get info on how well the page renders in different browsers and on different devices.

I usually only run experiments for a short while, though the HTTPS Everywhere one I'll want to run when it's out of beta.

The two beacon experiments have been disabled.

The HTTPS Everywhere experiment is working well and will be left enabled.

I've also reconfigured our firewall such that the following countries will see CAPTCHAs:

• China
  
• Vietnam
  
• Korea
  
• Ukraine
  
  

The following network is whitelisted, and will not see CAPTCHAs:

• Tor: The Onion Router
  

@Velocio someone is asking me why Cloudflare is blocking a URL.

Seems the URL in question includes encoded commas, ie. %2c and Cloudflare is blocking it because it's a potential inject attempt. "Restricted SQL Character Anomaly Detection Alert"

I've never used Cloudflare but I presume there is some way to exclude the URL from detection or detune the blocking so the URL(s) in question will pass?

Know anything about this kind of thing?

On LFGSS?

This is the SQL injection WAF rule by the sound of it.

Is this on one of your site's in which you have access to the Cloudflare dashboard? If so the firewall events can be viewed on the traffic tab and it will give the reason.

I've disabled that WAF rule on here, which is safe to do it you know your web application isn't vulnerable to SQL injection.

No, I'm actually doing some work at work for a change :P
It's someone else's shit but I get the fun questions don't I..

The site admin can disable the rules in the WAF control of the firewall tab.

The exact rule can be seen on the traffic tab which contains a list of all errors and WAF events triggered

Cheers, will get them to do that.

An experiment will shortly be enabled... it may impact non-EU visitors with an occasional fractionally slower connection.

The experiment is to restrict the private key for the TLS connection to only exist in the European data centres, and not elsewhere in the world.

It is a security experiment.

So, @Velocio Cloudflare dish out free certs? Think I might get 'em for my blog sites.
How do they handle validation/revalidation if I'm on cheapass shared linux hosting? I don't think I can use Let's Encrypt in this case. Presumably I use you as a DNS and you shuffle my traffic to my host, doing some SSL shenanigans in the process? How do you make money out of it?
Is this some kind of loss leader to get me to upgrade plans later on?

Universal SSL is the product.

Yes we give free certs. You cannot download those certs, we manage them for you and terminate the SSL traffic, rotate the certs, renew them, etc. It means we are a reverse proxy.

We then connect to your server, and yup... DNS is the key. When you enable Cloudflare for an A, AAAA or CNAME we will publish our IPs to the world, terminate the SSL, and then use the real IPs internally to reach you.

There are three modes for that last bit where Cloudflare talks to your server:

• Strict - You must have an SSL cert matching the host name on your origin
  
• Full - You can have any SSL cert on your origin, we only encrypt and we do not verify
  
• Flexible - We'll send the last bit over HTTP so we've publicly used HTTPS but privately go to you view HTTP
  
  

Flexible isn't great security, but sometimes with CNAMEs it's the best you can do (no control over the CNAME sites' ability to use TLS).

This is all free, and we still make money from it, it's not going away and isn't a loss leader... it's just a by-product of lowering the cost of doing something to fractions of a cent through automation and some clever tech.

We do most of our work stuff in a similar way within AWS using what you call 'Flexible'. Autoscaling IIS boxes accepting http traffic from various Cloudfronts (so close to Cloudflare it gets confusing), hosts CNAMEd to the Cloudfronts.

With my personal shit it's all on cheap shit hosting and I care not for its maintenance or even security for that matter, I just don't want the "Not Secure" shit popping up in Chrome so the quickest, easiest solution for me is what I want.

Might give it a whirl. You sure your servers can cope with the extra workload? Gotta be at least a hit a day from something that isn't a crawler...

An experiment has concluded.

50% of pages had their HTML minified, 50% didn't.

Over x0,000s of pages, we can conclusively say that minifying HTML saves on average 22ms of time per page viewed. That the time to minify (everything is dynamic) is not a cost worth worrying about as the pages do reach the browser 22ms sooner.

So I am currently running an Edge Workers experiment.
https://blog.cloudflare.com/cloudflare-workers-unleashed/

What I'm doing is attempting to solve the mixed content problem (displaying http images on a https page) whilst also increasing privacy and improving page load times.

The experiment goes like this:

• Find all images in comments
  
• Proxy them via an Edge Worker at the path /p/ on this site
  
  

The benefits:

• All images served from this domain
  
• HTTP2 means that the page will load faster
  
• The 3rd party images will be placed in my Cloudflare cache
  
• Fewer requests to third parties, and the ones that are sent aren't made by your browser
  
  

The bugs so far:

• It obscures the real URL of the image
  
• Amusingly it isn't working for http images, only https ones
  
  

I may reverse this, but for anyone that notices this is what is happening.

Example:

That image URL is https://blog.cloudflare.com/content/images/2018/03/workers-social.png

But if you right click the image and open it in a new tab you'll see it has an LFGSS link rather than a link to blog.cloudflare.com

And to keep the cache safe, only images will be proxied, nothing else. So no risk to JS and CSS domain isolation.

And measurements...

This page: https://www.lfgss.com/conversations/127097/?offset=59275

• With Edge Workers and image proxying = < 1 second load time on a good network
  
• Without Edge Workers and image proxying = > 5 second load time on a good network