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
Over the last few years, the IETF community has been focused on improving and expanding the use of the technical foundations for Internet security. Part of that work has been updating and deploying protocols such as Transport Layer Security (TLS), with the first draft of the latest version of TLS, TLS 1.3, published a bit more than two years ago on 17 April 2014. Since then, work on TLS 1.3 has continued with expert review and initial implementations aimed at providing a solid base for broad deployment of improved security on the global Internet.
CC BY 2.0 image by Marie-Claire Camp
In February of this year, the Internet Society hosted the TRON (TLS 1.3 Ready Or Not) workshop. The main goal of TRON was to gather feedback from developers and academics about the security of TLS 1.3. The conclusion of the workshop was that TLS 1.3 was, unfortunately, not ready yet.
One of the reasons it was deemed not yet ready was that there needed to be more real-world testing of independently written implementations. There were some implementations of the core protocol, but nobody had put together a full browser-to-server test. And some Continue reading
Today we're launching two new features and a brand new dashboard and API for Virtual DNS. Virtual DNS is CloudFlare’s DNS proxy that sits in front of some of the largest hosting providers in the world, shielding their DNS infrastructure from attacks and providing them with the DNS performance benefits of CloudFlare's network and caching.
It's been a year since we launched Virtual DNS, and the service has expanded a lot since then. Virtual DNS now answers 7 billion DNS queries a day, 4.6 billion of which are served from our cache, saving our Virtual DNS customers a collective 65% of their bandwidth. Beyond the bandwidth savings, Virtual DNS also protected its customers from a large vulnerability in BIND when it was discovered in August.
Virtual DNS is different from CloudFlare’s core authoritative DNS service, which comes included in CloudFlare’s standard plans. In authoritative DNS, CloudFlare hosts DNS records for a zone on its own infrastructure. In Virtual DNS, the customer hosts all of the DNS records for all of their zones, and CloudFlare serves as a front end proxy to them.
The new Virtual DNS dashboard makes it fast and easy Continue reading
Almost a year ago, we announced that we were going to stop answering DNS ANY queries. We were prompted by a number of factors:
The lack of legitimate ANY use.
The abundance of malicious ANY use.
The constant use of ANY queries in large DNS amplification DDoS attacks.
Additionally, we were about to launch Universal DNSSEC, and we could foresee the high cost of assembling ANY answers and providing DNSSEC-on-the-fly for those answers, especially when most of the time, those ANY answers were for malicious, illegitimate, clients.
Although we usually make a tremendous effort to maintain backwards compatibility across Internet protocols (recently, for example, continuing to support SHA-1-based SSL certificates), it was clear to us that the DNS ANY query was something that was better removed from the Internet than maintained for general use.
Our proposal at the time was to return an ERROR code to the querier telling them that ANY was not supported, and this sparked a robust discussion in the DNS protocol community. In this blog post, we’ll cover what has happened and what our final plan is.
Just before we published our blog a popular software started using ANY queries, to get all address Continue reading
We are excited to announce the launch of our Taipei data center, which is our 28th data center in Asia, and our 77th data center globally. Millions of websites which were previously served from Hong Kong are now served locally from Taipei.
我們高興地宣布CloudFlare的的台北機房建置完成。這是我們在亞洲的第二十八個,在全球的第七十七個數據中心。從現在起台灣的網民可以直接從CloudFlare在台北的節點訪問數以百萬計的網站,不再繞道到香港。
Taipei, home to many renowned tech companies, is famous not only for its vibrant night markets, but also for its warm and welcoming people. From soup dumplings to computer peripherals to Kangsi Coming, its contribution to the world is enormous.
科技重鎮台北,不單擁用充滿活力的夜市,台北人的熱情而友善的人情味也是舉世聞名的。從小籠包、電腦周邊零件到康熙來了,台北對世界的貢獻碩大無朋。
Taipei has one of the fastest Internet speeds. Yet, being located far away from other Internet interconnect centers makes for some unique challenges. When traffic is delivered to local eyeballs from Hong Kong, Tokyo, Singapore or worse-still Los Angeles, it is often subject to long latency and the constraints of limited capacity before arriving in Taipei. Additionally, traffic flowing on undersea cables around Taipei have been subject to cable cuts over the years, mainly because of the active fault lines around the island.
台北有世界上首屈一指的網路速度。可是,因為台北和其他互聯網交換中心的距離,來自香港,東京,甚至洛杉磯的流量往往要通過高延時和有限的頻寬才能傳送到台北。另外,台北位於板塊交界處,地震發生頻繁,海底電䌫中斷時有發生。
With the launch of our Taipei data center, visitors to millions of CloudFlare websites will experience a 4x improvement in performance and Continue reading
Some time ago we discovered that certain very slow downloads were getting abruptly terminated and began investigating whether that was a client (i.e. web browser) or server (i.e. us) problem.
Some users were unable to download a binary file a few megabytes in length. The story was simple—the download connection was abruptly terminated even though the file was in the process of being downloaded. After a brief investigation we confirmed the problem: somewhere in our stack there was a bug.
Describing the problem was simple, reproducing the problem was easy with a single curl
command, but fixing it took surprising amount of effort.
CC BY 2.0 image by jojo nicdao
In this article I'll describe the symptoms we saw, how we reproduced it and how we fixed it. Hopefully, by sharing our experiences we will save others from the tedious debugging we went through.
Two things caught our attention in the bug report. First, only users on mobile phones were experiencing the problem. Second, the asset causing issues—a binary file—was pretty large, at around 30MB.
After a fruitful session with tcpdump
one of our engineers was able to prepare a test case that reproduced the Continue reading