Building the simplest Go static analysis tool
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.
First, loading the program
We use golang.org/x/tools/go/loader to Continue reading
Kiev, Ukraine: CloudFlare’s 78th Data Center
Здоровенькі були! 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.
Localizing content
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
Empty DDoS Threats: Meet the Armada Collective
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 Threat
The extortion emails sent by the Armada Collective have been remarkably consistent over the last two months. Here's an example:
To: [Victim Org's Role Account]
From: [email protected]
Subject: DDOS ATTACK!!
FORWARD THIS MAIL TO WHOEVER IS IMPORTANT Continue reading
From: [email protected]
Subject: DDOS ATTACK!!
FORWARD THIS MAIL TO WHOEVER IS IMPORTANT Continue reading
Today Is A Big Day For Page Rules
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.
Announcing API Support For Page Rules
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.
13 New Settings Now Available On Page Rules
Instead of the short list of settings you could previously toggle, we've added menus with almost every Continue reading
IETF Hackathon: Getting TLS 1.3 working in the browser
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
New for Virtual DNS Customers: Self-Service Dashboard and APIs, and Two New Features
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.
A brand new dashboard and API
The new Virtual DNS dashboard makes it fast and easy Continue reading
What happened next: the deprecation of ANY
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
Taipei: CloudFlare’s 77th Data Center is Now Live
台北：CloudFlare的第七十七個數據中心已經上線喔！
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 today
今天的台北
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.
科技重鎮台北，不單擁用充滿活力的夜市，台北人的熱情而友善的人情味也是舉世聞名的。從小籠包、電腦周邊零件到康熙來了，台北對世界的貢獻碩大無朋。
Improved availability and performance
更進一步的可用性和性能
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
The curious case of slow downloads
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.
Failing downloads
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
CloudFlare Crypto Meetup: April 21, 2016
CloudFlare Crypto Meetup Teaser.
Now back in HD: the CloudFlare Cryptography Meetup series. A while back, CloudFlare hosted a pair of Meetups focused on encryption and cryptographic technology. Now that CloudFlare HQ has moved into our beautiful new home at 101 Townsend in San Francisco, we’ve decided to bring the crypto back.
In this series, we’ve invited experts from academia and industry to talk about the cryptographic protocols they are working on and to share experiences around deploying cryptographic applications in the real world. This is the place to geek out on crypto!
These talks are intended to explore interesting new crypto topics in an accessible way. It aims to be informative and thought provoking, and practical examples are encouraged.
We’ll start the evening at 6:00p.m. with time for networking, followed up with short talks by leading experts. Pizza and beer are provided!
Whether you're a cryptography hobbyist, an industry expert or just interested in the subject, come visit CloudFlare’s world headquarters at 6:00pm on April 21st.
RSVP here on Meetup.com.
Speakers
The confirmed speakers for April 21st are Brian Warner, Zakir Durumeric and Amine Kamel.
Brian Warner
magic-wormhole
"magic-wormhole" is a simple tool to move files from Continue reading
The revenge of the listening sockets
Back in November we wrote a blog post about one latency spike. Today I'd like to share a continuation of that story. As it turns out, the misconfigured rmem setting wasn't the only source of added latency.
It looked like Mr Wolf hadn't finished his job.
After adjusting the previously discussed rmem sysctl we continued monitoring our systems' latency. Among other things we measured ping times to our edge servers. While the worst case improved and we didn't see 1000ms+ pings anymore, the line still wasn't flat. Here's a graph of ping latency between an idling internal machine and a production server. The test was done within the datacenter, the packets never went to the public internet. The Y axis of the chart shows ping times in milliseconds, the X axis is the time of the measurement. Measurements were taken every second for over 6 hours:
As you can see most pings finished below 1ms. But out of 21,600 measurements about 20 had high latency of up to 100ms. Not ideal, is it?
System tap
The latency occurred within our datacenter and the packets weren't lost. This suggested a kernel issue again. Linux responds to ICMP pings from its soft Continue reading
It takes two to ChaCha (Poly)
Not long ago we introduced support for TLS cipher suites based on the ChaCha20-Poly1305 AEAD, for all our customers. Back then those cipher suites were only supported by the Chrome browser and Google's websites, but were in the process of standardization. We introduced these cipher suites to give end users on mobile devices the best possible performance and security.
CC BY-ND 2.0 image by Edwin Lee
Today the standardization process is all but complete and implementations of the most recent specification of the cipher suites have begun to surface. Firefox and OpenSSL have both implemented the new cipher suites for upcoming versions, and Chrome updated its implementation as well.
We, as pioneers of ChaCha20-Poly1305 adoption on the web, also updated our open sourced patch for OpenSSL. It implements both the older "draft" version, to keep supporting millions of users of the existing versions of Chrome, and the newer "RFC" version that supports the upcoming browsers from day one.
In this blog entry I review the history of ChaCha20-Poly1305, its standardization process, as well as its importance for the future of the web. I will also take a peek at its performance, compared to the other standard AEAD.
What Continue reading
Come Geek Out With The Original Inventor of DNS at CloudFlare
We like DNS, we think you might too.
CloudFlare and Gandi are hosting a three-part series on DNS. Our first event will be at the CloudFlare office with Paul Mockapetris, the original inventor of the Domain Name System.
Beyond inventing DNS, Paul built the first ever SMTP server. He ran networking at ARPA, served as the chair of the IETF, and is a honored member of the Internet Hall of Fame. He is currently the Chief Scientist at Threatstop, and the visiting scholar at the Universite de Pierre et Marie Curie in Paris.
The event is on Tuesday, April 12th, 2016 at 6 PM PST at our office in San Francisco, 101 Townsend Street (RSVP here). We’ll be covering the early days of DNS, DNS and security, the commercialization of DNS (what Paul famously calls DN$), and the future of DNS.
So come, grab some beer, and hang out with people who like DNS as much as you do.
Introducing CFSSL 1.2
Continuing our commitment to high quality open-source software, we’re happy to announce release 1.2 of CFSSL, our TLS/PKI Swiss Army knife. We haven’t written much about CFSSL here since we originally open sourced the project in 2014, so we thought we’d provide an update. In the last 20 months, we have added a ton of great features, and CFSSL has attracted an active community of users and contributors. Users range from large SaaS providers (Heroku) to game companies (Riot Games) and the newest Certificate Authority (Let’s Encrypt). For them and for CloudFlare, CFSSL has become a core tool for automating certificates and TLS configurations. With added support for configuration scanning, automated provisioning via the transport package, revocation, certificate transparency and PKCS#11, CFSSL is now even more powerful.
We’re also happy to announce CFSSL’s new home: cfssl.org. From there you can try out CFSSL’s user interface, download binaries, and test some of its features.
Motivation
This 2013 National Security Agency (NSA) slide describing how data from Google’s internal network was collected by intelligence agencies was eye-opening—and shocking—to many technology companies. The idea that an attacker could read messages passed between services wasn’t technically groundbreaking, but it Continue reading
The Trouble with Tor
The Tor Project makes a browser that allows anyone to surf the Internet anonymously. Tor stands for "the Onion router" and that describes how the service works. Traffic is routed through a number of relays run across the Internet where each relay only knows the next hop (because each hop is enclosed in a cryptographic envelope), not the ultimate destination, until the traffic gets to the final exit node which connects to the website — like peeling the layers of an onion.
Think of it like a black box: traffic goes into the box, is bounced around between a random set of relays, and ultimately comes out to connect to the requested site. Anonymity is assured because anyone monitoring the network would have a difficult time tying the individuals making the requests going into the black box with the requests coming out.
Importance and Challenges of Anonymity
Anonymity online is important for a number of reasons we at CloudFlare believe in. For instance, Tor is instrumental in ensuring that individuals living in repressive regimes can access information that may otherwise be blocked or illegal. We this is so important that we offer Continue reading
Going to IETF 95? Join the TLS 1.3 hackathon
If you’re in Buenos Aires on April 2-3 and are interested in building, come join the IETF Hackathon. CloudFlare and Mozilla will be working on TLS 1.3, the first new version of TLS in eight years!
At the hackathon we’ll be focusing on implementing the latest draft of TLS 1.3 and testing interoperability between existing implementations written in C, Go, OCaml, JavaScript and F*. If you have experience with network programming and cryptography, come hack on the latest and greatest protocol and help find problems before it is finalized. If you’re planning on attending, add your name to the Hackathon wiki. If you can’t make it, but implementing cryptographic protocols is your cup of tea, apply to join the CloudFlare team!
We’re very excited about TLS 1.3, which brings both security and performance improvements to HTTPS. In fact, if you have a client that speaks TLS 1.3 draft 10, you can read this blog on our TLS 1.3 mirror: tls13.cloudflare.com.
We hope to see you there!
TLS Certificate Optimization: The Technical Details behind “No Browser Left Behind”
Overview
Back in early December we announced our "no browser left behind" initiative to the world. Since then, we have served well over 500 billion SHA-1 certificates to visitors that otherwise would not have been able to communicate securely with our customers’ sites using HTTPS. All the while, we’ve continued to present newer SHA-2 certificates to modern browsers using the latest in elliptic curve cryptography, demonstrating that one does not have to sacrifice security to accommodate all the world’s Internet users. (If you weren’t able to acquire a SHA-1 certificate before CAs ceased issuing them on 2015/12/31, you can still sign up for a paid plan and we will immediately generate one to serve to your legacy visitors.)
Shortly after we announced these new benefits for our paid Universal SSL customers, we started hearing from other technology leaders who were implementing (or already had implemented) similar functionality. At first glance, the logic to identify incoming connections that only support SHA-1 seems straightforward, but as we spoke with our friends at Facebook, Twitter, and Mozilla, I realized that everyone was taking a slightly different approach. Complicating the matter even further was the fact that at CloudFlare we not only Continue reading
A Deep Dive Into DNS Packet Sizes: Why Smaller Packet Sizes Keep The Internet Safe
Yesterday we wrote about the 400 gigabit per second attacks we see on our network.
One way that attackers DDoS websites is by repeatedly doing DNS lookups that have small queries, but large answers. The attackers spoof their IP address so that the DNS answers are sent to the server they are attacking, this is called a reflection attack.
Domains with DNSSEC, because of the size of some responses, are usually ripe for this type of abuse, and many DNS providers struggle to combat DNSSEC-based DDoS attacks. Just last month, Akamai published a report on attacks using DNS lookups against their DNSSEC-signed .gov domains to DDoS other domains. They say they have seen 400 of these attacks since November.
To prevent any domain on CloudFlare being abused for a DNS amplification attack in this way, we took precautions to make sure most DNS answers we send fit in a 512 byte UDP packet, even when the zone is signed with DNSSEC. To do this, we had to be creative in our DNSSEC implementation. We chose a rarely-used-for-DNSSEC signature algorithm and even deprecated a DNS record type along the way.
Elliptic Curves: Keeping It Tight
Dutch mathematician Arjen Lenstra famously talks Continue reading
400Gbps: Winter of Whopping Weekend DDoS Attacks
Over the last month, we’ve been watching some of the largest distributed denial of service (DDoS) attacks ever seen unfold. As CloudFlare has grown we've brought on line systems capable of absorbing and accurately measuring attacks. Since we don't need to resort to crude techniques to block traffic we can measure and filter attacks with accuracy. Our systems sort bad packets from good, keep websites online and keep track of attack packet rates and bits per second.
The current spate of large attacks are all layer 3 (L3) DDoS. Layer 3 attacks consist of a large volume of packets hitting the target network, and the aim is usually to overwhelm the target network hardware or connectivity.
L3 attacks are dangerous because most of the time the only solution is to acquire large network capacity and buy beefy networking hardware, which is simply not an option for most independent website operators. Or, faced with huge packet rates, some providers simply turn off connections or entirely block IP addresses.
A Typical Day At CloudFlare
Historically, L3 attacks were the biggest headache for CloudFlare. Over the last two years, we’ve automated almost all of our L3 attack handling and these automatic systems protect Continue reading
Staying afloat: the DROWN Attack and CloudFlare
CloudFlare customers are automatically protected against the recently disclosed DROWN Attack. We do not have SSLv2 enabled on our servers.
We publish our SSL configuration here so that others can use it. We currently accept TLS 1.0, 1.1 and 1.2.
We are proactively testing our customers' origin web servers to detect vulnerable servers and will be reaching out to any that have a server that is vulnerable to DROWN.
In the interim, ensure that SSLv2 is fully disabled and/or that private keys are not shared with servers that still need to have SSLv2.