Two weeks ago CloudFlare announced that it was supporting HTTP/2 Server Push for all our customers. By simply adding a Link
header to an HTTP response specifying preload
CloudFlare would automatically push items to web browsers that support Server Push.
To illustrate how easy this is I create a small PHP page that uses the PHP header
function to insert appropriate Link
headers to push images to the web browser via CloudFlare. The web page looks like this when loaded:
There are two images loaded from the same server both of which are pushed if the web browser supports Server Push. This is achieved by inserting two Link
headers in the HTTP response. The response looks like:
HTTP/1.1 200 OK
Server: nginx/1.9.15
Date: Fri, 13 May 2016 10:52:13 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Link: </images/drucken.jpg>; rel=preload; as=image
Link: </images/empire.jpg>; rel=preload; as=image
At the bottom are the two Link
headers corresponding to the two images on the page with the rel=preload
directive as specified in W3C preload draft.
The complete code can be found in this gist but the core of the code looks like this:
<?php
function pushImage($uri) {
header("Link: <{$uri}>; rel=preload; Continue reading
In December, we released HTTP/2 support for all customers and on April 28 we released HTTP/2 Server Push support as well.
The release of HTTP/2 by CloudFlare had a huge impact on the number of sites supporting and using the protocol. Today, 50% of sites that use HTTP/2 are served via CloudFlare.
When we released HTTP/2 support we decided not to deprecate SPDY immediately because it was still in widespread use and we promised to open source our modifications to NGINX as it was not possible to support both SPDY and HTTP/2 together with the standard release of NGINX.
We've extracted our changes and they are available as a patch here. This patch should build cleanly against NGINX 1.9.7.
The patch means that NGINX can be built with both --with-http_v2_module
and --with-http_spdy_module
. And it will accept both the spdy
and http2
keywords to the listen
directive.
To configure both HTTP/2 and SPDY in NGINX you'll need to run:
./configure --with-http_spdy_module --with-http_v2_module --with-http_ssl_module
Note that you need SSL support for both SPDY and HTTP/2.
Then it will be possible to configure an NGINX server to support both HTTP/2 and SPDY on Continue reading
At CloudFlare we strive to combine features that are simple, secure, and backed by solid technology. The Origin CA is a great example of this. You no longer need to go to a third-party certificate authority to protect the connection between CloudFlare and your origin server. You can now get a certificate to encrypt the connection between CloudFlare and the origin from CloudFlare directly with one click.
In certificate-based security, the most important thing is protecting the private key. We designed the one-click certificate dashboard to maximize private key security. Your private key is created client-side in your browser using the W3C’s Web Crypto API and only the public key is sent to CloudFlare’s servers. This security feature turned out to be a big win for usability as well as an interesting technical challenge.
Most certificate authorities (CAs) specialize in one type of transaction: they take a certificate signing request (CSR) (and sometimes a fee) and in return they provide a signed certificate. A CSR is a way to tell a certificate authority what your public key is and to prove you have control of the corresponding private key. The certificate authority doesn’t Continue reading
Very early on in the company’s history we decided that everything that CloudFlare does on behalf of its customer-base should be controllable via an API. In fact, when you login to the CloudFlare control panel, you’re really just making API calls to our backend services. Over time that API has matured and improved. We are now on v4 of that API.
The current CloudFlare API is documented here and it’s used by both the CloudFlare control panel and directly by umpteen customers every minute of every day. The new API is designed with a clean naming structure and consistent data representation for data. It’s also extensible.
This blog entry introduces python-cloudflare, a Python wrapper providing full access to the CloudFlare v4 API.
Let’s get right into the thick-of-it with the simplest coding example available to show python-cloudflare in action. This example lists all your domains (zones) and also checks some basic features for each zone.
#!/usr/bin/env python
import CloudFlare
def main():
cf = CloudFlare.CloudFlare()
zones = cf.zones.get(params={'per_page':50})
for zone in zones:
zone_name = zone['name']
zone_id = zone['id']
settings_ipv6 = cf.zones.settings.ipv6.get(zone_id)
ipv6_on = settings_ipv6['value']
Continue reading
Today we’re announcing the sunsetting of CloudFlare’s first client API, API v1. Starting November 9th, 2016 at noon Pacific Time (20:00 UTC), CloudFlare will no longer be supporting API v1.
While it is bittersweet to let our first API from CloudFlare’s early days go, we are so excited to show you all of the great things about our latest API: API v4. We’re confident that once you get started using it, you’ll see how easy API v4 makes managing your CloudFlare settings.
(For those of you who are curious where CloudFlare’s API v2 and v3 went, they ran away with IPv5 and PHP 6.)
If you are using API v1 and need to migrate to API v4, we’ve written extensive migration docs here for you to follow. They contain every API call from v1 and their equivalent in v4 side by side.
After CloudFlare discontinues support for API v1 in November 2016, any calls to API v1 will return the HTTP status code 410 Gone with the message: “This API has been deprecated in favor of API v4, available at https://api.cloudflare.com.”
CloudFlare uses Continue reading
Last week multiple vulnerabilities were made public in the popular image manipulation software, ImageMagick. These were quickly named ImageTragick. Although a vulnerability in image manipulation software might not seem like a problem for web site owners it is in fact a genuine security concern.
CloudFlare quickly rolled out a WAF rule to protect our customers from this vulnerability. It was automatically deployed for all customers with the WAF enabled. We know that it takes time for customers to upgrade their web server software and so the WAF protects them in the interim.
Many websites allow users to upload images and the websites themselves often manipulate these images using software like ImageMagick. For example, if you upload a picture of yourself to use as an avatar, it will very likely be resized by the website. ImageMagick is very popular and there are plugins that make it easy to use with PHP, Ruby, Node.js and other languages so it is common for websites to use it for image resizing or cropping.
Unfortunately, researchers discovered that it was possible to execute arbitrary code (CVE-2016-3714) by hiding it inside image files that a user uploads. That means an attacker can make Continue reading
On March 9, 章亦春, known to most of us as agentzh, organized the first Bay Area OpenResty Meetup at CloudFlare's San Francisco office.
CloudFlare is a big user of Lua, LuaJIT, NGINX and OpenResty and happy to be able to sponsor Yichun's work on this fast, flexible platform.
The slides and videos from the meetup are now available for viewing by people who were unable to be there in person.
The slides are here.
The slides can be found here
Yichun's slides are here
If you are interested in being present at the next OpenResty Meetup by sure to follow the meetup itself.
Two summers ago, with a seemed-big-at-the-time network of 28 datacenters, not long after introducing Medellin, CloudFlare introduced support for WebSockets, initially for our Enterprise customers.
CC BY 2.0 image by Marcin Wichary
Today, with our network nearing 80 global locations, we're pleased to announce support for WebSockets for all our customers, including Enterprise, Business, Pro, and Free, with resources allocated by plan level.
If you don't want to read RFC 6455, then this short paragraph from our previous blog post explains:
The WebSocket protocol is a distinct TCP-based protocol, however, it’s initiated by an HTTP request which is then "upgraded" to create a persistent connection between the browser and the server. A WebSocket connection is bidirectional: the server can send data to the browser without the browser having to explicitly ask for it. This makes things like multiplayer games, chat, and other services that require real-time exchange of information possible over a standard web protocol
There's a lot more technical history in that post covering how we modified NGINX to support a huge number of connections through port reuse. But the bottom line is that WebSockets are a vital technology for web sites that Continue reading
Our last DNS meetup was a packed house with Paul Mockapetris, the original inventor of DNS. We learned why DNS answers have a question count but always only one question, why underscores aren’t allowed in domain names, and the history of how DNS came to be.
Our next meetup is with the infamous Dan Kaminsky –– there’s even a DNS attack named after him, the Kaminsky attack. Dan is known for his work finding a core flaw in the Internet, and then leading the charge to repair it. He is an invited expert to the W3C, the guiding organization for the Web, and co-founded the cybersecurity firm White Ops. He is even one of the seven "key shareholders" able to restore the Internet's Domain Name System if necessary.
We’ll cover how Dan discovered the Kaminsky attack, the future of DNS and privacy, how to secure email with DNS, and what are the policy implications of governments allowing DNS blocking. It’s going to be a really great event - we can’t wait to see you there. The meetup is at Gandi’s headquarters: 121 2nd Street, San Francisco at 6PM PST on Tuesday, May 10th, 2016. To claim your spot, Continue reading
Yesterday a new vulnerability has been announced in OpenSSL/LibreSSL. A padding oracle in CBC mode decryption, to be precise. Just like Lucky13. Actually, it’s in the code that fixes Lucky13.
It was found by Juraj Somorovsky using a tool he developed called TLS-Attacker. Like in the “old days”, it has no name except CVE-2016-2107. (I call it LuckyNegative201)
It’s a wonderful example of a padding oracle in constant time code, so we’ll dive deep into it. But first, two quick background paragraphs. If you already know all about Lucky13 and how it's mitigated in OpenSSL jump to "Off by 20" for the hot and new.
If, before reading, you want to check that your server is safe, you can do it with this one-click online test.
Very long story short, the CBC cipher suites in TLS have a design flaw: they first compute the HMAC of the plaintext, then encrypt plaintext || HMAC || padding || padding length
using CBC mode. The receiving end is then left with the uncomfortable task of decrypting the message and checking HMAC and padding without revealing the padding length in any way. If they do, we call Continue reading
In the fall of 2014 CloudFlare launched Universal SSL and doubled the number of sites on the Internet accessible via HTTPS. In just a few days we issued certificates protecting millions of our customers’ domains and became the easiest way to secure your website with SSL/TLS.
At the time, we "strongly recommend[ed] that site owners install a certificate on their web servers so we can encrypt traffic to the origin." This recommendation was followed by a blog post describing two readily-available options for doing so—creating a self-signed certificate and purchasing a publicly trusted certificate—and a third, still-in-beta option: using our private CA. Even though out-of-pocket costs of acquiring public CA certificates have since fallen to $0 since that post, we have continued to receive requests from our customers for an even easier (and more performant) option.
Operating a public certificate authority is difficult because you don't directly control either endpoint of the HTTPS connection (browser or web server). As a result, public CAs are limited both in their ability to issue certificates optimized for inter-server communication, as well as in their ability to revoke certificates if they are compromised. Continue reading
CloudFlare has released a new version of our plugin for cPanel with two new features and more control over the security settings of your website.
The new plugin (v6.0) uses the latest cPanel PHP-based APIs, and is completely re-architected to make adding new features easier, allowing for more frequent updates.
We’ve always focused on making integration with CloudFlare as easy as possible. As a customer of one of our hosting partners you can quickly start using CloudFlare features and routing your website traffic through CloudFlare’s global network by clicking on the CloudFlare icon from your cPanel interface.
Add domains to CloudFlare through Full Zone Provisioning. A huge benefit of Full Zone Provisioning is that it enables all of CloudFlare’s protection, including DDoS mitigation, at the root domain (yourdomain.com) as well the subdomain (www.yourdomain.com).
If your website is experiencing Layer 7 DDoS attacks, you can now click on the 'Enable “I'm under attack" mode ’ button to filter out malicious traffic while allowing legitimate visitors to reach your site. When this is in place, visitors will receive a temporary page for about five seconds while we analyze the traffic to make Continue reading
CloudFlare just turned up our newest data center in Bangkok, the capital of Thailand and a very popular destination with travelers in Southeast Asia. This expands our network to span 32 cities across Asia, and 79 cities globally.
Thailand, with a population of 65 million, is the fourth largest country in Southeast Asia. As the central interconnection point for all Internet communications within the country, Bangkok was the natural choice for our newest deployment.
Southeast Asia commonly includes the countries of Brunei, Cambodia, East Timor, Indonesia, Laos, Malaysia, Myanmar, Philippines, Singapore, Thailand and Vietnam.
Following Singapore and then Kuala Lumpur, Malaysia, Bangkok is the third location for CloudFlare in the region. We have more deployments in the works in the region; however our next data center beginning with the letter 'B' is roughly 6,000 miles away.
While only 40% of the population is online, Thailand has become a majority-mobile country very quickly, with 70% of its users accessing the Internet predominantly via smartphones. Through CloudFlare’s implementation of encryption using the ChaCha20-Poly1305 cipher suites, Continue reading
CloudFlare recently wrote about the group of cyber criminals claiming to be be the "Armada Collective." In that article, we stressed that this group had not followed through on any of the ransom threats they had made. Quite simply, this copycat group of cyber criminals had not actually carried out a single DDoS attack—they were only trying to make easy money through fear by using the name of the original “Armada Collective” group from late 2015.
Since we published that article earlier this week, this copycat group claiming to be "Armada Collective" has stopped sending ransom threats to website owners. Extorting companies proves to be challenging when the group’s email actively encourages target companies to the search for the phrase “Armada Collective” on Google. The first search result for this phrase now returns CloudFlare’s article outing this group as a fraud.
Beginning late Thursday evening (Pacific Standard Time) several CloudFlare customers began to receive threatening emails from a "new" group calling itself the “Lizard Squad”. These emails have a similar modus operandi to the previous ransom emails. This group was threatening DDoS attacks unless a ransom amount was paid to a Bitcoin address before a deadline. Based on discussions Continue reading
Last November, we rolled out HTTP/2 support for all our customers. At the time, HTTP/2 was not in wide use, but more than 88k of the Alexa 2 million websites are now HTTP/2-enabled. Today, more than 70% of sites that use HTTP/2 are served via CloudFlare.
CC BY 2.0 image by Roger Price
HTTP/2’s main benefit is multiplexing, which allows multiple HTTP requests to share a single TCP connection. This has a huge impact on performance compared to HTTP/1.1, but it’s nothing new—SPDY has been multiplexing TCP connections since at least 2012.
Some of the most important aspects of HTTP/2 have yet to be implemented by major web servers or edge networks. The real promise of HTTP/2 comes from brand new features like Header Compression and Server Push. Since February, we’ve been quietly testing and deploying HTTP/2 Header Compression, which resulted in an average 30% reduction in header size for all of our clients using HTTP/2. That's awesome. However, the real opportunity for a quantum leap in web performance comes from Server Push.
Today, we’re happy to announce HTTP/2 Server Push support for all of our customers. Server Push enables websites and Continue reading
We're big fans of HTTP/2 at CloudFlare. Our customers make up the majority of HTTP/2 enabled domains today. HTTP/2 is a key part of the modern web, and its growth and adoption is changing how websites and applications are built.
On Thursday April 28, 2016, our friends at CatchPoint are hosting a live AMA (Ask Me Anything) with experts from CloudFlare, Akamai, and Google answering questions in real time about the protocol's features, adoption, and future.
When: Thursday April 28, 2016 from 2pm-3pm Eastern Time (1600-1700 UTC)
How: Ask questions ahead of time (and vote on questions). Join in real-time on Thursday.
Who: CloudFlare's own Suzanne Aldrich will join Ilya Grigorik from Google, Tim Kadlec from Akamai, and Andrew Smirnov from Catchpoint.
Need the basics on HTTP/2 ahead of time? Visit the CloudFlare HTTP/2 website.
Go native vendoring (a.k.a. GO15VENDOREXPERIMENT) allows you to freeze dependencies by putting them in a vendor
folder in your project. The compiler will then look there before searching the GOPATH.
The only annoyance compared to using a per-project GOPATH, which is what we used to do, is that you might forget to vendor a package that you have in your GOPATH. The program will build for you, but it won't for anyone else. Back to the WFM times!
I decided I wanted something, a tool, to check that all my (non-stdlib) dependencies were vendored.
At first I thought of using go list
, which Dave Cheney appropriately called a swiss army knife, but while it can show the entire recursive dependency tree (format .Deps
), there's no way to know from the templating engine if a dependency is in the standard library.
We could just pass each output back into go list
to check for .Standard
, but I thought this would be a good occasion to build a very simple static analysis tool. Go's simplicity and libraries make it a very easy task, as you will see.
We use golang.org/x/tools/go/loader
to Continue reading
Здоровенькі були! CloudFlare just turned up our newest datacenter in Kiev, the capital and largest city of Ukraine.
Kiev is an old city with more than 1,000 years of history. It was the capital of Kievan Rus’, an ancient country which is considered to be the ancestor of modern Ukraine, Belarus and Russia. If you visit the city by plane, you may be almost blinded by the shining golden domes of numerous old churches and cathedrals - and once there, be sure to try the famous Ukrainian beet soup, “Borscht”. CloudFlare decided to contribute to the long history of Kiev with our 22nd data center in Europe, and our 78th data center globally.
Frankfurt is arguably the biggest point of interconnection in the world, and is home to Deutscher Commercial Internet Exchange (DE-CIX) which plays an absolutely critical role and sees close to 5Tbps in traffic. While this is great if you live near Frankfurt, it is also where most traffic is exchanged for other parts of Germany, large parts of Europe (think Austria, Bulgaria, Czech Republic, Denmark, Estonia, Finland, Greece, Hungary, Italy, Kazakhstan, Lithuania, Montenegro, Norway, Poland, Romania, Serbia, Turkey, Ukraine, etc.), and even countries such Continue reading
Beginning in March 2016, we began hearing reports of a gang of cybercriminals once again calling themselves the Armada Collective. The calling card of the gang was an extortion email sent to a wide variety of online businesses threatening to launch DDoS attacks if they weren't paid in Bitcoin.
From The Wizard of Oz (1939)
We heard from more than 100 existing and prospective CloudFlare customers who had received the Armada Collective's emailed threats. We've also compared notes with other DDoS mitigation vendors with customers that had received similar threats.
Our conclusion was a bit of a surprise: we've been unable to find a single incident where the current incarnation of the Armada Collective has actually launched a DDoS attack. In fact, because the extortion emails reuse Bitcoin addresses, there's no way the Armada Collective can tell who has paid and who has not. In spite of that, the cybercrooks have collected hundreds of thousands of dollars in extortion payments.
The extortion emails sent by the Armada Collective have been remarkably consistent over the last two months. Here's an example:
Today we're releasing a whole suite of upgrades to page rules: API support, additional settings, pausing a page rule and a mobile-friendly design. Page Rules is the technology that allows you to configure your CloudFlare settings on a per-URL basis. It's often our most powerful feature, enabling CloudFlare domain owners to customize CloudFlare's functionality to exactly match their application's needs.
Page Rules are now fully programmable via API.
$ curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_TAG}/pagerules"
-H "X-Auth-Email: [email protected]"
-H "X-Auth-Key: 000000000000"
-H "Content-Type: application/json"
--data '{
"targets":[{
"target":"url",
"constraint":{
"operator":"matches",
"value":"*example.com/images/*"
}
}],
"actions":[{
"id":"always_online",
"value":"on"
}],
"priority":1,
"status":"active"
}'
Starting today, you can script the creation and modification of page rules. You can integrate page rules into your deployment process to bypass caching on every new API endpoint you ship, or to automatically sync your page rules across your domains on CloudFlare. Check out the page rules API docs and get started today. We can't wait to see what automations you build.
Instead of the short list of settings you could previously toggle, we've added menus with almost every Continue reading