Tag Archives: website

… or not migrating to Cloudflare

www.cloudflare.com

Several days ago I wrote a blogpost about my Cloudflare migration. I have done a bit more research since then and unfortunately, there are a few snags that could really hurt your website if you fail to consider the implications of the way in which Cloudflare and similar services work.

 Ronald Kunenborg | october 2016.

Main issues

There are two main issues, as described by an interesting blogpost on the blog of Sven Slootweg. Sven is the former administrator of AnonNews.org, and a security researcher. He was also suspected of being part of LulzSec, a very high profile group of hackers. I’ve read most of his posts now and I take them very seriously.

What he states is basically that

  • CloudFlare offers services that are very insecure by default [1];
  • CloudFlare has a business model that depends on them being the “Man in the Middle” with access to a lot of traffic [1];
  • CloudFlare does not mitigate DDOS attacks, unless they are quite small and only affect your webserver [1];
  • Some other minor issues, which I’ll skip. You should read the references for things like issues with Tor [2], SEO rankings [3], website impersonation [4], etcetera, to determine whether they apply to you.

The main problem with the security is that while the user may consider his or her experience to be encrypted (by SSL), the path from CloudFlare to the origin server is not. Now, consider an enduser in a country with an oppressive government who uses your CloudFlare-fronted website. CloudFlare may have a local server in that country. Suppose the user visits a page on the governments blacklist and leaves a nasty comment. Normally, SSL would encrypt all traffic and the government couldn’t intercept the traffic and look inside it. Well, not unless they were using a bit more resources than a simple scanner. But with CloudFlare the traffic between the CloudFlare local server and the webserver hosting the incriminating page, that traffic goes over the border *unencrypted*. Ouch. In some countries, your user will not survive this experience. And the user isn’t even warned: the browser tells the user that everything is fine. Even an SSL test (https://www.ssllabs.com/ssltest/analyze.html?d=www.grundsatzlich-it.nl) will say so. But it’s not. Oh, and if you have a front-end that accepts credit card information, that information will *also* travel the entire internet unencrypted. Not as dangerous as the first scenario, but probably not something you’d like to see as someone using a webstore.

Now, you can actually use the option to also encrypt the traffic between CloudFlare and your server. Let’s just say it’s not the default and requires a bit more expertise than just “point and click”. However, it’s not that difficult. That still leaves CloudFlare as the single point where a lot of web traffic goes through – entirely unencrypted. Sven Slootweg comments that:

This may not sound that bad – after all, they’re just a service provider, right? – but let’s put this in context for a moment. Currently, CloudFlare essentially controls 11% of the 10k biggest websites, over 8% of the 100k biggest websites (source), and almost 5% of sites on the entire web (source). According to their own numbers from 2012(!), they had more traffic than several of the most popular sites and services on earth combined, and almost half the traffic of Facebook. It has only grown since. And unlike every other backbone provider and mitigation provider, they can read your traffic in plaintext, TLS or not.

And finally, the DDOS issue. CloudFlare uses a method that mitigates against DDOS attacks by putting up a front page that asks you to enter a CAPTCHA. Apart from the fact it blocks bots, even backup bots, this doesn’t actually stop any big DDOS attack against something other than your web pages since it doesn’t block attacks by inspecting the packets but just relies on the CAPTCHA and stands in front of you. Dedicated DDOS mitigation works by making sure the packets never reach the real servers – CLoudFlare actually lets the packets reach their servers and relies on having “enough servers”. Given the new threat environment with DDOS attacks now going up to 600 Gbit/sec thanks to the “Internet of (apparently quite insecure) Things”, this may not be enough. Certainly, for the money you have to pay for the mitigation service it’s probably more effective to pay a dedicated DDOS protection service. Since CloudFlare is also responsible for hosting many of the DDOS-service provider websites, paying them for DDOS protection feels a bit like paying protection money to the Mafia.

The verdict

If you use CloudFlare to avoid buying a real certificate to secure your blog on “Human rights in Russia”, or run a webstore that accepts creditcard payments on your own webpages instead of using a payment processor page, you’re opening your users up to huge risks. And pleading innocent is less and less an option now that this information is out there. You can actually get better protection but CloudFlare will always be a Man in the Middle. Sven’s blog lists a number of alternatives if you can’t accept that.

However, for websites like mine, it’s not a big deal to accept less security. After all, before I migrated to CloudFlare the entire site was in cleartext. It’s slightly more secure now than it was, and thanks to this information I will make it more secure in the near future by using a better certificate.

If you move to CloudFlare like I did, you need to carefully weigh the pro’s and cons – better than I did, at least – before moving. But for a lot of blogs it may still be a very good option. If however your webshop or political blog is hosted by CloudFlare, you’d better do some checking before you post or pay. When in doubt, do not enter.

References

2016
[1] http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/
[2] https://blog.torproject.org/blog/trouble-cloudflare

2015
[3] https://salt.agency/blog/seo-rankings-cloudflare/

2014
[4] https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflare/
[5] https://scotthelme.co.uk/cloudflares-great-new-features-and-why-i-wont-use-them/

Server-test
[6] https://www.ssllabs.com/ssltest/analyze.html?d=www.grundsatzlich-it.nl

Integrating Twitter in WordPress

twitter large logo

Last year Twitter decided to change the way Twitter interacts with the rest of the world, by making it more difficult to integrate its twitter-streams with your own website. While you can get around this if you can deploy server-side software and go through the hassle of signing up for a developer key, a lot of folks run websites without being interested in having to program just to get their own tweets to display.

Twitter does have a solution, but this just dumps the stream on your site with the lay-out and styling of Twitter. While this is understandable from a branding and marketing point of view, it’s incredibly annoying to have your website look like a hash of different styles just because Twitter doesn’t like you changing the lay-out. So there are a lot of people looking for alternatives.

The best alternative I’ve found for my purpose is http://jasonmayes.com/projects/twitterApi/. Jason Mayes twitter API just takes the formatted twitter-feed, removes the formatting and provides the stream with normal tags to the page. Using standard CSS you can then style the stream and presto, you have a nice looking twitter feed.

How it works in WordPress is as follows:
– Download the software from http://jasonmayes.com/projects/twitterApi/
– Upload the javascript file “twitterFetcher_min.js” to your website. This could be as media but I chose to use FTP to upload it into a theme. As long as it’s on your website it’s okay though, the location is unimportant.
– Add a Text widget to the page where you want the tweets to show up.
– Include the following text in the widget:


<script src="/{path}/twitterFetcher_min.js"></script>
<div id="tweet-element">Tweets by Ronald Kunenborg</div>

<script>
var configProfile = {
"profile": {"screenName": '{yourtwittername}'},
"domId": 'tweet-element',
"maxTweets": 10,
"enableLinks": true,
"showUser": true,
"showTime": true,
"showImages": true
};
twitterFetcher.fetch(configProfile);
</script>

Replace “{yourtwittername}” with your own twitter name (of that of someone whose timeline you wish to show), and the {path} with the path of the uploaded javascript and you’re good to go. However, this looks pants. So we need to style it. In order to do that, include the following text in the widget before the script:
<style>
/*
* Tweet CSS - on Jason Mayes tweetgrabber (http://jasonmayes.com/projects/twitterApi/)
*/

div#tweet-element ul {
list-style: none;
}

div#tweet-element h2 {
clear:both;
}

div#tweet-element p {
font-size: 9pt;
margin: 0 0 0 0;
}

div#tweet-element ul li {
list-style:none;
overflow:hidden;
border-top:1px solid #dedede;
margin: 5px 0 10px 0;
padding: 0px;
}

div#tweet-element ul li:hover {
background-color:#f0f3fb;
}

/* tekst of tweet */
.tweet {
clear: left;
}

.user {
clear:left;
float:left;
}

.user a {
}

/* hide the @twittername, which is the 3rd span in the user class */
.user span:nth-child(3) {
display: none;
}

.user a > span {
margin-left:2px;
}

.user a > span {
display: table-cell;
vertical-align: middle;
margin: 5px;
padding: 5px;
}

.widget-text img,
.user a span img {
display: block;
float:left;
max-width: 40px;
margin: 2px 2px 2px 2px;
}

div#tweet-element p.timePosted {
clear: left;
font-style: italic;
}

div#tweet-element p.timePosted a {
color: #444;
}

.interact {
float:left;
margin-top:-7px;
width: 100%;
}

.interact a {
margin-left: 0px;
margin-right: 5px;
width: 30%;
}

.interact a.twitter_reply_icon {
float:left;
text-align: center;
}

.interact a.twitter_retweet_icon {
float:left;
text-align: center;
}

.interact a.twitter_fav_icon {
float:right;
text-align: center;
}

/* show media on front-page - hide it with display:none if you don't want to show media included by others. */
.media img {
max-width:100%;
}

#linkage {
position:fixed;
top:0px;
right:0px;
background-color:#3d3d3d;
color:#ffffff;
text-decoration:none;
padding:5px;
width:10%;
font-family:arial;
}
</style>

Make sure the <style> part is first in the Text widget.

Of course you can also put the style (without the <style> tags) in a stylesheet (.css) file, upload it and then refer to it, instead of pasting the stylesheet in the Text widget. In that case use the following command:

<link rel='stylesheet' id='twitter-css' href='/{path}/twitter-style.css' type='text/css' media='all' />

And please replace {path} with the desired path.

I hope this helps you as much as it helped me.

Migrating to CloudFlare

www.cloudflare.com

I recently added CloudFlare as cache in front of my website. Not only does it provide worldwide local caching of my website, it also improves security by adding in an easy manner all kinds of features you’d otherwise find hard to arrange. It’s still a hassle, but not as much as it used to be.

The standard CloudFlare plan is free. Yep. And you can’t beat the value. The following features are part of it:

  • Caching at a server that is local to your visitors, improving their browsing speeds. Pretty nice and worth the price all in and of itself.
  • Analytics in an easy dashboard. You can get this by incorporating Google Analytics on your pages, true, but here it’s already in the product. However, CloudFlare also has a nice button that allows you to add Google Analytics to all of your pages, if you really want it, without changing your website in any way.
  • Safe browsing over SSL for people visiting the CloudFlare cache, at no charge.
  • DNSSEC can be turned on, securing your DSN entries (DNS translates the name of your website into the IP-address you need to actually get there) against rogue DNS-servers that change the IP-address to their own sites, so they can intercept the traffic or just spoof your website and change pages around. Could be quite embarassing if you are a dissident or well-known political figure, or a bank.
  • A “web firewall” that tries to catch spambots and scrapers before they even reach your website. The more advanced options are paid, but the free option is pretty nice. It has, for instance, the option of asking suspect browsers to authenticate their “humanity” before allowed to access your site. This is enabled by default.
  • IPv6 to IPv4 translation. If you’re on a provider that does not provide IPv6 website hosting you should move ASAP anyway, but suppose you can’t? In that case you have the option of pretending to your rather outdated server that the request is actually an IPv4 type request. Could be useful.
  • An option called “Apps”. Apps are small features you can enable that are provided by 3rd parties. One of these for instance is “A Better Browser” which warns users of older browsers that they should upgrade. Once again, no code on your website changes and you can turn it on and off quite easily. Other apps provide analytics, more security and monitoring but almost all of these are paid options.
  • Email-address obfuscation. For the truly paranoid, you can turn all your emailadresses on the site into addresses that cannot be harvested by the scrapers they said they would stop. I don’t bother with this, but feel free.
  • Hotlink protection. This is pretty nifty if you have a site with a lot of images, and people blogging about them link directly to your site from their article. That means their pageviews count against your bandwidth. With this option you can prevent those requests from being served.

These options are all easily accessible through a set of buttons as displayed here: cloudflare-buttons

Pretty nice all by itself. But I’ll discuss the setup and two main features in more detail.

Setup

The setup is easy. Just sign up and add your website. The main thing you need to get working is the nameservers. If you cannot change the nameservers for your website, things will get really tough because that is how CloudFlare works. If you cannot change them, contact your provider. If your provider does not allow nameserver changes, move away to another that does support it. Otherwise none of the newer features of the internet will work unless your provider agrees to provide them to you. That won’t be cheap.

After you get the nameservers changed, you have to log out and wait a few hours. By then the change will have been recognized by CloudFlare, and now you can actually use its features. The two most useful features are of course caching and encryption, which I explain below in a bit more detail.

Caching

The caching features of the CloudFlare platform help you in the sense that small DDOS attacks won’t bring down your website or hurt your direct provider. Big ones will mean you have to pay up (a lot), but it’s better than your direct provider shutting down your website for a minor DDOS assault, right? They also have the option named “always online(tm)” that provides a cached copy of your website, if it is offline on your own side. Note that this only goes for the popular (cached) pages but these are the most important ones anyway. Of course, caching can be disabled (temporarily) by turning on “development mode”.

Encryption

Encrypting the website gives you the option to have browsers come in over SSL. And this is very interesting because browsers are now signalling by default that your site is untrusted if it is not protected by SSL. The CloudFlare option provides SSL for your website from visitor browser to CloudFlare, but if you don’t add something more, it will still be unencrypted between CloudFlare and your original website.

If you trust the channel between your website and CloudFlare, this is still pretty safe. For most websites it’s a major improvement because they go from no SSL at all, to SSL between visitor and cache. But if you want more it’s pretty easy. Most website hosting companies provide you with the ability to place a self-signed certificate on your website, and CloudFLare can be set to acknowledge that certificate. You could also set CloudFlare to acknowledge only certificates signed by a trusted authority, increasing the security of your channel either further, or reducing it to zero, depending on who you trusted as certificate provider. In my case, I go with the self-signed certificate.

DNSSEC is however a bit more involved. I was unable to get this working because my hosting provider does not provide me with the ability to add a “DS” record to the DNS-server. I’m still looking into it. HOWEVER… my provider has automatic DNSSEC as long as I use their nameservers… This effectively means that I am going to have to do without DNSSEC *or* CloudFlare. Given the risks involved (minor) I’m going to stick with CloudFlare for a while, but I may be returning to the provider I have. I would really like them to have this though.

Summary

All in all, I can highly recommend CloudFlare. It’s free, it’s easy and provides immediate benefits for most websites. If you’re big enough to already have most of this it may be less interesting, but for 90% of the internet this is a step forward.

Update

Update 09-okt-2016: I’ve written a new article about why you should be careful when moving to CloudFlare, as it is not quite as suitable as I thought for websites that require actual security and encryption.