Optimizing TLS over TCP to reduce latency
The layered nature of the Internet (HTTP on top of some reliable transport (e.g. TCP), TCP on top of some datagram layer (e.g. IP), IP on top of some link (e.g. Ethernet)) has been very important in its development. Different link layers have come and gone over time (any readers still using 802.5?) and this flexibility also means that a connection from your web browser might traverse your home network over WiFi, then down a DSL line, across fiber and finally be delivered over Ethernet to the web server. Each layer is blissfully unaware of the implementation of the layer below it.
But there are some disadvantages to this model. In the case of TLS (the most common standard used for sending encrypted data across in the Internet and the protocol your browser uses with visiting an https:// web site) the layering of TLS on top of TCP can cause delays to the delivery of a web page.
That’s because TLS divides the data being transmitted into records of a fixed (maximum) size and then hands those records to TCP for transmission. TCP promptly divides those records up into segments which are then transmitted. Ultimately, Continue reading
Perth, Australia: 80th Data Center
CloudFlare is excited to announce the launch of our newest data center in Perth, Australia. This expands the breadth of our global network to span 80 unique cities across 41 countries, and is our fourth data center in the Oceania region, joining existing data centers in Sydney, Melbourne and Auckland.
Western Australia
Perth is in a fascinating location. Home to sunny beaches and the highest number of self-made millionaires in the world, it is actually geographically closer to Singapore than to Sydney (though closer to Sydney in a “networking” sense, as determined by BGP routing).
Visitors to millions of websites across Western Australia served locally can now experience a faster and safer Internet - and ISPs can reach us at the Western Australia Internet Exchange (WA-IX), one of 119 internet exchanges that we openly peer at.
Latency in milliseconds from end user (Perth) to CloudFlare. Source: Cedexis
Missing letters?
Helping build CloudFlare’s network provides our team members with the opportunity to not just speed up the Internet, but also improve our sense of geography. Visitors to our offices in San Francisco, London and Singapore can get a sneak peek at our fast-changing map (with live and upcoming dots). Perth Continue reading
Open Sourcing CloudFlare’s UI Framework
Late last year, the CloudFlare UI team made a huge decision: to change JavaScript frameworks from Backbone & Marionette to React & Redux.
We’ve been one of the single biggest Backbone+Marionette apps on the web for a while now, and the decision to move was not taken lightly. On our team we have a former core team member of the Marionette team (myself), and the author of several popular Backbone projects: Backgrid and Backbone Paginator.
In the spirit of the open web, we want to share more about what we’re doing. This starts by open sourcing the UI framework that we have spent the last few months building.
Introducing cf-ui
While moving to React, we’ve taken our existing Backbone UI framework and rebuilt it from scratch on top of React. This includes over 50 packages that include dozens of components, utilities, test helpers, and more.
Examples: https://cloudflare.github.io/cf-ui
GitHub: https://github.com/cloudflare/cf-ui
We’re not open sourcing cf-ui because we think our buttons are any better than anyone else’s buttons, but because it’s an opportunity to share some of the technical decisions that we’ve made while building out a massive React application. The hope is that this will be Continue reading
Supporting the transition to IPv6-only networking services for iOS
Early last month Apple announced that all apps submitted to the Apple Store June 1 forward would need to support IPv6-only networking as they transition to IPv6-only network services in iOS 9. Apple reports that “Most apps will not require any changes”, as these existing apps support IPv6 through Apple's NSURLSession and CFNetwork APIs.
Our goal with IPv6, and any other emerging networking technology, is to make it ridiculously easy for our customers to make the transition. Over 2 years ago, we published Eliminating the last reasons to not enable IPv6 in celebration of World IPv6 Day. CloudFlare has been offering full IPv6 support as well as our IPv6-to-IPv4 gateway to all of our customers since 2012.
Why is the transition happening?
IPv4 represents a technical limitation, a hard stop to the number of devices that can access the Internet. When the Internet Protocol (IP) was first introduced by Vint Cerf and Bob Kahn in the late 1970s, Internet Protocol Version 4 (IPv4) used a 32-bit (four-byte) number, allowing about 4 billion unique addresses. At the time, IPv4 seemed more than sufficient to power the World Wide Web. On January 31, 2011, the top-level pool of Internet Assigned Numbers Authority Continue reading
The Sleepy User Agent
From time to time a customer writes in and asks about certain requests that have been blocked by the CloudFlare WAF. Recently, a customer couldn’t understand why it appeared that some simple GET requests for their homepage were listed as blocked in WAF analytics.
A sample request looked liked this:
GET / HTTP/1.1
Host: www.example.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (compatible; MSIE 11.0; Windows NT 6.1; Win64; x64; Trident/5.0)'+(select*from(select(sleep(20)))a)+'
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,fr;q=0.6
As I said, a simple request for the homepage of the web site, which at first glance doesn’t look suspicious at all. Unless your take a look at the User-Agent header (its value is the string that identifies the browser being used):
Mozilla/5.0 (compatible; MSIE 11.0; Windows NT 6.1; Win64; x64; Trident/5.0)'+(select*from(select(sleep(20)))a)+
The start looks reasonable (it’s apparently Microsoft Internet Explorer 11) but the agent strings ends with '+(select*from(select(sleep(20)))a)+. The attacker is attempting a SQL injection inside the User-Agent value.
It’s common to see SQL injection in URIs and form parameters, but here the attacker has hidden the SQL query select * from (select(sleep(20))) inside the User-Agent Continue reading
Using HTTP/2 Server Push with PHP
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 readingOpen sourcing our NGINX HTTP/2 + SPDY code
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
How we built Origin CA: Web Crypto
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.
Certificate authorities don’t need your private key
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
python-cloudflare
Using the CloudFlare API via Python
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.
An example
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 readingSunsetting API v1 In Favor Of CloudFlare’s Current Client API: API v4
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.
What will happen after the sunset?
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.”
What can you do with API v4?
CloudFlare uses Continue reading
Inside ImageTragick: The Real Payloads Being Used to Hack Websites
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
First Bay Area OpenResty Meetup
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.
abode.io by Dragos Dascalita of Adobe
The slides are here.
KONG by Marco Palladino from Mashape
The slides can be found here
What's new in OpenResty for 2016 by Yichun Zhang of CloudFlare
Yichun's slides are here
If you are interested in being present at the next OpenResty Meetup by sure to follow the meetup itself.
Everybody gets WebSockets
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.
What are WebSockets?
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
Dan Kaminsky Will Be Taking Your Questions At Our DNS Meetup Next Week In San Francisco
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
Yet Another Padding Oracle in OpenSSL CBC Ciphersuites
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.
TLS, CBC, and Mac-then-Encrypt
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
Introducing CloudFlare Origin CA
Free and performant encryption to the origin for CloudFlare customers
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
Stronger protection and more control over security settings with CloudFlare’s new cPanel plugin
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.
New features offering stronger protection
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
Bangkok, Thailand: CloudFlare’s 79th Data Center
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 expansion
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.
Online, in a massively mobile way
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
Lizard Squad Ransom Threats: New Name, Same Faux Armada Collective M.O.
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
Announcing Support for HTTP/2 Server Push
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
.jpg){kind=link}
Incremental Improvements On SPDY
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.
Pushing Ahead
Today, we’re happy to announce HTTP/2 Server Push support for all of our customers. Server Push enables websites and Continue reading