Deprecating the DNS ANY meta-query type

DNS, one of the oldest technologies running the Internet, keeps evolving. There is a constant stream of new developments, from DNSSEC, through DNS-over-TLS, to a plentiful supply of fresh EDNS extensions.

New DNS Resource Records types are being added all the time. As the Internet evolves, new RR’s gain traction while the usage of some old record types decreases. Did you know you can use DNS to express the location of your server on the planet's surface?

Today, we are announcing that we are deprecating the DNS ANY meta-query. In a few weeks we'll be responding to those queries with rcode 4 / Not Implemented.

“ANY” is one of the special “magic” types in DNS. Instead of being a query for a single type like A , AAAA or MX, ANY retrieves all the available types for a given name. Over the years there have been many arguments over the semantics of ANY with some people arguing it really means ALL. Answers to ANY queries are among the biggest that DNS servers give out. The original reason for adding the ANY to DNS was to aid in debugging and testing Continue reading

Unser neuer 31er Datacenter: Düsseldorf

Hallo Düsseldorf. Nestled in the center of the Lower Rhine basin lies the bustling city of Düsseldorf, capital of Germany’s most populous state, Northern Rhine-Westphalia. Provided its status as an international business and telecommunications hub, and serving a population larger than the Netherlands, our data center in Düsseldorf is an important addition to our European network. This means not only better performance in Germany and Northern Europe, but additional redundancy for our 10 other data centers throughout Europe, including our first German data center in Frankfurt.

For the local audience: Liebe Freunde in Düsseldorf, euer Internetanschluss ist schneller geworden und ihr könnt jetzt sicher surfen. Viel Spaß.

Not just any data center

Our Düsseldorf data center holds a special place in the heart of our legal counsel Ken Carter. When he’s not helping to build a better Internet, he is likely to be found regaling the office with tales of his adventures in the quaint medieval town of Bad Honnef am Rhein, just south of our new data center. Ban Honnef, most famously known as the world-wide headquarters for Birkenstock, can now add one more tale of note. Equidistant between Frankfurt and Dusseldorf, it is Continue reading

No upgrade needed: CloudFlare sites already protected from FREAK

The newly announced FREAK vulnerability is not a concern for CloudFlare's SSL customers. We do not support 'export grade' cryptography (which, by its nature, is weak) and we upgraded to the non-vulnerable version of OpenSSL the day it was released in early January.

CC BY 2.0 image by Stuart Heath

Our OpenSSL configuration is freely available on our Github account here as are our patches to OpenSSL 1.0.2.

We strive to stay on top of vulnerabilities as they are announced; in this case no action was necessary as we were already protected by decisions to eliminate cipher suites and upgrade software.

We are also pro-active about disabling protocols and ciphers that are outdated (such as SSLv3, RC4) and keep up to date with the latest and most secure ciphers (such as ChaCha-Poly, forward secrecy and elliptic curves).

Protecting web origins with Authenticated Origin Pulls

As we have been discussing this week, securing the connection between CloudFlare and the origin server is arguably just as important as securing the connection between end users and CloudFlare. The origin certificate authority we announced this week will help CloudFlare verify that it is talking to the correct origin server. But what about verification in the opposite direction? How can the origin verify that the client talking to it is actually CloudFlare?

TLS Client Authentication

TLS (the modern version of SSL) allows a client to verify the identity of the server it is talking to. Normally, a TLS handshake is one-way, that is, the client is able to verify the server's identity, but the server is not able to verify the client's identity. What about when both sides need to verify each other's identity?

Enter TLS Client Authentication. In a client authenticated TLS handshake both sides provide a certificate to be verified. If the origin server is configured to only accept requests which use a valid client certificate from CloudFlare, requests which have not passed through CloudFlare will be dropped (as they will not have our certificate). This means that attackers cannot circumvent CloudFlare features such as our WAF Continue reading

Thoughts on Network Neutrality, the FCC, and the Future of Internet Governance

Today the United States Federal Communications Commission (FCC) voted to extend the rules that previously regulated the telephone industry to now regulate Internet Service Providers (ISPs). The Commission did this in order to preserve the principle of network neutrality. Broadly stated, this principle is that networks should not discriminate against content that passes through them.

At CloudFlare, we are strong proponents of network neutrality. My co-founder, Michelle Zatlyn, sat on the FCC's Open Internet Advisory Committee. The work of that committee played a role in guiding today's vote. So there is a large part of us that is celebrating today.

At the same time, I have deep concerns that proponents of a free and open Internet may look back on today not as a great victory, but as the first step in what may turn out to be a devastating loss. The Internet has largely been governed from the bottom up by technologists seeking rough consensus and running code. Today's action by the FCC may mark the beginning of a new era where the Internet is regulated by lawyers from the top down. As a technologist and recovering lawyer, that worries me.

The Threat to the Network

If you think Continue reading

Enforce Web Policy with HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS, RFC 6797) is a web security policy technology designed to help secure HTTPS web servers against downgrade attacks. HSTS is a powerful technology which is not yet widely adopted. CloudFlare aims to change this.

Downgrade attacks (also known as SSL stripping attacks) are a serious threat to web applications. This type of attack is a form of man-in-the-middle attack in which an attacker can redirect web browsers from a correctly configured HTTPS web server to an attacker controlled server. Once the attacker has successfully redirected a user, user data, including cookies, can be compromised. Unfortunately, this attack is outside the realm of pure SSL to prevent. This is why HSTS was created.

These attacks are very real: many major websites have been attacked through SSL stripping. They are a particularly powerful attack against otherwise well secured sites, as they bypass the protections of SSL.

HSTS headers consists of an HTTP header with several parameters -- including a configurable duration for client web browsers to cache and continue to enforce policy even if the site itself changes. Through CloudFlare, it is easy to configure on a per-domain basis with standard settings.

HSTS causes compliant browsers Continue reading

Universal SSL: Encryption all the way to the origin, for free

Last September, CloudFlare unveiled Universal SSL, enabling HTTPS support for all sites by default. All sites using CloudFlare now support strong cryptography from the browser to CloudFlare’s servers. One of the most popular requests for Universal SSL was to make it easier to encrypt the other half of the connection: from CloudFlare to the origin server.

Until today, encryption from CloudFlare to the origin required the purchase of a trusted certificate from a third party. The certificate purchasing process can be tedious and sometimes costly. To remedy this, CloudFlare has created a new Origin CA service in which we provide free limited-function certificates to customer origin servers.

Today we are excited to announce the public beta of this service, providing full encryption of all data from the browser to the origin, for free.

Encrypted all the way

CloudFlare offers three modes for HTTPS: Flexible, Full and Strict. In Flexible mode, traffic from browsers to CloudFlare is encrypted, but traffic from CloudFlare to a site's origin server is not. In Full and Strict modes, traffic between CloudFlare and the origin server is encrypted. Strict mode adds validation of the origin server’s certificate. We strongly encourage customers to select Strict mode Continue reading

TLS Session Resumption: Full-speed and Secure

At CloudFlare, making web sites faster and safer at scale is always a driving force for innovation. We introduced “Universal SSL” to dramatically increase the size of the encrypted web. In order for that to happen we knew we needed to efficiently handle large volumes of HTTPS traffic, and give end users the fastest possible performance.

CC BY 2.0 image by ecos systems

In this article, I’ll explain how we added speed to Universal SSL with session resumptions across multiple hosts, and explain the design decisions we made in this process. Currently, we use two standardized session resumption mechanisms that require two different data sharing designs: Session IDs RFC 5246, and Session Tickets RFC 5077.

Session ID Resumption

Resuming an encrypted session through a session ID means that the server keeps track of recent negotiated sessions using unique session IDs. This is done so that when a client reconnects to a server with a session ID, the server can quickly look up the session keys and resume the encrypted communication.
At each of CloudFlare’s PoPs (Point of Presence) there are multiple hosts handling HTTPS traffic. When the client attempts to resume a TLS connection with a Continue reading

Do the ChaCha: better mobile performance with cryptography

_{CC BY-ND 2.0 image image by Clinton Steeds}

CloudFlare is always trying to improve customer experience by adopting the latest and best web technologies so that our customers (and their visitors) have a fast and a secure web browsing experience.

More and more web sites are now using HTTPS by default. This sea change has been spearheaded by many groups including CloudFlare enabling free SSL for millions of sites with Universal SSL, Google moving towards marking plain HTTP as insecure in Chrome, and the Let’s Encrypt project’s plans to make certificates free in 2015.

Not only is the encrypted web more secure, it can also be faster than the unencrypted web if the latest HTTPS features are implemented. HTTPS sites are blazing fast on CloudFlare because we keep up with the latest performance-enhancing features:

• SPDY 3.1 is on by default for all customers. SPDY enables faster-than-HTTP download speeds by enabling multiplexing
• OCSP stapling: faster revocation checking.
• Optimized certificate bundles using CFSSL, our open source SSL bundler: an optimized certificate chain provides faster validation of certificates in the browser
• ECDSA certificates for all free customers with Universal SSL: smaller certificates with smaller keys result in faster Continue reading

End of the road for RC4

Today, we completely disabled the RC4 encryption algorithm for all SSL/TLS connections to CloudFlare sites. It's no longer possible to connect to any site that uses CloudFlare using RC4.

Over a year ago, we disabled RC4 for connections for TLS 1.1 and above because there were more secure algorithms available. In May 2014, we deprecated RC4 by moving it to the lowest priority in our list of cipher suites. That forced any browser that had a good alternative to RC4 to use it. Those two changes meant that almost everyone who was using RC4 to connect to CloudFlare sites switched to a more secure protocol.

Back in May, we noted that some people still needed RC4, particularly people using old mobile phones and some Windows XP users. At the time, 4% of requests using RC4 came from a single phone type: the Nokia 6120.

At the time, we noted that roughly 0.000002% of requests to CloudFlare were using the RC4 protocol. In the last 9 months, that number is halved and so, although some people are still using RC4, we have decided to turn off the protocol. It's simply no longer secure.

The remaining users are almost Continue reading

SSL Week Means Less Weak SSL

I'm excited to announce that today kicks off SSL Week at CloudFlare. Over the course of this week, we'll make a series of announcements on what we're doing to improve encryption on the Internet.

Inherently, for encryption to be the most effective, it has to meet three criteria: 1) it needs to be easy and inexpensive to use; 2) it needs to be fast so it doesn't tax performance; and 3) it needs to be up to date and ahead of the latest vulnerabilities.

Easy, Fast & Secure

Throughout CloudFlare's history, these priorities have guided our approach to encryption. Last September, we announced Universal SSL and brought world class encryption to every CloudFlare customer, even those on our Free service plan. While that effort doubled the size of the encrypted web, our work is far from done. This week we're announcing a series of initiatives that further our efforts to ensure we provide the easiest, fastest, and most secure encryption.

While Universal SSL made it easy to ensure that the connection from a device to CloudFlare was secure, this week we're going to begin the process of making it easy (and free) to ensure the connection from CloudFlare back to Continue reading

Get Started with CloudFlare ServerShield for Plesk

ServerShield makes it easy to activate CloudFlare and StopTheHacker.

CloudFlare has partnered with Parallels, the leading hosting solutions provider, to make server protection, content acceleration and malware removal easier than ever. We recently launched CloudFlare ServerShield® to all Plesk 12 users as an extension. ServerShield combines the performance and security features of CloudFlare with the malware scanning and removal solution of StopTheHacker. Whether you are a hosting provider looking to offer additional services to your customers, or a Plesk server user, you can access ServerShield with two easy clicks.

Already, a number of hosters and agencies have found ServerShield a key addition to their tools to help their customer sites’ security and performance. Rafal Kukla of Kukla Studio, a UK based design agency, has this to say:

“ServerShield made it straightforward to give my customers industry leading security and performance as well as reputation monitoring. Running a busy agency, I am focused on my customers' site design, ServerShield allows me to do that without sacrificing the fundamentals of site functionality. With one single click I can enable CloudFlare among all my customers instead of spending time configuring each site separately.”

We believe that this extension is incredibly timely Continue reading

Updating the DNS Registration Model to Keep Pace with Today’s Internet.

CloudFlare is, arguably, the largest third-party DNS Authoritative operator in the world. We manage well over 1 million domains and have registrations in almost every TLD open for registrations. Our role as a DNS operator is to maintain customer information and publish their records in the global DNS.

In this blog, we’ll introduce a significant problem that DNS operators like CloudFlare face when trying to provide the best possible experience to our customers. If you are a CloudFlare customer, you’ll remember during the sign up process you were asked to login to your registrar account in order to change your nameservers (NS). The absence of an automated process for changing NS records not only makes our signup process one step longer than we’d like, it also prevents CloudFlare, and other 3rd party DNS operators, from doing a slew of other things that would benefit customers and the Internet as a whole.

Note: In this blog we’ll use the term DNS Operator mainly in the context of operators that provide Authoritative DNS service. This is sometimes called Managed DNS service.

Manual Updates

For those who are not yet CloudFlare customers, let’s run through the sign up process:

When CloudFlare customers enable Continue reading

Path MTU discovery in practice

Last week, a very small number of our users who are using IP tunnels (primarily tunneling IPv6 over IPv4) were unable to access our services because a networking change broke "path MTU discovery" on our servers. In this article, I'll explain what path MTU discovery is, how we broke it, how we fixed it and the open source code we used.

First there was the fragmentation

When a host on the Internet wants to send some data, it must know how to divide the data into packets. And in particular it needs to know the maximum size of packet. The maximum size of a packet a host can send is called Maximum Transmission Unit: MTU.

The longer the MTU, the better for performance, but the worse for reliability, because a lost packet means more data to be retransmitted and because many routers on the Internet can't deliver very long packets.

The fathers of the Internet assumed that this problem would be solved at the IP layer with IP fragmentation. Unfortunately IP fragmentation has serious disadvantages and it's avoided in practice.

Do-not-fragment bit

To work around fragmentation problems the IP layer contains a "Don't Fragment" bit on every IP packet. Continue reading

DNSSEC Done Right

This blog post is probably more personal than the usual posts here. It’s about why I joined CloudFlare.

I’ve been working on DNSSEC evolution for a long time as implementor, IETF working group chair, protocol experimenter, DNS operator, consultant, and evangelist. These different perspectives allow me to look at the protocol in a holistic way.

First and foremost, it’s important to realize the exact role of DNSSEC. DNSSEC is actually a misnomer: it’s from an era when the understanding of different security technologies, and what role each plays, was not as good as today. Today, this protocol would be called DNSAUTH. This is because all it does is to provide integrity protection to the answers from authoritative servers.

Over the years, the design of DNSSEC has changed. A number of people working on early versions of DNSSEC (myself included) didn’t know DNS all that well. Similarly, many DNS people at the time didn’t understand security, and in particular, cryptography all that well. To make things even more complex, general understanding of the DNS protocol was lacking in certain areas and needed to be clarified in order to do DNSSEC properly. This has led to three major versions of the Continue reading

Help us test our DNSSEC implementation

For an introduction to DNSSEC, see our previous post

Today is a big day for CloudFlare! We are publishing our first two DNSSEC signed zones for the community to analyze and give feedback on:

• www.cloudflare-dnssec-auth.com - a fully signed zone managed by CloudFlare
• www.cloudflare-dnssec-cname.com - an external zone linking to a signed record with a CNAME

We've been testing our implementation internally for some time with great results, so we now want to know from outside users how it’s working!

Here’s an example of what you should see if you pull the records of, for example, www.cloudflare-dnssec-auth.com.

$ dig www.cloudflare-dnssec-auth.com A +dnssec

; <<>> DiG 9.10.1-P1 <<>> www.cloudflare-dnssec-auth.com A +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29654
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.cloudflare-dnssec-auth.com.    IN  A

;; ANSWER SECTION:
www.cloudflare-dnssec-auth.com.    300 IN  A   104.28.29.67  
www.cloudflare-dnssec-auth.com.    300 IN  A   104.28.28.67  
www.cloudflare-dnssec-auth.com.    300 IN  RRSIG   A  Continue reading

Flexible SSL & WordPress: Fixing “Mixed Content” Errors

As many are aware, CloudFlare launched Universal SSL several months ago. We saw lots of customers sign up and start using these new, free SSL certificates. For many customers that didn’t already have an SSL certificate, they were able to use “Flexible SSL”.

Flexible SSL creates a secure (HTTPS) connection between the website visitor and CloudFlare and then an in-secure (HTTP) connection between CloudFlare and the origin server. For any site using absolute links to assets (i.e. javascript, css, and image files), this can lead to a “Mixed Content” error.

Mixed Content = Mixed Protocol

What is “Mixed Content”? This can be understood as mixed protocol. When the webpage is loaded over SSL (HTTPS protocol), most browsers expect all of the assets to be loaded over the same protocol. Some browsers will display an error about loading “insecure content” while others will just block the insecure content outright.

This error only applies to pages loaded over SSL, since the browser is working to make sure that secure pages only load equally secure assets.

Wordpress Plugin Updates

The latest version of the CloudFlare plugin for Wordpress works to resolve a lot of these errors by altering the protocol within the Continue reading

DDoS Packet Forensics: Take me to the hex!

A few days ago, my colleague Marek sent an email about a DDoS attack against one of our DNS servers that we'd been blocking with our BPF rules. He noticed that there seemed to be a strange correlation between the TTL field in the IP header and the IPv4 source address.

CC BY 2.0 image by Jeremy Keith

The source address was being spoofed, as usual, and apparently chosen randomly, but something else was going on. He offered a bottle of Scotch to the first person to come up with a satisfactory solution.

Here's what some of the packets looked like:

$ tcpdump -ni eth0 -c 10 "ip[8]=40 and udp and port 53"
1.181.207.7.46337 > x.x.x.x.53: 65098+  
1.178.97.141.45569 > x.x.x.x.53: 65101+  
1.248.136.142.63489 > x.x.x.x.53: 65031+  
1.207.241.195.52993 > x.x.x.x.53: 65072+

$ tcpdump -ni eth0 -c 10 "ip[8]=41 and udp and port 53"
2.10.30.2.2562 > x.x.x.x.53: 65013+  
2.4.9.36.1026 > x.x.x.x.53: 65019+  
2.98. Continue reading

CloudFlare in 2014: Bigger, Faster, Securer

At the end of 2013 we posted a blog article titled 2013: Rebuild the Engine; 2014: Step on the Gas which explained how in 2013 we had been rebuilding the engine that powers CloudFlare and how we expected 2014 to be when we stepped on the gas.

In that blog post, we said that we'd be expanding our network to betters serve customers in China and Latin America (as well as continuing other global expansions), and that we'd be making a big announcement around SSL.

CC BY-ND 2.0 image by Do Hyun-Kim

Looking back at 2014, we did a whole lot more and many of those changes had a meaningful impact well beyond CloudFlare. Now when we make a change, the needles on the Internet's dials move: when we roll out support for new protocols, sites tracking those protocols see a sudden jump in usage.

Here's a month by month review of CloudFlare's 2014:

January 8: keeping our promise to Latin America, we opened our first data center there in Chile.

January 27: we published our first transparency report covering National Security Orders on the first day it became legal to discuss them.

February 13: we Continue reading

Kyoto Tycoon Secure Replication

Kyoto Tycoon is a distributed key-value store written by FAL Labs, and it is used extensively at CloudFlare. Like many popular key-value stores, Kyoto Tycoon uses timestamp-based replication to ensure eventual consistency and guarantee ordering. Kyoto Tycoon is an open source project, and in the spirit of the holidays, we’re contributing our internal changes back to the open source project.

_{CC BY-ND 2.0 image by Moyan Brenn}

CloudFlare uses Kyoto Tycoon to replicate data from a Postgres Database to our 30 data centers around the world. In practice, it takes around 3 seconds for full propagation in normal conditions. This is our pipeline for distributing sensitive data like our session ticket keys and DNS data to the CloudFlare edge.

Protecting data in transit

If the Internet is not a dangerous place, it at least has dangerous neighborhoods. To move from one datacenter to another, data has to pass through the public Internet. Data could end up going though some network with a wire-tap in place, or through a network with an unscrupulous network operator.

Datacenter-to-datacenter encryption has been brought into the international spotlight since the surveillance revelations. One of the leaked slides contained the expression “SSL added Continue reading