In 2014, Cloudflare set out to encrypt the Internet by introducing Universal SSL. It made getting an SSL/TLS certificate free and easy at a time when doing so was neither free, nor easy. Overnight millions of websites had a secure connection between the user’s browser and Cloudflare.

But getting the connection encrypted from Cloudflare to the customer’s origin server was more complex. Since Cloudflare and all browsers supported SSL/TLS, the connection between the browser and Cloudflare could be instantly secured. But back in 2014 configuring an origin server with an SSL/TLS certificate was complex, expensive, and sometimes not even possible.

And so we relied on users to configure the best security level for their origin server. Later we added a service that detects and recommends the highest level of security for the connection between Cloudflare and the origin server. We also introduced free origin server certificates for customers who didn’t want to get a certificate elsewhere.

Today, we’re going even further. Cloudflare will shortly find the most secure connection possible to our customers’ origin servers and use it, automatically. Doing this correctly, at scale, while not breaking a customer’s service is very complicated. This blog post explains how we are automatically achieving that highest level of security possible for those customers who don’t want to spend time configuring their SSL/TLS set up manually.

When we announced Universal SSL, we knew the backend security of the connection between Cloudflare and the origin was a different and harder problem to solve.

In order to configure the tightest security, customers had to procure a certificate from a third party and upload it to their origin. Then they had to indicate to Cloudflare that we should use this certificate to verify the identity of the server while also indicating the connection security capabilities of their origin. This could be an expensive and tedious process. To help alleviate this high set up cost, in 2015 Cloudflare launched a beta Origin CA service in which we provided free limited-function certificates to customer origin servers. We also provided guidance on how to correctly configure and upload the certificates, so that secure connections between Cloudflare and a customer’s origin could be established quickly and easily.

What we discovered though, is that while this service was useful to customers, it still required a lot of configuration. We didn’t see the change we did with Universal SSL because customers still had to fight with their origins in order to upload certificates and test to make sure that they had configured everything correctly. And when you throw things like load balancers into the mix or servers mapped to different subdomains, handling server-side SSL/TLS gets even more complicated.

Around the same time as that announcement, Let’s Encrypt and other services began offering certificates as a public CA for free, making TLS easier and paving the way for widespread adoption. Let’s Encrypt and Cloudflare had come to the same conclusion: by offering certificates for free, simplifying server configuration for the user, and working to streamline certificate renewal, they could make a tangible impact on the overall security of the web.

The announcements of free and easy to configure certificates correlated with an increase in attention on origin-facing security. Cloudflare customers began requesting more documentation to configure origin-facing certificates and SSL/TLS communication that were performant and intuitive. In response, in 2016 we announced the GA of origin certificate authority to provide cheap and easy origin certificates along with guidance on how to best configure backend security for any website.

The increased customer demand and attention helped pave the way for additional features that focused on backend security on Cloudflare. For example, authenticated origin pull ensures that only HTTPS requests from Cloudflare will receive a response from your origin, preventing an origin response from requests outside of Cloudflare. Another option, Cloudflare Tunnel can be set up to run on the origin servers, proactively establishing secure and private tunnels to the nearest Cloudflare data center. This configuration allows customers to completely lock down their origin servers to only receive requests routed through our network. For customers unable to lock down their origins using this method, we still encourage adopting the strongest possible security when configuring how Cloudflare should connect to an origin server.

Cloudflare currently offers five options for SSL/TLS configurability that we use when communicating with origins:

• In Off mode, as you might expect, traffic from browsers to Cloudflare and from Cloudflare to origins are not encrypted and will use plain text HTTP.

• In Flexible mode, traffic from browsers to Cloudflare can be encrypted via HTTPS, but traffic from Cloudflare to the site's origin server is not. This is a common selection for origins that cannot support TLS, even though we recommend upgrading this origin configuration wherever possible. A guide for upgrading can be found here.

• In Full mode, Cloudflare follows whatever is happening with the browser request and uses that same option to connect to the origin. For example, if the browser uses HTTP to connect to Cloudflare, we’ll establish a connection with the origin over HTTP. If the browser uses HTTPS, we’ll use HTTPS to communicate with the origin; however we will not validate the certificate on the origin to prove the identity and trustworthiness of the server.

• In Full (strict) mode, traffic between Cloudflare follows the same pattern as in Full mode, however Full (strict) mode adds validation of the origin server’s certificate. The origin certificate can either be issued by a public CA like Let’s Encrypt or by Cloudflare Origin CA.

• In Strict mode, traffic from the browser to Cloudflare that is HTTP or HTTPS will always be connected to the origin over HTTPS with a validation of the origin server’s certificate.

What we have found in a lot of cases is that when customers initially signed up for Cloudflare, the origin they were using could not support the most advanced versions of encryption, resulting in origin-facing communication using unencrypted HTTP. These default values persisted over time, even though the origin has become more capable. We think the time is ripe to re-evaluate the entire concept of default SSL/TLS levels.

That’s why we will reduce the configuration burden for origin-facing security by automatically managing this on behalf of our customers. Cloudflare will provide a zero configuration option for how we will communicate with origins: we will simply look at an origin and use the most-secure option available to communicate with it.

Re-evaluating default SSL/TLS modes is only the beginning. Not only will we automatically upgrade sites to their best security setting, we will also open up all SSL/TLS modes to all plan levels. Historically, Strict mode was reserved for enterprise customers only. This was because we released this mode in 2014 when few people had origins that were able to communicate over SSL/TLS, and we were nervous about customers breaking their configurations. But this is 2022, and we think that Strict mode should be available to anyone who wants to use it. So we will be opening it up to everyone with the launch of the automatic upgrades.

To upgrade the origin-facing security of websites, we first need to determine the highest security level the origin can use. To make this determination, we will use the SSL/TLS Recommender tool that we released a year ago.

The recommender performs a series of requests from Cloudflare to the customer’s origin(s) to determine if the backend communication can be upgraded beyond what is currently configured. The recommender accomplishes this by:

• Crawling the website to collect links on different pages of the site. For websites with large numbers of links, the recommender will only examine a subset. Similarly, for sites where the crawl turns up an insufficient number of links, we augment our results with a sample of links from recent visitors requests to the zone. All of this is to get a representative sample to where requests are going in order to know how responses are served from the origin.

• The crawler uses the user agent Cloudflare-SSLDetector and has been added to Cloudflare’s list of known “good bots”.

• Next, the recommender downloads the content of each link over both HTTP and HTTPS. The recommender makes only idempotent GET requests when scanning origin servers to avoid modifying server resource state.

• Following this, the recommender runs a content similarity algorithm to determine if the content collected over HTTP and HTTPS matches.

• If the content that is downloaded over HTTP matches the content downloaded over HTTPS, then it’s known that we can upgrade the security of the website without negative consequences.

• If the website is already configured to Full mode, we will perform a certificate validation (without the additional need for crawling the site) to determine whether it can be updated to Full (strict) mode or higher.

If it can be determined that the customer’s origin is able to be upgraded without breaking, we will upgrade the origin-facing security automatically.

But that’s not all. Not only are we removing the configuration burden for services on Cloudflare, but we’re also providing more precise security settings by moving from per-zone SSL/TLS settings to per-origin SSL/TLS settings.

The current implementation of the backend SSL/TLS service is related to an entire website, which works well for those with a single origin. For those that have more complex setups however, this can mean that origin-facing security is defined by the lowest capable origin serving a part of the traffic for that service. For example, if a website uses img.example.com and api.example.com, and these subdomains are served by different origins that have different security capabilities, we would not want to limit the SSL/TLS capabilities of both subdomains to the least secure origin. By using our new service, we will be able to set per-origin security more precisely to allow us to maximize the security posture of each origin.

The goal of this is to maximize the origin-facing security of everything on Cloudflare. However, if any origin that we attempt to scan blocks the SSL recommender, has a non-functional origin, or opts-out of this service, we will not complete the scans and will not be able to upgrade security. Details on how to opt-out will be provided via email announcements soon.

There are a number of reasons why someone might want to configure a lower-than-optimal security setting for their website. One common reason customers provide is a fear that having higher security settings will negatively impact the performance of their site. Others may want to set a suboptimal security setting for testing purposes or to debug some behavior. Whatever the reason, we will provide the tools needed to continue to configure the SSL/TLS mode you want, even if that’s different from what we think is the best.

We will begin to roll this change out before the end of the year. If you read this and want to make sure you’re at the highest level of backend security already, we recommend Full (strict) or Strict mode. If you prefer to wait for us to automatically upgrade your origin security for you, please keep your eyes peeled to your inbox for the date we will begin rolling out this change for your group.

At Cloudflare, we believe that the Internet needs to be secure and private. If you’d like to help us achieve that, we’re hiring across the engineering organization.

By 'end-to-end security', I mean that neither the site owner nor users have to trust Cloudflare to serve the correct documents, like they do now. This is similar to how using HTTPS means you don't have to trust your ISP to not modify or inspect traffic.

The first step is to choose a domain name for your website. Websites should be given their own domain name, rather than served directly from the gateway by root hash, so that they are considered a distinct origin by the browser. This is primarily to prevent cache poisoning, but there are several functional advantages as well. It gives websites their own instance of localStorage and their own cookie jar which are sandboxed from inspection and manipulation by malicious third-party documents. It also lets them run Service Workers without conflict, and request special permissions of the user like access to the webcam or GPS. But most importantly, having a domain name makes a website easier to identify and remember.

Now that you've chosen a domain, rather than using it as-is, you’ll need to add "ipfs-sec" as the left-most subdomain. So for example, you'd use "ipfs-sec.example.com" instead of just "example.com". The ipfs-sec subdomain is special because it signals to the user and to their browser that your website is capable of being served with end-to-end integrity.

In addition to that, ipfs-sec domains require DNSSEC to be properly setup to prevent spoofing. Unlike with standard HTTPS, where DNS spoofing can't usually result in a on-path attacker attack, this is exactly what DNS spoofing does to IPFS because the root hash of the website is stored in DNS. Many registrars make enabling DNSSEC as easy as the push of a button, though some don't support it at all.

With the ipfs-sec domain, you can now follow the developer documentation on how to serve a generic static website from IPFS. Note that you'll need to use a CNAME setup and retain control of your DNS, rather than the easier method of just signing up for Cloudflare. This helps maintain a proper separation between the party managing the DNSSEC signing keys and the party serving content to end-users. Keep in mind that CNAME setups tend to be problematic and get into cases that are difficult to debug, which is why we reserve them for technically sophisticated customers.

You should now be able to access your website over HTTP and HTTPS, backed by our gateway.

HTTPS helps makes sure that nobody between the user and Cloudflare's edge network has tampered with the connection, but it does nothing to make sure that Cloudflare actually serves the content the user asked for. To solve this, we built two connected projects: a modified gateway service and a browser extension.

First, we forked the go-ipfs repository and gave it the ability to offer cryptographic proofs that it was serving content honestly, which it will do whenever it sees requests with the HTTP header X-Ipfs-Secure-Gateway: 1. The simplest case for this is when users request a single file from the gateway by its hash -- all the gateway has to do is serve the content and any metadata that might be necessary to re-compute the given hash.

A more complicated case is when users request a file from a directory. Luckily, directories in IPFS are just files containing a mapping from file name to the hash of the file, and very large directories can be transparently split up into several smaller files, structured into a search tree called a Hash Array Mapped Trie (HAMT). To convince the client that the gateway is serving the contents of the correct file, the gateway first serves the file corresponding to the directory, or every node in the search path if the directory is a HAMT. The client can hash this file (or search tree node), check that it equals the hash of the directory they asked for, and look up the hash of the file they want from within the directory's contents. The gateway then serves the contents of the requested file, which the client can now verify because it knows the expected hash.

Finally, the most complicated case by far is when the client wants to access content by domain name. It's complicated because the protocol for authenticating DNS, called DNSSEC, has very few client-side implementations. DNSSEC is also not widely deployed, even though some registrars make it even easier than setting up HTTPS. In the end, we ended up writing our own simple DNSSEC-validating resolver that's capable of outputting a cryptographically-convincing proof that it did some lookup correctly.

It works the same way as certificate validation in HTTPS: we start at the bottom, with a signature from some authority claiming to be example.com over the DNS records they want us to serve. We then lookup a delegation (DS record) from an authority claiming to be .com, that says "example.com is the authority with these public keys" which is in turn signed by the .com authority's private key. And finally, we lookup a delegation from the root authority, ICANN (whose public keys we already have), attesting to the public keys used by the .com authority. All of these lookups bundled together form an authenticated chain starting at ICANN and ending at the exact records we want to serve. These constitute the proof.

Chain of trust in DNSSEC.

The second project we built out was a browser extension that requests these proofs from IPFS gateways and ipfs-sec domains, and is capable of verifying them. The extension uses the webRequest API to sit between the browser's network stack and its rendering engine, preventing any unexpected data from being show to the user or unexpected code from being executed. The code for the browser extension is available on Github, and can be installed through Firefox's add-on store. We’re excited to add support for Chrome as well, but that can’t move forward until this ticket in their bug tracker is addressed.

On the other hand, if a user doesn't have the extension installed, the gateway won't see the X-Ipfs-Secure-Gateway header and will serve the page like a normal website, without any proofs. This provides a graceful upgrade path to using IPFS, either through our extension that uses a third-party gateway or perhaps another browser extension that runs a proper IPFS node in-browser.

My favorite website on IPFS so far has been the mirror of English Wikipedia put up by the IPFS team at Protocol Labs. It's fast, fun to play with, and above all has practical utility. One problem that stands out though, is that the mirror has no search feature so you either have to know the URL of the page you want to see or try to find it through Google. The Turkish-language mirror has in-app search but it requires a call to a dynamic API on the same host, and doesn't work through Cloudflare's gateway because we only serve static content.

I wanted to provide an example of the kinds of secure, performant applications that are possible with IPFS, and this made building a search engine seem like a prime candidate. Rather than steal Protocol Labs' idea of 'Wikipedia on IPFS', we decided to take the Kiwix archives of all the different StackExchange websites and build a distributed search engine on top of that. You can play with the finished product here: ipfs-sec.stackexchange.cloudflare-ipfs.com.

The way it's built is actually really simple, at least as far as search engines go: We build an inverted index and publish it with the rest of each StackExchange, along with a JavaScript client that can read the index and quickly identify documents that are relevant to a user's query. Building the index takes two passes over the data:

1. The first pass decides what words/tokens we want to allow users to search by. Tokens shouldn't be too popular (like the top 100 words in English), because then the list of all documents containing that token is going to be huge and it's not going to improve the search results anyways. They also shouldn't be too rare (like a timestamp with sub-second-precision), because then the index will be full of meaningless tokens that occur in only one document each. You can get a good estimate of the most frequent K tokens, using only constant-space, with the really simple space-saving algorithm from this paper.

2. Now that the first pass has given us the tokens we want to track, the second pass through the data actually builds the inverted index. That is, it builds a map from every token to the list of documents that contain that token, called a postings list. When a client wants to find only documents that contain some set of words/tokens, they download the list for each individual token and intersect them. It sounds less efficient than it is -- in reality, the postings lists are unnoticeably small (<30kb) even in the worst case. And the browser can 'pipeline' the requests for the postings lists (meaning, send them all off at once) which makes getting a response to several requests about as fast as getting a response to one.

We also store some simple statistics in each postings list to help rank the results. Essentially, documents that contain a query token more often are ranked higher than those that don't. And among the tokens in a query, those tokens that occur in fewer documents have a stronger effect on ranking than tokens that occur in many documents. That's why when I search for "AES SIV" the first result that comes back is:

• "Why is SIV a thing if MAC-and-encrypt is not the most secure way to go?"

while the following is the fourth result, even though it has a higher score and greater number of total hits than first result:

• "Why is AES-SIV not used, but AESKW, AKW1?"

(AES is a very popular and frequently discussed encryption algorithm, while SIV is a lesser-known way of using AES.)

But this is what really makes it special: because the search index is stored in IPFS, the user can convince themselves that no results have been modified, re-arranged, or omitted without having to download the entire corpus. There's one small trick to making this statement hold true: All requests made by the search client must succeed, and if they don't, it outputs an error and no search results.

To understand why this is necessary, think about the search client when it first gets the user's query. It has to tokenize the query and decide which postings lists to download, where not all words in the user's query may be indexed. A naive solution is to try to download the postings list for every word unconditionally, and interpret a non-200 HTTP status code as "this postings list must not exist". In this case, a network adversary could block the search client from being able to access postings lists that lead to undesirable results, causing the client to output misleading search results either through omission or re-arranging.

What we do instead is store the dictionary of every indexed token in a file in the root of the index. The client can download the dictionary once, cache it, and use it for every search afterwards. This way, the search client can consult the dictionary to find out which requests should succeed and only send those.

We were incredibly excited when we realized the new avenues and types of applications that combining IPFS with Cloudflare open up. Of course, our IPFS gateway and the browser extension we built will need time to mature into a secure and reliable platform. But the ability to securely deliver web pages through third-party hosting providers and CDNs is incredibly powerful, and its something cryptographers and internet security professionals have been working towards for a long time. As much fun as we had building it, we're even more excited to see what you build with it.

Subscribe to the blog for daily updates on our announcements.

Today we’re excited to introduce Cloudflare’s IPFS Gateway, an easy way to access content from the InterPlanetary File System (IPFS) that doesn’t require installing and running any special software on your computer. We hope that our gateway, hosted at cloudflare-ipfs.com, will serve as the platform for many new highly-reliable and security-enhanced web applications. The IPFS Gateway is the first product to be released as part of our Distributed Web Gateway project, which will eventually encompass all of our efforts to support new distributed web technologies.

This post will provide a brief introduction to IPFS. We’ve also written an accompanying blog post describing what we’ve built on top of our gateway, as well as documentation on how to serve your own content through our gateway with your own custom hostname.

Usually, when you access a website from your browser, your browser tracks down the origin server (or servers) that are the ultimate, centralized repository for the website’s content. It then sends a request from your computer to that origin server, wherever it is in the world, and that server sends the content back to your computer. This system has served the Internet well for decades, but there’s a pretty big downside: centralization makes it impossible to keep content online any longer than the origin servers that host it. If that origin server is hacked or taken out by a natural disaster, the content is unavailable. If the site owner decides to take it down, the content is gone. In short, mirroring is not a first-class concept in most platforms (Cloudflare’s Always Online is a notable exception).

The InterPlanetary File System aims to change that. IPFS is a peer-to-peer file system composed of thousands of computers around the world, each of which stores files on behalf of the network. These files can be anything: cat pictures, 3D models, or even entire websites. Over 5,000,000,000 files had been uploaded to IPFS already.

There are two key differences between IPFS and the web as we think of it today.

The first is that with IPFS anyone can cache and serve any content—for free. Right now, with the traditional web, most typically rely on big hosting providers in remote locations to store content and serve it to the rest of the web. If you want to set up a website, you have to pay one of these major services to do this for you. With IPFS, anyone can sign up their computer to be a node in the system and start serving data. It doesn’t matter if you’re working on a Raspberry Pi or running the world’s biggest server. You can still be a productive node in the system.

The second key difference is that data is content-addressed, rather than location-addressed. That’s a bit of a subtle difference, but the ramifications are substantial, so it’s worth breaking down.

Currently, when you open your browser and navigate to example.com, you’re telling the browser “fetch me the data stored at example.com’s IP address” (this happens to be 93.184.216.34). That IP address marks where the content you want is stored in the network. You then send a request to the server at that IP address for the “example.com” content and the server sends back the relevant information. So at the most basic level, you tell the network where to look and the network sends back what it found.

IPFS turns that on its head.

With IPFS, every single block of data stored in the system is addressed by a cryptographic hash of its contents, i.e., a long string of letters and numbers that is unique to that block. When you want a piece of data in IPFS, you request it by its hash. So rather than asking the network “get me the content stored at 93.184.216.34,” you ask “get me the content that has a hash value of QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy.” (QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy happens to be the hash of a .txt file containing the string “I’m trying out IPFS”).

Remember that with IPFS, you tell the network what to look for, and the network figures out where to look.

First off, it makes the network more resilient. The content with a hash of QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy could be stored on dozens of nodes, so if one node that was caching that content goes down, the network will just look for the content on another node.

Second, it introduces an automatic level of security. Let’s say you know the hash value of a file you want. So you ask the network, “get me the file with hash QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy” (the example.txt file from above). The network responds and sends the data. When you receive all the data, you can rehash it. If the data was changed at all in transit, the hash value you get will be different than the hash you asked for. You can think of the hash as like a unique fingerprint for the file. If you’re sent back a different file than you were expecting to receive, it’s going to have a different fingerprint. This means that the system has a built-in way of knowing whether or not content has been tampered with.

A Note on IPFS Addresses and Cryptographic Hashes

Since we’ve spent some time going over why this content-addressed system is so special, it’s worth talking a little bit about how the IPFS addresses are built. Every address in IPFS is a multihash, which means that the address combines information about both the hashing algorithm used and the hash output into one string. IPFS multihashes have three distinct parts: the first byte of the mulithash indicates which hashing algorithm has been used to produce the hash; the second byte indicates the length of the hash; and the remaining bytes are the value output by the hash function. By default, IPFS uses the SHA-256 algorithm, which produces a 32-byte hash. This is represented by the string “Qm” in Base58 (the default encoding for IPFS addresses), which is why all the example IPFS addresses in this post are of the form “Qm…”.

While SHA-256 is the standard algorithm used today, this multihash format allows the IPFS protocol to support addresses produced by other hashing algorithms. This allows the IPFS network to move to a different algorithm, should the world discover flaws with SHA-256 sometime in the future. If someone hashed a file with another algorithm, the address of that file would start some characters other than “Qm”.

The good news is that, at least for now, SHA-256 is believed to have a number of qualities that make it a strong cryptographic hashing algorithm. The most important of these is that SHA-256 is collision resistant. A collision occurs when there are two different files that produce the same hash when run through the SHA-256 algorithm. To understand why it’s important to prevent collisions, consider this short scenario. Imagine some IPFS user, Alice, uploads a file with some hash, and another user, Bob, uploads a different file that happens to produce the exact same hash. If this happened, there would be two different files in the network with the exact same address. So if some third person, Carol, sent out an IPFS request for the content at that address, she wouldn't necessarily know whether she was going to receive Bob’s file or Alice’s file.

SHA-256 makes collisions extremely unlikely. Because SHA-256 computes a 256-bit hash, there are 2^256 possible IPFS addresses that the algorithm could produce. Hence, the chance that there are two files in IPFS that produce a collision is low. Very low. If you’re interested in more details, the birthday attack Wikipedia page has a cool table showing exactly how unlikely collisions are, given a sufficiently strong hashing algorithm.

Now that we’ve walked through all the details of what IPFS is, you’re probably wondering how to use it. There are a number of ways to access content that’s been stored in the IPFS network, but we’re going to address two popular ones here. The first way is to download IPFS onto your computer. This turns your machine into a node of the IPFS network, and it’s the best way to interact with the network if you want to get down in the weeds. If you’re interested in playing around with IPFS, the Go implementation can be downloaded here.

But what if you want access to content that’s stored on IPFS without the hassle of operating a node locally on your machine? That’s where IPFS gateways come into play. IPFS gateways are third-party nodes that fetch content from the IPFS network and serve it to you over HTTPS. To use a gateway, you don’t need to download any software or type any code. You simply open up a browser and type in the gateway’s name and the hash of the content you’re looking for, and the gateway will serve the content in your browser.

Say you know you want to access the example.txt file from before, which has the hash QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy, and there’s a public gateway that is accessible at https://example-gateway.com

To access that content, all you need to do is open a browser and type

https://example-gateway.com/ipfs/QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy

and you’ll get back the data stored at that hash. The combination of the /ipfs/ prefix and the hash is referred to as the file path. You always need to provide a full file path to access content stored in IPFS.

At the most basic level, you can access any of the billions of files stored on IPFS from your browser. But that’s not the only cool thing you can do. Using Cloudflare’s gateway, you can also build a website that’s hosted entirely on IPFS, but still available to your users at a custom domain name. Plus, we’ll issue any website connected to our gateway a free SSL certificate, ensuring that each website connected to Cloudflare's gateway is secure from snooping and manipulation. For more on that, check out the Distributed Web Gateway developer docs.

A fun example we’ve put together using the Kiwix archives of all the different StackExchange websites and build a distributed search engine on top of that using only IPFS. Check it out here.

IPFS is a peer-to-peer network, so there is the possibility of users sharing abusive content. This is not something we support or condone. However, just like how Cloudflare works with more traditional customers, Cloudflare’s IPFS gateway is simply a cache in front of IPFS. Cloudflare does not have the ability to modify or remove content from the IPFS network. If any abusive content is found that is served by the Cloudflare IPFS gateway, you can use the standard abuse reporting mechanism described here.

IPFS is only one of a family of technologies that are embracing a new, decentralized vision of the web. Cloudflare is excited about the possibilities introduced by these new technologies and we see our gateway as a tool to help bridge the gap between the traditional web and the new generation of distributed web technologies headlined by IPFS. By enabling everyday people to explore IPFS content in their browser, we make the ecosystem stronger and support its growth. Just like when Cloudflare launched back in 2010 and changed the game for web properties by providing the security, performance, and availability that was previously only available to the Internet giants, we think the IPFS gateway will provide the same boost to content on the distributed web.

Dieter Shirley, CTO of Dapper Labs and Co-founder of CryptoKitties said the following:

We’ve wanted to store CryptoKitty art on IPFS since we launched, but the tech just wasn’t ready yet. Cloudflare’s announcement turns IPFS from a promising experiment into a robust tool for commercial deployment. Great stuff!

The IPFS gateway is exciting, but it’s not the end of the road. There are other equally interesting distributed web technologies that could benefit from Cloudflare’s massive global network and we’re currently exploring these possibilities. If you’re interested in helping build a better internet with Cloudflare, we’re hiring!

Subscribe to the blog for daily updates on our announcements.

We began supporting the DNS Certification Authority Authorization (CAA) Resource Record in June behind a beta flag. Our goal in doing so was to see how the presence of these records would affect SSL certificate issuance by publicly-trusted certification authorities. We also wanted to do so in advance of the 8 September 2017 enforcement date for mandatory CAA checking at certificate issuance time, without introducing a new and externally unproven behavior to millions of Cloudflare customers at once. This beta period has provided invaluable insight as to how CAA records have changed and will continue to change the commercial public-key infrastructure (PKI) ecosystem.

As of today, we’ve removed this beta flag and all users are welcome to add CAA records as they see fit—without having to first contact support. Note that if you’ve got Universal SSL enabled, we’ll automatically augment your CAA records to allow issuance from our CA partners; if you’d like to disable Universal SSL and provide your own certificates, you’re welcome to do that too.Below are some additional details on CAA, the purpose of this record type, and how its use has evolved since it was first introduced. If you’d rather just jump to the details of our implementation, click here and we’ll take you to the relevant section of the post.

Before diving into CAA it’s helpful to understand the purpose of a public key infrastructure (PKI). Quite simply, PKI is a framework that’s used to secure communications between parties over an insecure public network. In “web PKI”, the PKI system that’s used to secure communications between your web browser and this blog (for example), the TLS protocol is used with SSL certificates and private keys to protect against eavesdropping and tampering.

While TLS handles the sanctity of the connection, ensuring that nobody can snoop on or mess with HTTPS requests, how does your browser know it’s talking to the actual owner of blog.cloudflare.com and not some imposter? Anyone with access to OpenSSL or a similar tool can generate a certificate purporting to be valid for this hostname but fortunately your browser only trusts certificates issued (or “signed by”) by certain well-known parties.

These well-known parties are known as certification authorities (CAs). The private and public key that form the certificate for blog.cloudflare.com were generated on Cloudflare hardware, but the stamp of approval—the signature—was placed on the certificate by a CA. When your browser receives this “leaf” certificate, it follows the issuer all the way to a “root” that it trusts, validating the signatures along the way and deciding whether to accept the certificate as valid for the requested hostname.

Before placing this stamp of approval, CAs are supposed to take steps to ensure that the certificate requester can demonstrate control over the hostname. (In some cases, as you’ll learn below, this is not always the case, and is one of the reasons that CAA was introduced.)

Given that people are imperfect beings and prone to making mistakes or poor judgement calls, it should come to the surprise of no one that the PKI ecosystem has a fairly blemished track-record when it comes to maintaining trust. Clients, CAs, servers, and certificate requesters are all created or operated by people who have made mistakes.

Jurassic Park. 1993, Stephen Spielberg [Film] Universal Pictures.

Client providers have been known to add compromising certificates to the local trust store or install software to intercept secure connections; servers have been demonstrated to leak private keys or be unable to properly rotate session ticket keys; CAs have knowingly mis-issued certificates or failed to validate hostname ownership or control reliably; and individuals requesting certificates include phishers creating convincing imposter versions of popular domains and obtaining valid and trusted certificates. Every party in this ecosystem is not completely without blame in contributing to a diminished sense of trust.

Of these many problems (most of which have already been addressed or are in the process of being resolved), perhaps the most unsettling is the willful mis-issuance of certificates by trusted CAs. Knowingly issuing certificates to parties who haven't demonstrated ownership, or issuance outside the parameters defined by the CA/Browser Forum (a voluntary and democratic governing body for publicly-trusted certificates) by CAs who have certificates present in trust stores severely undermines the value of that trust store, all certificates issued by that CA, and the publicly-trusted PKI ecosystem as a whole.

To help prevent future mis-issuance by publicly trusted CAs, a new DNS resource record was proposed by those CAs to help reduce the risk of certificate mis-issuance: The Certification Authority Authorization (CAA) Resource Record.

The general idea is that the owner of any given domain (e.g., example.com) would add CAA records at their authoritative DNS provider, specifying one or more CAs who are authorized to issue certificates for their domain.

RFC6844 currently specifies three property tags for CAA records: issue, issuewild, and iodef.

• The issue property tag specifies CAs who are authorized to issue certificates for a domain. For example, the record example.com. CAA 0 issue "certification-authority.net" allows the "Certification Authority" CA to issue certificates for example.com.

• The issuewild property tag specifies CAs that are only allowed to issue certificates that specify a wildcard domain. E.g., the record example.com. CAA 0 issuewild "certification-authority.net" only allows the "Certification Authority" CA to issue certificates containing wildcard domains, such as *.example.com.

• The iodef property tag specifies a means of reporting certificate issue requests or cases of certificate issuance for the corresponding domain that violate the security policy of the issuer or the domain name holder. E.g., the record example.com. CAA 0 iodef "mailto:example@example.com" instructs the issuing CA to send violation reports via email to the address provided at the attempted time of issuance.

CAA records with the issue and issuewild tags are additive; if more than one are returned as the response for a DNS query for a given hostname, the CAs specified in both records are both considered authorized.

If the authoritative DNS provider does not yet support CAA records or none are present in the zone file, the issuing CA is still authorized to issue when no records are present, largely preserving the issuance behavior before CAA records were an adopted standard.

As of 8 September 2017, all publicly-trusted CAs are now required to check CAA at issuance time for all certificates issued, thereby enabling certificate requestors (domain owners) to dictate which CAs can issue certificates for their domain.

RFC6844 specifies a very curious CAA record processing algorithm:

The search for a CAA record climbs the DNS name tree from the
   specified label up to but not including the DNS root '.'.

   Given a request for a specific domain X, or a request for a wildcard
   domain *.X, the relevant record set R(X) is determined as follows:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA(X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

While the above algorithm is not easily understood at first, the example immediately following it is much easier to comprehend:

For example, if a certificate is requested for X.Y.Z the issuer will
   search for the relevant CAA record set in the following order:

      X.Y.Z

      Alias (X.Y.Z)

      Y.Z

      Alias (Y.Z)

      Z

      Alias (Z)

      Return Empty

In plain English, this means that if the owner of example.com requests a certificate for test.blog.example.com, the issuing CA must

1. Query for a CAA record at test.blog.example.com.. If a CAA record exists for this hostname, the issuing CA stops checking for CAA records and issues accordingly. If no CAA record exists for this hostname and this hostname exists as an A or AAAA record, the CA then moves up the DNS tree to the next highest label.

2. Query for a CAA record at blog.example.com.. Just like the first check, if no CAA record exists for this hostname and this hostname exists as an A or AAAA record, the CA then continues traversing the DNS tree.

3. Query for a CAA record at example.com.

4. Query for a CAA record at com.

At the end of the last step, the issuing CA has climbed the entire DNS tree (excluding the root) checking for CAA records. This functionality allows a domain owner to create CAA records at the root of their domain and have those records apply to any and all subdomains.

However, the CAA record processing algorithm has an additional check if the hostname exists as a CNAME (or DNAME) record. In this case, the issuing CA must also check the target of the CNAME record. Revisiting the example above for test.blog.example.com. where this hostname exists as a CNAME record, the issuing CA must

1. Query for a CAA record at test.blog.example.com.. Since test.blog.example.com. exists as the CNAME test.blog.example.com. CNAME test.blog-provider.net., the issuing CA must next check the target for the presence of a CAA record before climbing the DNS tree.

2. Query for a CAA record at test.blog-provider.net.

The issuing CA in this example is only at step two in the CAA processing algorithm and it has already come across two separate issues.

First, the issuing CA has checked the hostname requested on the certificate (test.blog.example.com.) and since that hostname exists as a CNAME record, it has also checked the target of that record (test.blog-provider.net.). However, if test.blog-provider.net. itself is also a CNAME record, the the CAA record processing algorithm states that the issuing CA must check the target of that CNAME as well.

In this case it is fairly simple to create a CNAME loop (or very long CNAME chain) either via an accidental misconfiguration or with malicious intent to prevent the issuing CA from completing the CAA check.

Second, example.com and blog-provider.net might not be owned and operated by the same entity or even exist in the same network. The RFC authors appear to be operating under the assumption that CNAME records are still used as they were in November 1987:

A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR.

This behavior may have been true thirty years ago, but consider the number and prevalence of SaaS providers in 2017; who truly is authoritative for the content addressed by a DNS record, the content creator (and likely domain name owner who is using a CNAME) or the SaaS provider to whom the content creator subscribes?

Many if not all major service or application providers include clauses in their respective terms of service with regards to content added by the user to their account for the service. Intellectual property must be user-generated, properly licensed, or otherwise lawfully obtained. As content uploaded by users is difficult to control, liability limitations, indemnification, and service termination are all commonly used when the intellectual property added to the service is owned by another party, is unlawful, or is outside the definition of acceptable use. From a content perspective within the scope of a service provider's terms of service, it’s difficult to consider the service provider canonical for the content hosted there.

Using a real world example, there are currently 401,716 CNAME records in the zone files for domains on Cloudflare whose target is ghs.google.com. This hostname is given to subscribers of Google's Blogger service to use as the target of a CNAME so that a Blogger subscriber may use their own domain name in front of Google's service. With one CAA record, Google could dictate that nearly half a million blogs with a vanity domain name can only have one CA or no CAs issue certificates unless each of those hostnames created their own CAA records to allow issuance.

Even without following CNAMEs to their targets, the DNS climbing algorithm is not unproblematic. Operators of top-level domains may decide that only certain issuing CAs are trustworthy or certain CAs are advantageous for business and create CAA records only allowing those CAs to issue. We already see this in action today with the pseudo-top level domain nl.eu.org which has the CAA record nl.eu.org. CAA 0 issue "letsencrypt.org", which only allows issuance through Let's Encrypt without CAA records being present at the subdomains of nl.eu.org.

The authors of RFC6844 were also unwilling to secure their record and its use from any potential on-path attacks—

Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required.

Without DNSSEC, DNS responses are returned to the requestor in plain-text. Anyone in a privileged network position (a recursive DNS provider or ISP) could alter the response to a CAA query to allow or deny issuance as desired. As only about 820,000 .com domain names out of the more than 130 million registered .com domain names are secured with DNSSEC, perhaps the low adoption rates influenced the decision to not make DNSSEC with CAA mandatory.

Moving beyond the RFC, the CA/Browser Forum's Baseline Requirements (BR) attempt to clarify aspects regarding the behavior a CA should take when checking for CAA.

CAs are permitted to treat a record lookup failure as permission to issue if:

• the failure is outside the CA's infrastructure;

• the lookup has been retried at least once; and

• the domain's zone does not have a DNSSEC validation chain to the ICANN root

Effectively, this means that if the CAA response is either a SERVFAIL, REFUSED, or the query times out, regardless of whether or not a CAA record exists, the CA is permitted to issue if this query fails more than once while attempting to issue a certificate. However, multiple CAs have told us that DNS lookup failures will prevent issuance regardless of the above conditions in the BR. In this case, something as benign as a transient network error could result in a denial of issuance or worse, any recursor that doesn’t understand and a query for CAA record will prevent issuance. We actually saw this with Comcast’s resolvers and reported the bug to their DNS provider.

There’s an additional security gap in that neither the RFC nor the BR indicate where the issuing CA should query for CAA records. It is acceptable within the current standards to query any DNS recursor for these records as well as the authoritative DNS provider for a domain. For example, an issuing CA could query Google’s Public DNS or a DNS recursor provided by their ISP for these responses. This enables compromised DNS recursors or one run by a rogue operator to alter these responses, either denying issuance or allowing issuance by a CA not approved by the domain owner. The RFC and BR should be amended so that an issuing CA must always query these records at the authoritative provider to close this gap.

As of today, CAA records are no longer in beta and all customers are able to add CAA records for their zones. This can be done in the DNS tab of the Cloudflare dashboard or via our API.

When creating CAA records in the dashboard, an additional modal appears to help clarify the different CAA tag options and format the record correctly as an incorrectly formatted record would result in every CA not being able to issue a certificate.

Cloudflare is in a unique position to be able to complete SSL validation for a domain and have certificates issued on the domain owner's behalf. This is how Cloudflare is able to automatically provision and have our Universal SSL certificates issued for every domain active on Cloudflare for free.

Cloudflare partners with multiple CAs to issue certificates for our managed SSL products: Universal SSL, Dedicated Certificates, and SSL for SaaS. Since CAA record checking is now mandatory for publicly-trusted CAs, Cloudflare automatically adds the requisite CAA records to the zone when a user adds one or more CAA records in the Cloudflare dashboard for their domain in order to allow our partner CAs to continue to be able to issue certificates for each of our SSL products.

Some site owners may want to manage their own SSL certificates in order to be compliant with their own standard operating procedures or policies. Alternately, domain owners may only want to trust specific CAs that are not the CAs Cloudflare currently partners with to issue Universal SSL certificates. In the latter case, users now have the ability to disable Universal SSL.

When Universal SSL is disabled, the CAA records added to allow our partner CAs to issue certificates are deleted and all Universal SSL certificates available for the zone are removed from our edge. Dedicated certificates, custom certificates, as well as SSL for SaaS certificates are all individually managed by each customer and can be added or removed as needed.

CAA as it exists today does very little to reduce the attack surface around certificate issuance while making it more difficult for well-intended parties to participate. That said, CAA is a young standard recently adopted by the web PKI community with many involved individuals as well as active parties working toward addressing some of the gaps present in the current RFC and committed to making the overall CAA experience better for both the certificate requesters and CAs.

To start, an errata report exists to clarify the CAA record processing algorithm and to reduce the degree in which the targets of CNAME records should be checked. Similarly, the DNS tree-climbing behavior of the CAA record processing algorithm is still up for debate. There are also active discussions around implementation issues, such as the recognition that some authoritative DNS resolvers incorrectly sign empty responses to CAA queries when DNSSEC is enabled for a zone and how to handle these cases in a way that would still allow CAs to issue. Proposals exist suggesting new tags or property fields in CAA records, such as a CA requiring an account number in the property value for issue tags, or only allowing specific validation types (e.g., DV, OV, or EV). The Electronic Frontier Foundation (EFF) has expressed interest in hardening CAs against non-cryptographic attacks, particularly with a focus on the domain validation process for obtaining certificates. While not directly pertaining to CAA, any ideas or proposed hardening solutions might increase reliance on CAA or completely obviate the need for it altogether.

CC BY-NC 2.5 by xkcd.com

As with all internet standards, none are perfect and all are far from permanent—CAA included. Being in the position to implement new standards at scale, seeing what effect adoption of those standards has, and working with the Internet community to address any issues or gaps is a privilege and allows us to live up to our mission of building a better Internet.

We're thrilled to be involved in efforts to make CAA (and any other standard) better for anyone and everyone.

CC BY 2.0 image by JD Hancock

When you complete the sign-up process, we batch your domain together with a few dozen other recently signed-up domains, and fire off a request to one of our Certificate Authority (CA) partners. The CA then sends us back a shared certificate covering the root (e.g. example.com) and top-level wildcard (e.g. *.example.com) of your domain, along with the hostnames of the other customers in the request. We then package this shared certificate with its encrypted private key and distribute it to our datacenters around the world, ensuring that your visitors’ HTTPS sessions are speedy no matter where they originate.

Since that process was created, we have used it to secure millions of domains with free Universal SSL certificates and helped make the Internet a faster and more secure place.

But along the way we heard from customers who wanted more control over the certificates used for their domains. They want control of when they’re issued, whether other customers’ (or Cloudflare’s) hostnames appear on them, the breadth of subdomains they protect and which SSL/TLS versions and encryption options they support.

In short, customers want a service that provides a non-shared, customizable certificate for their domain.

CC BY 2.0 image by JD Hancock

Perhaps the most common request we heard was "I love your Universal SSL product, but how can I use it on my website in a way that the certificate shows my domain name instead of cloudflaressl.com? And how can I prevent the certificate from being shared with other customers (all without upgrading my plan)?".

A close second was “*Why do I have to disable Cloudflare on my extra.long.name.example.com or risk my users experiencing browser errors? Your Universal SSL certificates cover only one level of wildcard but I also want my hosts at .staging.example.com protected.”

Lastly, as we’ve rolled out exciting encryption features like TLS 1.3, Automatic HTTPS Rewrites, Opportunistic Encryption, we’ve heard that you want granular control over which certificates and subdomains have these new features enabled.

Today we’re excited to announce two new products to meet all of these needs and many more to come: Dedicated SSL Certificates and Dedicated SSL Certificates with Custom Hostnames. These new certificate offerings are issued on-demand, with a new private key generated exclusively for your domain, and branded prominently with your domain name.

A customer owning the domain dedicatedcerts.xyz would have shared certificate with a name like ssl329744.cloudflaressl.com under Universal SSL, but their own certificate with Dedicated SSL Certificates.

Dedicated Certificate as rendered in Google Chrome

Universal SSL Certificate as rendered in Google Chrome

Dedicated Certificates combine the benefits of Universal SSL certificates—automated renewal and rapid revocation/reissuance to address nascent crypto vulnerabilities—without having to upload (and manage the renewal of) certificates purchased elsewhere.

They’re also the first step in our plan to provide true subdomain-level customization of your HTTPS settings, whether requiring Modern TLS or selectively enabling new and upcoming features such as Automatic HTTPS Rewrites or HTTPS from within China using separate keys.

Unlike custom certificates that you acquire and upload yourself, Dedicated Certificates free you from the complexity and monotony of safely generating and storing private keys; crafting certificate signing requests (CSRs); requesting, downloading, and building certificate chains; and regularly renewing and re-installing certificates on your server. Why risk letting a certificate expire and show errors to users, or not reissuing your key pair fast enough when the next Heartbleed pops up?

The process is incredibly easy and quick. Simply log in to the Cloudflare Dashboard, click on the Crypto tab, and then click the "Order SSL Certificate" button. You’ll be asked whether you need to add custom hostnames, given a chance to input them, and then confirm your billing information. The cost for a Dedicated Certificate is $5 per month and the cost of a Dedicated Certificate with Custom Hostnames is $10 per month.

As soon as you hit "Next" we’ll validate your domain name with one of our Certificate Authorities, charge your account for the remainder of the month, and then order the certificate and distribute it to our edge. The whole process takes just a minute or two to order and send your certificate to all 100 of our datacenters, where it’ll be ready and waiting to accelerate and protect your visitors’ HTTPS sessions.

While there are no inherent security risks with a shared certificate, we’ve heard from quite a few customers that they do not want their hostnames listed alongside the hostnames of other customers (who may be in other, entirely unrelated industries). By ordering a Dedicated Certificate you can be sure that only your hostnames appear on your certificate.

Similarly, Dedicated Certificates allows agencies, SaaS providers, and other businesses to isolate their customers onto separate certificates—a must for those serving competitive firms in the same industry. If you currently serve customer1 and customer2 on a sub-domain of your zone, example.com, you can issue a separate certificate to each, guaranteeing that neither customers’ domain name appears on the other’s certificate.

Universal SSL certificates are issued using a common name that is a concatenation of "ssl", a six-digit sequence number, and “.cloudflaressl.com”. For example, ssl123456.cloudflaressl.com. With Dedicated Certificates you can use your domain name in this field, and be sure that no other domains—whether an unrelated site or yours or someone else’s—are ever shown to your visitors.

Until today, if you had orange-clouded (proxied) entries in DNS for hosts such as www.staging.example.com and www.uat.example.com, you would need a Business or Enterprise plan to avoid showing your users SSL errors (that may or may not be dismissible, depending on other security settings). Using Dedicated Certificates with Custom Hostnames you can now order a certificate protecting *.staging.example.com, *.uat.example.com—with room for up to 50 total hostnames or wildcards.

Dedicated Certificates gives you control over how frequently you want their private keys to be regenerated and your certificate reissued. Want us to reissue your certificate immediately? Weekly? Simply delete it from the Edge Certificates table and request another one through our UI or API. You won’t be charged for the replacement unless you explicitly cancel your monthly subscription.

Enterprise customers that want to serve SSL within China may have concerns about using the same private key there as the one that secures their HTTPS traffic in other parts of the world. We’re looking forward to giving you control over designating a specific Dedicated SSL Certificate to be used exclusively in China.

Not a problem. Simply delete the certificate from the Edge Certificates card on the Crypto tab in your dashboard and re-order it. You will not be prompted for payment again unless you explicitly cancel the subscription from the Subscriptions page.

Yes, all Cloudflare plans can order Dedicated Certificates.

If you are a Free, Pro, or Business customer, simply follow the instructions above to place an order. If you are an Enterprise customer or want to order certificates for a Multi-User Organization, please contact your Customer Success Engineer to request that your account be provisioned with the desired number of certificates.

Note that in all cases you must have completed the onboarding process for your zone and have your nameservers pointed to Cloudflare DNS. We are working on adding support for those zones that use an external DNS provider, or have been onboarded through one of our partners.

Certificates are served in the following priority order (from highest to lowest):

1. Uploaded Certificates

2. Dedicated Certificates with Custom Hostnames

3. Dedicated Certificates

4. Universal Certificates

However, if the highest priority certificate doesn’t have a hostname matching the incoming request, we’ll move on to the next certificate. If none of the certificates can handle the request, e.g., you’re serving traffic at www.staging.example.com but haven’t purchased a Dedicated Certificate with Custom Hostnames (or uploaded a certificate to a Business or Enterprise plan), your users will see an error.

Cloudflare works with Let's Encrypt (and other CA certificates) in two ways: you can upload a Let's Encrypt certificate and we will serve it to your visitors, and when we make a connection to your origin server you can use a Let's Encrypt certificate to secure the connection.

Cloudflare's Dedicated Certificates totally automates the process of acquiring and distributing a certificate and has added advantages over using a third-party certificate.

1. We optimize the certificate chain to maximize compatibility with browsers/user agents, and deploy multiple versions of your certificate—SHA-2/ECDSA, SHA-2/RSA, and SHA-1/RSA—in a certificate pack. Based on the capabilities of the browser sending each incoming request, we’ll serve the most optimal certificate for that connection.

2. We support both custom names on the certificate and wildcard records (at multiple levels).

3. We handle renewal automatically and distributed renewed certificates without any work required by you.

Dedicated Certificates encrypt traffic between your visitors’ web browsers and Cloudflare, while Origin CA certificates encrypt traffic between Cloudflare and your (origin) server.

When a user connects to your site hosted on Cloudflare, e.g., https://www.example.com, a Dedicated Certificate will be used if it exists. When we need to fetch data from your origin server, we’ll look for an Origin CA (or other) certificate on your origin.

The two offerings are complementary and should be used together with Strict mode to create a validated, end-to-end encrypted connection.

No, these certificates are branded with the Common Name (CN) of the domain under which you placed the order. All custom hostnames or wildcard entries added must be subdomains of this parent zone.

If you would like a Dedicated Certificate for another domain, simply switch to that zone using the "Select Website" dropdown in the top-left corner of the Cloudflare Dashboard.

Want to work with the amazing group of Software Engineers and Product Designers that built this product?

We’d love to talk to you. And we’re always hiring. Reach out on whatever medium suits you, or find us at https://www.cloudflare.com/join-our-team!

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. Our situation at CloudFlare is markedly different: we affirmatively control the edge of our network so we have the flexibility to build and operate a secure CA that’s capable of issuing highly streamlined certificates and ensuring they are utilized securely.

With Origin CA, we questioned all aspects of certificate issuance and browser validation, from domain control validation (DCV) to path bundling and revocation checking. We asked ourselves what cruft public CAs would remove from certificates if they only needed to work with one browser, whose codebase they maintained? Questions such as "why bloat certificates with intermediate CAs when they only need to speak with our NGINX-based reverse proxy" and "why force customers to reconfigure their web or name server to pass DCV checks when they’ve already demonstrated control during zone onboarding?" helped shape our efforts.

The result of us asking these questions and removing anything not needed to secure the connection between our servers and yours is described below, along with the benefits you may see and the interfaces you may use. We’re excited to introduce this third option for protecting your origin—more secure than self-signed certificates and more convenient, performant, and cost effective than publicly trusted certificates—and look forward to hearing about all the various ways you may use it.

The most difficult and time-consuming part of securing your origin with TLS is obtaining—and renewing—a certificate. Or many certificates if you’re using a provider that doesn’t support wildcards. Often this process requires intimate knowledge of OpenSSL or related command line tools, a reconfiguration of your web or DNS server to accommodate domain control validation, and a regularly scheduled reminder or cron job to perform this process again every year (or even every few months). With Origin CA, we took the opportunity to remove as many of these obstacles as possible.

Customers more comfortable in the GUI can, with just two clicks, securely generate a private key and wildcard certificate that will be trusted by our systems for anywhere from 7 days to 15 years. And those who prefer more control over the process can use our API or CLI to issue certificates of specified validity, key type, and key size. Regardless of the user interface chosen, the potentially complicated validation process has been replaced by a simple API key now available in your account on the CloudFlare dashboard; we’ve already verified you control your zone, there’s no need to prove it again.

If your origin server handles traffic for more than a few hostnames, it can get unwieldy to place a long list of SANs on each certificate request. The alternative—placing just one SAN on each certificate and using Server Name Indication (SNI) extension to lazy load the correct certificate—can easily get out of hand. In this deployment scenario the number of certificates required is a non-trivial fraction of the the number of hostnames you wish to protect (not to mention you may not even be allowed to do so on shared hosts).

Beyond provisioning efforts, placing too many SANs on a single certificate can significantly increase the size of the certificate. Larger certificates consume more bandwidth at your origin (which, unlike CloudFlare, may bill you for marginal bandwidth consumption). The obvious answer for protecting more than a few hostnames (or even domains) on your origin is to use wildcard certificates. With Origin CA, you can request a single certificate containing wildcards for any and all of the zones registered in your account; you can even add wildcards covering multiple levels of a domain, e.g., *.example.com, *.secure.example.com, and *.another-example.com can all co-exist on the same certificate.

If you’ve ever tried revoking a publicly trusted certificate—or relying on browsers to distrust a revoked certificate—you know how unreliable the process can be. Take your pick of explanations from Google crypto-wunderkind Adam Langley—Revocation doesn’t work (2011); No, don’t enable revocation checking (2014); or Revocation still doesn’t work (2014)—they all reach the same conclusion: browser-based revocation checking is broken and useless without hard fails. (The advent of the OCSP Must-Staple extension should improve the situation, but if history is any indication it will be quite a while before sufficient browsers, certificate authorities, and issued certificates support it.)

Fortunately with Origin CA, we only need one "browser" to respect revocation: our edge. Failing hard—the only acceptable way to fail from a security perspective—is incredibly simple (and fast) when your user agent has an in-memory list of all valid certificates. (Try doing that with the millions of certificates issued by dozens of CAs over the past few years!) Rather than fire requests across the public Internet and praying they return quickly enough, our NGINX instances can just query a local database for each new HTTPS session and confirm in microseconds whether you’ve revoked the certificate for any reason.

And if/when the time comes to revoke, a single click and confirmation is all that’s required for our edge to distrust the certificate. If you expose or misplace your private key (and can’t find it under the couch or in the pockets of yesterday’s pants), simply navigate to the Crypto tab and click the "x" icon next to the compromised certificate. Within seconds we’ll push this revocation status worldwide and our edge servers will refuse to communicate with origins serving the revoked certificate. Such speed, security, and reliability is impossible without total control over the CA and browser ecosystem.

Even if published to the world, to abuse your CloudFlare Origin CA certificate an attacker would either need to compromise your CloudFlare account or take control of your registrar or DNS provider account. In any case, you'd have a lot more to worry about than just a compromised certificate.

While most web server operators will elect to download the default PEM format for their certificate (as expected by Apache httpd and NGINX), many others will require a different variation. As illustrated in the screenshots below, certificates can be downloaded in several different formats, including DER, the binary equivalent of PEM’s ASCII, and PKCS#7, the Microsoft IIS Server and Apache Tomcat-compatible choice. Simply pick what works for your server and download it; there’s no need to learn cryptic command-line methods for converting.

Besides additional formats, we also have instructions for a wide variety of operating systems and web servers. After generating your certificate simply select your desired destination from the 80+ different options and instructions specific to your environment will be displayed.

Before a user agent can securely transmit HTTP actions like GET and POST to a web server, it must first establish the TLS session. To do so, the client kicks off a handshake by sending its own capabilities and the server responds with the negotiated cipher suite and certificate that should be used to protect the conversation agreeing upon a symmetric key.

Until the client receives—and validates—the certificate(s) sent across the network by the origin, it is unable to complete the handshake and commence with requesting data. As such, it’s in the best interest of performance-sensitive users to make this certificate as small and unencumbered as possible. (Ideally the packet containing the certificate even fits within a single frame and is not fragmented during transmission.) One brief survey by a member of the CA/B Forum found that while the majority of certificates were between 1-2 kB, several thousand were found in the wild at least 10 kB in size, with one even over 50(!) kB.

With Origin CA certificates, we’ve stripped everything that’s extraneous to communication between our servers and yours to produce the smallest possible certificate and handshake. For example, we have no need to bundle intermediate certificates to assist browsers in building paths to trusted roots; no need to include signed certificate timestamps (SCTs) for purposes of certificate transparency and EV treatment; no need to include links to Certification Practice Statements or other URLs; and no need to listen to Online Certificate Status Protocol (OCSP) responses from third-parties.

Eliminating these unnecessary components typically found in certificates from public CAs has allowed us to reduce the size of the handshake by up to 70%, from over 4500 bytes in some cases to under 1300. You can replicate this test yourself using the following two OpenSSL s_client calls:

$ for host in google.com bing.com cloudflare.com patriots.com; do echo -en "$host\t" && openssl s_client -connect www.$host:443 -servername www.$host 2>/dev/null </dev/null | grep "has read"; done
google.com      SSL handshake has read 3747 bytes and written 497 bytes
bing.com        SSL handshake has read 4252 bytes and written 583 bytes
cloudflare.com  SSL handshake has read 3845 bytes and written 501 bytes
patriots.com    SSL handshake has read 4507 bytes and written 499 bytes

$ openssl s_client -connect [ORIGIN_IP]:443 -servername [ORIGIN_HOSTNAME] 2>/dev/null </dev/null | grep "has read"
SSL handshake has read 1289 bytes and written 496 bytes

Now that you've learned why you may want to use Origin CA-issued certificates on your origin, let’s explore the various interfaces you have for issuing (and revoking) them. Effective immediately, certificates for your origin can be issued in an automated fashion through our API or CLI, or through a guided wizard in the Crypto app on the CloudFlare Dashboard. Each of the three available methods is described below along with examples:

To get started, login to the dashboard and click on the Crypto icon.

Next, scroll down to the Origin Certificates card and click the "Create Certificate" button.

At this point, you must decide whether you wish to provide your own certificate signing request (CSR) or let your browser create one using its cryptographic libraries.

If you’ve already generated a private key and CSR, select the radio button labeled "I have my own CSR" and paste the CSR contents into the textbox that appears. Alternatively, leave the default option of “Let CloudFlare generate a key pair using my browser” selected. (If you are accessing the dashboard using an older browser, i.e., one that does not support Web Crypto API, you will only see one option.)

By default, the list of hostnames your origin certificate covers includes the apex of the currently selected zone (example.com) and one level of wildcard (*.example.com). If you’d like to protect additional hostnames outside this list (e.g., *.secure.example.com), simply type them in the input box at the bottom of the modal. You may add up to 100 hostnames (or wildcards) on a single certificate, spanning multiple zones, provided they are for zones active in your account. Please keep in mind that each additional SAN increases the size of your certificate, so applications requiring frequent updates to the origin (and thus TLS handshakes) you should use as few SANs as possible.

After entering additional hostnames (or confirming the defaults will suffice), click Next and your certificate will be generated. By default, it will be displayed in PEM format, which is what web servers such as Apache httpd and NGINX expect. If you require an alternative format, such as PKCS#7 for Microsoft’s IIS or Apache Tomcat, change the dropdown box appropriately and save the contents to your server. Or if you’d like to use a binary format such as DER, select that and click the download button.

Lastly, choose your web server from the select box at the bottom of the window and click "Show instructions". Doing so will open installation instructions in a new browser window that, once followed, will allow you to adjust your SSL setting (at the top of the Crypto app) to "Strict" mode.

If you would like to automate the process of issuing certificates for your origin, or require more control over the parameters (e.g., shorter-lived certificates, greater key size, etc.), you can make use of our certificates API endpoint.

Before calling the API you will first need to generate a certificate signing request. To do so, you can use cfssl or OpenSSL. Instructions for the former can be found here, while our friends at DigiCert have provided an easy-to-use wizard for the latter. Don't worry about including subject alternative names (SANs) in the CSR — we’ll take those in separately through the JSON payload.

$ openssl req -new -newkey rsa:2048 -nodes -out www_example_com.csr -keyout www_example_com.key -subj "/C=US/ST=California/L=/O=/CN=www.example.com"
Generating a 2048 bit RSA private key
.............................+++
.....................................................................................................................................+++
writing new private key to 'www_example_com.key'

Log in to the CloudFlare dashboard, and click My Settings under your username in the top-right  hand corner. Scroll down to the API Key panel and click "View API Key".

Click within the window that pops up and then copy the contents that is auto-selected to your clipboard. Save the key to an environment variable as it will be used in the subsequent curl command.

$   export CF_API_KEY="v1.0-c9..."

Note that you will need to remove newlines from the CSR as newlines are not permitted in JSON and add them back into the certificate that’s returned. When you remove them you should replace the newline character (hex code 0A) with the string "\n".

$ curl -sX POST https://api.cloudflare.com/client/v4/certificates/ \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "X-AUTH-USER-SERVICE-KEY: $CF_API_KEY" \
--data '{"hostnames":["example.com","*.example.com"],"requested_validity":"365","request_type":"origin-rsa","csr":"-----BEGIN CERTIFICATE REQUEST-----...-----END CERTIFICATE REQUEST-----"}'

{
  "success": true, "errors": [], "messages": [],
  "result": {
    "id": "0x47530d8f561faa08",
    "certificate": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----",
    "hostnames": [ "example.com", "*.example.com" ],
    "expires_on": "2014-01-01T05:20:00.12345Z",
    "request_type": "origin-rsa",
    "requested_validity": "365",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----...-----END CERTIFICATE REQUEST-----"
  }
}

Lastly, if you’re using a Linux platform that supports RPM or DEB packages, the easiest way to request certificates is with the Origin CA CLI. Before proceeding, make sure you follow the instructions above in the API example to save your API key in the CF_API_KEY environment variable.

To get started, browse to https://pkg.cloudflare.com/ and follow the instructions to add the CloudFlare Package Repository to your system. With the new package server in place, use apt or yum to install the "cfca" package (binary placed in /usr/local/bin on DEbian, e.g.,) and then issue a certificate in a manner similar to the following examples:

$ /usr/local/bin/cfca getcert -hostnames example.com,*.example.com
2016/04/25 19:47:23 [INFO] generate received request
2016/04/25 19:47:23 [INFO] received CSR
2016/04/25 19:47:23 [INFO] generating key: rsa-2048
2016/04/25 19:47:24 [INFO] encoded CSR
2016/04/25 19:47:24 [INFO] Connecting to https://api.cloudflare.com/client/v4/certificates/
2016/04/25 19:47:25 [INFO] Successfully issued certificate for:
*.example.com
example.com
2016/04/25 19:47:25 [INFO] Saved generated private key to wildcard.example.com.key
2016/04/25 19:47:25 [INFO] Saved issued certificate to wildcard.example.com.pem

$ /usr/local/bin/cfca getcert -days 7 -hostnames *.foo.com,*.bar.com -key-type ecdsa -key-size 256
2016/04/26 12:24:24 [INFO] generate received request
2016/04/26 12:24:24 [INFO] received CSR
2016/04/26 12:24:24 [INFO] generating key: ecdsa-256
2016/04/26 12:24:24 [INFO] encoded CSR
2016/04/26 12:24:24 [INFO] Connecting to https://api.cloudflare.com/client/v4/certificates/
2016/04/26 12:24:28 [INFO] Successfully issued certificate for:
*.foo.com
*.bar.com
2016/04/26 12:24:28 [INFO] Saved generated private key to wildcard.foo.com.key
2016/04/26 12:24:28 [INFO] Saved issued certificate to wildcard.foo.com.pem

$ cat wildcard.foo.com.pem | openssl x509 -noout -text | grep "Not After\|Public Key Algorithm\|DNS"
Not After : May  3 19:19:00 2016 GMT
Public Key Algorithm: id-ecPublicKey
DNS:*.foo.com, DNS:*.bar.com

As you use Origin CA to generate certificates and secure your origin servers, keep these recommendations in mind:

1. Use Origin CA to generate certificates for your origin servers, using wildcards for each zone to keep SANs to a minimum.

2. Upgrade each zone’s SSL setting from "Flexible" or "Full" to "Strict" mode you have Origin CA or public CA certificates installed protecting all hostnames in that zone.

3. If you were previously enrolled in our beta Origin CA program, you should issue new certificates so they include revocation endpoints.

4. When pausing CloudFlare or gray-clouding individual zones, be aware that you and your visitors may receive errors in their browsers until you orange-cloud (reverse proxy) them again.

If you encounter any difficulty issuing certificates, or have any other concerns or suggestions, please open a support ticket and we will be happy to assist you.

We’re at the cPanel Conference in Denver this week, so feel free to drop by our booth and say hello. It’s a great opportunity to connect with our partners and better understand their needs. We’re always trying to streamline our partners’ user experience, and we thought it would be a fitting time to walk through our recently updated WHMCS integration.

CloudFlare’s WHMCS 6.0 plugin lets hosting providers and registrars extend all the benefits of CloudFlare directly to their customers. You can offer your entire user base a global CDN with 62 points of presence, automatic web content optimization, basic DDoS protection, reputation-based threat protection, and much more with virtually no extra work.

These benefits are seamlessly integrated into your WHMCS client. All your customers need to do is click a button, and a new CloudFlare account will be configured for them.

While signing up for an account on www.cloudflare.com only takes a few minutes, users do need to point the relevant DNS records to CloudFlare’s nameservers. Offerring a one-click solution via our WHMCS integration is a great opportunity for hosting providers and registrars to streamline the process for their customers.

CloudFlare’s Universal SSL offering provides free SSL encryption to all customers on its network. However, as a partner, Universal SSL is only available with full DNS integration (opposed to CNAME integration). Our WHMCS module comes with full DNS integration built-in, making it the fastest way to get up and running with Universal SSL.

So, in addition to the performance and basic security benefits of CloudFlare, you can also offer free SSL encryption to all of your customers.

Becoming a partner means you can offer your customers faster and more secure websites than providers that don’t have a CloudFlare integration.

To integrate CloudFlare into your WHMCS solution, start by visiting our partners page and telling us a little bit about your company. We’ll provide an API key that you can use to install our WHMCS module. For technical questions related to our integrations, please email us at partnersupport@cloudflare.com.

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.

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 for their websites to ensure their visitors get the strongest data security possible.

As we previously discussed, sites on CloudFlare’s Free plan default to Flexible SSL mode. To take advantage of our Strict SSL mode it’s necessary to install a certificate on the origin server, which until now required them to buy one from a third party. Now customers can get that certificate directly from CloudFlare, for free.

This certificate is only used to protect the traffic between the origin server and CloudFlare; it is never presented to browsers. For now you should only use it behind orange-clouded sites on CloudFlare.

If you are a CloudFlare customer and want to sign up for the beta, just send an email to origin-ca-beta@cloudflare.com with the following:

• A certificate signing request (CSR)

• The domain name of the orange-clouded zone you want to install the certificate on

The first ten brave beta customers will get a shiny new certificate to install on their web server. Note: do not send your private key to CloudFlare, only the CSR is needed.

Update: The beta is full! Thanks to those who are participating.

In order to grant certificates to customer origins, CloudFlare had to create its own Certificate Authority. This consists of a set of processes and systems to validate certificate requests and create new certificates. For the Origin CA, CloudFlare created a private key and certificate for the specific purpose of signing certificates for origin servers.

The certificate authority software we use is CFSSL, our open source PKI toolkit written in Go. It allows us to validate CSRs and use them to create new certificates for sites. These certificates are signed with our certificate authority private key, and validated when CloudFlare connects to the origin in Strict SSL mode.

In collaboration with other members of the industry (such as Richard Barnes from the Let's Encrypt project), we have updated CFSSL with several new features that help make it a viable certificate authority tool. These include PKCS#11 support, which makes it possible for CFSSL to use a Hardware Security Module (HSM) to store private keys and OCSP support, which lets CFSSL answer questions about the revocation status of a certificate.

CAs are supposed to only give certificates to sites that own the domain(s) listed in the certificate. Domain validation is usually done in one of three ways:

• Putting a challenge in the DNS zone

• Putting a challenge into a meta-tag of an HTML page hosted on the domain

• Sending an email challenge to the domain registrant from the WhoIs DB

Since CloudFlare is both a content delivery network and a DNS provider, both DNS and HTML validation can be done by CloudFlare on behalf of the site. If your site is on CloudFlare and orange-clouded, we will give you a certificate for your site.

The CloudFlare Origin CA is currently not trusted by browsers, so these certificates should not be used on sites that are not behind CloudFlare. To issue certificates that are trusted by browsers, we would have to convince a publicly trusted certificate authority to cross-sign our CA certificate. This is not necessary in this case since it is CloudFlare that determines which certificates we trusted and the Origin CA is on our list.

The certificate signing request (CSR) is the standard mechanism for obtaining a certificate from a certificate authority. It contains a public key, some metadata such as which domain it is for and is digitally signed by a private key. It lets CloudFlare know that you own the private key.

CFSSL is not only a tool that can be used for running a CA, but it can be used to create CSRs too. Following these instructions will get you a private key and a CSR to submit to a certificate authority.

1) Install Go:

https://golang.org/doc/install

2) Install CFSSL

$ go get github.com/cloudflare/cfssl/cmd/...

3) Create a CSR template

Use the following template for csr.json and replace “mysite.com” with your site’s domain name and names with your company's information.

csr.json:

{
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "hosts": [
    “mysite.com"
  ],
 "CN": "mysite.com",
  "names": [
    {
      "C": "US",
      "L": "San Francisco",
      "ST": "California",
      "O": "My Company, Inc.",
      "OU": "My Company’s IT Department"
    }
  ]
}

4) Create the certificate

$ cfssl genkey csr.json | cfssljson -bare site

This creates two files:

• site.csr: your CSR

• site-key.pem: your private key

If CFSSL is not working for you, here are some more resources for creating CSRs:

• Comodo

• GlobalSign

• Digicert

In the future we plan on releasing tools to make certificate generation even easier and more automatic.

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.

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 web site, there is no guarantee that they will connect to the same physical machine that they connected to previously. Without session sharing, the success rate of session ID resumption could be as low as 1/n (when there are n hosts). That means the more hosts we have, the less likely a session can be resumed. This goes directly against our goal of scaling SSL performance!

CloudFlare’s solution to this problem is to share the sessions within the PoP, making the successful resumption rate approach 100%.

We employ a memcached cluster to cache all the recent negotiated sessions from all the hosts within the same PoP. To enhance the secrecy and security of session keys, all cached sessions are encrypted. When a new session with a session ID is negotiated, a host will encrypt the new session and insert it to memcached, indexed by the session ID. When a host needs to look up a session for session resumption, it will query memcached using the session ID as the key and decrypt the cached session to resume it. All those operations happen as non-blocking asynchronous calls thanks to the power of OpenResty, and many handy OpenResty modules such as the fully asynchronous memcached client. We also needed tweaks in OpenSSL to support asynchronous session caching.

I’d like to send a few shout-outs to my amazing colleagues Piotr Sikora and Yichun Zhang for making this project possible.

Using OpenSSL’s s_client utility, we can quickly test how a session ID is speeds up the TLS connection from the client side. We test the TLS performance of www.cloudflare.com from our office. And the result is shown below:

The overall cost of a session resumption is less than 50% of a full TLS handshake, mainly because session resumption only costs one round-trip while a full TLS handshake requires two. Moreover, a session resumption does not require any large finite field arithmetic (new sessions do), so the CPU cost for the client is almost negligible compared to that in a full TLS handshake. For mobile users, the performance improvement by session resumption means a much more reactive and battery-life-friendly surfing experience.

Session resumption with session IDs has a major limitation: servers are responsible for remembering negotiated TLS sessions for a given period of time. It poses scalability issues for servers with a large load of concurrent connections per second and for servers that want to cache sessions for a long time. Session ticket resumption is designed to address this issue.

The idea is simple: outsource session storage to clients. A session ticket is a blob of a session key and associated information encrypted by a key which is only known by the server. The ticket is sent by the server at the end of the TLS handshake. Clients supporting session tickets will cache the ticket along with the current session key information. Later the client includes the session ticket in the handshake message to indicate it wishes to resume the earlier session The server on the other end will be able to decrypt this ticket, recover the session key and resume the session.

Now consider every host in the same PoP uses the same encryption key, the good news is that every host now is able to decrypt this session ticket and resume the session for the client. The not-so-good news is that this key becomes critical single point of failure for TLS security: if an adversary gets hold of it, the session key information is exposed for every session ticket! Even after the lifetime of a session ticket, such a loss would invalidate supposed “perfect forward secrecy” (as evangelized here on our blog). Therefore, it is important to:

“generate session ticket keys randomly, distribute them to the servers without ever touching persistent storage and rotate them frequently.”(Adam Langley)

To meet all these security goals, we first start an in-memory key generator daemon that generates a fresh, timestamped key every hour. Keys are encrypted so that only our nginx servers can decrypt them. Then with CloudFlare’s existing secure data propagation infrastructure, ticket keys replicate from one primary instance to all of our PoPs around the world. Each host periodically queries the local copy of the database through a memcached interface for fresh encryption keys for the current hour. To summarize, the key generation daemon generates keys randomly and rotates them hourly, and keys are distributed to all hosts across the globe securely without being written to disk.

There are some technical details still worth mentioning. First, we need to tackle distributed clock synchronization. For example, there might be one host thinks it is UTC 12:01pm while other hosts still think it UTC 11:59am, the faster-clock host might start encrypting session tickets with the key of 12:00pm while other hosts could not decrypt those tickets because they don’t know the new key yet. Or the fast-clock host might find the key is not yet available due to propagation delay. Instead of dedicating efforts for synchronization, we solve the problem by breaking the synchronization requirement. The key daemon generates keys one hour ahead and each host would opportunistically save the key for the next hour (if there is any) as a decryption-only key. Now even with one or more faster-clock hosts, session resumption by ticket still works without interruption because they can still decrypt session tickets encrypted by any other.

Also we set the session ticket lifetime hint to be 18 hours, the same value for SSL session timeout. Each server also keeps ticket keys for the past 18 hours for ticket decryption.

To summarize, we support TLS session resumption globally using both sessions IDs and session tickets. For any web site on CloudFlare’s network, HTTPS performance has been made faster for every user and every device.

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.

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 the origin is secure as well. Beyond just encrypting the connection to the origin, we will also roll out a way to cryptographically ensure that the connection to the origin is, in fact, coming from CloudFlare's network.

In the last six months, research into cipher suites has continued at a torrid pace. The good news is that new ciphers that perform particularly well on mobile devices have started to become standardized. The bad news is that some of the older ciphers that were previously standard appear more and more likely to be comprisable. This week we'll, therefore, be adding support for a fast, new cipher while deprecating support for a cipher that we no longer have faith in.

We have a number of other surprises in store to help build a better, safer Internet. Stay tuned, we're confident SSL Week will help ensure SSL is anything but weak.

DNS is one of the pillars of authority on the Internet. DNS is used to translate domain names (like www.cloudflare.com) to numeric Internet addresses (like 198.41.214.163)—it’s often referred to as the “phone book of the Internet”.

DNSSEC is a set of security extensions to DNS that provides the means for authenticating DNS records. CloudFlare is planning to introduce DNSSEC in the next six months, and has brought Olafur Gudmundsson, one of the inventors of DNSSEC, on board to help lead the project.

CC BY 2.0 by Eric Fischer

The Domain Name System (DNS) is one of the oldest and most fundamental components of the modern Internet. As the mechanism that maps domain names to Internet Protocol (IP) addresses, it provides a human-readable layer to navigate the millions of machines and devices on the Internet. In the early 1980s, when DNS was designed, there was no consideration for strong security mechanisms in the protocol. Computers at that time were underpowered compared with today’s machines, public key cryptography was a relatively new concept and highly regulated, and the network was much smaller, with fewer participants who were relatively well known and trusted. As the network grew and evolved, DNS remained unchanged as an insecure and unauthenticated protocol.

In 1993, the IETF started a public discussion around how DNS could be made more trustworthy. Eventually, a set of extensions to DNS, called Domain Name System Security Extensions (DNSSEC), were settled on, and formally published in 2005. These extensions replaced earlier proposals as a definitive way forward for securing DNS. Though it’s been almost a decade since this publication, DNSSEC is still far from mainstream adoption.

There are several catalysts pushing DNSSEC adoption, one of which is Dan Kaminsky’s cache poisoning attack from 2008. This attack highlighted the significant trust issues in traditional DNS, and how DNSSEC is well positioned to solve them. However, even after a significant amount of work, adoption is lagging — there are several factors holding DNSSEC adoption back. Among them are network operators that prefer stability to complexity (for good reason). Another difficulty with DNSSEC adoption is that there is no universal consensus around whether DNSSEC is the right tool to secure the DNS.

In this post, we will explore the inherent insecurity of DNS and how DNSSEC can be used to improve trust in this fundamental part of the Internet.

The concept of DNS is simple: it’s a global database of information about domain names. It’s the Internet’s phone book.

If a client wants to connect to an address such as ‘www.example.com’ and needs to know which IP address corresponds to this address, they can ask DNS. Typically, all DNS messages are sent over UDP.

There are several types of Resource Records (RR) that DNS can answer questions about. One of the most important RRs is called an “A record”, which stores the IPv4 address associated with the domain. To find out the value of any record for a given domain, you can ask a DNS resolver. For example, it you wanted the IP address for www.example.com, the question you could ask is:

“What is the A record for the domain www.example.com?”

The raw DNS request is a UDP packet as shown in Listing 1. This request contains an ID (0x27e1), some flags to indicate that it is a request, and the question itself.

The response for our raw DNS request is shown in Listing 2. This response comes with the matching ID (0x27e1), a copy of the original request echoed back, some flags (1/0/0), and an answer to the question: 93.184.216.119. It also contains a validity period, called time to live (TTL), to indicate how long the record is valid.

Raw DNS request:

0x0000: 5ad4 0100 0001 0000 0000 0000 0765 7861 ‘............exa
0x0010: 6d70 6c65 0363 6f6d 0000 0100 01        mple.com.....

Wireshark’s interpretation:

Raw DNS Response:

0x0000: 51d4 8180 0001 0001 0000 0000 0765 7861 ‘............exa
0x0010: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
0x0020: 0100 0100 0031 f500 045d b8d8 77 .....1...]..w

Wireshark’s interpretation:

DNS is a distributed key/value database. The values returned can in theory be anything but in practice need to fit into well known types, such as addresses, mail exchanges, sever lists, free format text records etc. The keys consist of a name, type, and class. The name space is hierarchical (see below) and DNS information is “published” by Authoritative Servers. DNS Resolvers will locate the information requested by asking the appropriate authoritative servers by following the naming hierarchy from one Authoritative DNS server to the next one. The ISP typically provides a Recursive Resolver that will perform resolution on behalf of customers. You can also use a public resolver like the ones provided by Google (8.8.8.8, 8.8.4.4) or OpenDNS (208.67.222.222, 208.67.220.220).

Web-enabled applications like browsers use something called a Stub Resolver to interact with the DNS. Once the application or browser has obtained the IP address of the website, they can access it using the HTTP or HTTPS protocols.

The hierarchy of DNS namespace is well defined: DNS names consist of labels that are separated by dots. Thus “www.example.com.” consists of 4 labels “www” (leaf) “example” (domain) “com” (TLD) and “.” i.e. the root. Resolvers search by starting at the longest match of the labels, i.e., if it only knows about the root then, it starts the search there. If they know about .com they start there.

There are thirteen rootservers maintained by 12 different organizations. The root zone is maintained by IANA, which is a part of ICANN, and is published by Verisign which operates two of the root servers. The contents of the root zone is a list of the authoritative servers for each TLD, but not much else. Thus, if a root DNS server receives a query for “www.example.com” it will answer with what is called a referral to “.com” resolvers. The answer from the root server contains a set of records called NS (Name Server). These records list the nameservers which should have more information about the requested zone, i.e., the “.com” servers.

Each one of the TLDs authoritative nameservers knows about the authoritative nameservers for the domains under them (example.com, cloudflare.com, google.com, etc.). Following this downward, you will eventually get to the server that can answer queries about records for the name you are looking for.

DNS is the largest distributed delegated database in the world. Delegated means that each name can have a different authority that can maintain the information, and any changes are reflected in the DNS. For this reason, it’s important that resolvers don’t keep what they learn forever. Similarly, it’s important that busy resolvers can reuse the information they have fetched. This reuse of information is accomplished by placing a TTL on every DNS record which tells resolvers how long they can reuse the records to answer questions. When a resolver returns a cached value, it adjusts the TTL downward reflecting how long the data has resided in its cache.

In March of 2014, the government of Turkey decided to block Twitter inside the country. They did so at the DNS level by instructing Turkish ISP’s to return specified records for twitter.com and send them to a Turkish government web site. People quickly realized what was happening, and, by using foreign recursive resolvers, they could bypass the restrictions and get continue to get Twitter’s true address. This inspired citizens to spray paint Google’s public DNS server address on buildings and public spaces.

This incident in Turkey illustrates the first major security problem with DNS: there is no authentication. Any party with a privileged network position (e.g. they control a router that sits between two sides of a connection) is able to modify DNS records to point to wherever they choose. This is the so-called “on-path attacker attack”, and DNS is vulnerable.

In 2008, Dan Kaminsky revealed an attack on the DNS system which can trick a DNS recursive resolvers into storing incorrect DNS records. Once the nameserver has stored the incorrect response, it will happily return it to everyone who asks until the cache entry expires (usually dictated by the TTL). This is so-called “DNS poisoning” attack could allow arbitrary attacker to trick DNS, and redirect web browsers (and other applications) to incorrect servers allowing them to hijack traffic.

DNS poisoning attacks are simple to describe, but difficult to pull off. Take the sequence of events:

• Client queries recursive resolver

• Recursive resolver queries authoritative server

• Authoritative server replies to recursive resolver

• Recursive resolver replies with an answer to the client

Kaminsky’s attack relies on the fact that UDP is a stateless protocol and that source IP addresses are blindly trusted. Each of the requests and responses described here is a single UDP request containing to and from IP addresses. Any host can in theory forge the source address on UDP message making look like it came from the expected source. Any attacker sitting on a network that does not filter outbound packets can construct a UDP message that says it’s from the authoritative server and send to the recursive resolver.

Of the requests above, message number 3 is a good target to attack. This is because the recursive resolver will accept the first answer to its question that matches its query. So, if you can answer it faster than the authoritative server, the recursive resolver will accept your answer as the truth. This is the core of the attack:

• Pick a domain whose DNS entries you want to hijack.

• Send a request to the recursive resolver for the record you want to poison.

• Send many fake UDP responses pretending to be the authoritative server with the answer of your choosing (i.e. point the A record to an IP you control).

If one of your malicious—acceptable—responses arrives ahead of the real response, the recursive resolver will believe your record and cache it for as long as the TTL is set. Then any other clients asking for the poisoned record will be directed to your malicious servers.

There are some complications that make this harder than it sounds in practice. For example, you have to guess:

• The request ID—a 16-bit number

• The authoritative server address that the query was sent to

• The recursive resolver address used to send the query

• The UDP port used to send the query to the authoritative server

When Kaminsky’s attack was originally proposed, many of these values were easily guessable or discoverable, thus making DNS poisoning a real threat. Since then, request ID, port randomization, and source address rotation have made this specific attack more difficult to pull off—but not impossible. DNS cache poisoning is a real issue, and has been reported in the wild as recently as September 2014.

The fundamental issue that allows this kind of attack to happen is that there is no way for the resolver to validate that the records are what they are supposed to be. Note: if the attacker is in position to see the query traffic from the recursive resolver, it has all the information it needs to forge answers (see http://www.wired.com/2014/03/quantum/).

The security extensions to DNS add protection for DNS records, and allow the resolvers and applications to authenticate the data received. These powerful additions will mean that all answers from DNS can be trusted. Earlier we described how DNS resolution starts at the root nameserver, and works down (e.g. for “www.example.com” it starts at the root server, then “com”, then “example.com”). This is the same way that trust is conferred via DNSSEC. The DNS root is the definitive root of trust, and a chain of trust is built to the root from any DNS entry. This is a lot like the chain of trust used to validate TLS/SSL certificates, except that, rather than many trusted root certificates, there is one trusted root key managed by the DNS root maintainer IANA.

The point of DNSSEC is to provide a way for DNS records to be trusted by whoever receives them. The key innovation of DNSSEC is the use of public key cryptography to ensure that DNS records are authentic. DNSSEC not only allows a DNS server to prove the authenticity of the records it returns. It also allows the assertion of “non-existence of records”.

The DNSSEC trust chain is a sequence of records that identify either a public key or a signature of a set of resource records. The root of this chain of trust is the root key which is maintained and managed by the operators of the DNS root. DNSSEC is defined by the IETF in RFCs 4033, 4034, and 4035.

There are several important new record types:

• DNSKEY: a public key, used to sign a set of resource records (RRset).

• DS: delegation signer, a hash of a key.

• RRSIG: a signature of a RRset that share name/type/class.

A DNSKEY record is a cryptographic public key, DNSKEYs can be classified into two roles, which can be handled by separate keys or a single key

• KSK (key signing key): used to sign DNSKEY records.

• ZSK (zone signing key): used to sign all other records in the domain is authoritative for.

For a given domain name and question, there are a set of answers. For example, if you ask for the A record for cloudflare.com, you get a set of A records as the answer:

cloudflare.com.            285    IN    A    198.41.212.157
cloudflare.com.            285    IN    A    198.41.213.157

The set of all records of a given type for a domain is called an RRset. An RRSIG (Resource Record SIGnature) is essentially a digital signature for an RRset. Each RRSIG is associated with a DNSKEY. The RRset of DNSKEYs are signed with the key signing key (KSK). All others are signed with the zone signing key (ZSK). Trust is conferred from the DNSKEY to the record though the RRSIG: if you trust a DNSKEY, then you can trust the records that are correctly signed by that key.

However, the domain’s KSK is signed by itself, making it difficult to trust. The way around this is to walk the domain up to the next/parent zone. To verify that the DNSKEY for example.com is valid, you have to ask the .com authoritative server. This is where the DS record comes into play: it acts as a bridge of trust to the parent level of the DNS.

The DS record is a hash of a DNSKEY. The .com zone stores this record for each zone that has supplied DNSSEC keying information. The DS record is part of an RRset in the zone for .com and therefore has an associated RRSIG. This time, the RRset is signed by the .com ZSK. The .com DNSKEY RRset is signed by the .com KSK.

The ultimate root of trust is the KSK DNSKEY for the DNS root. This key is universally known and published.

Here is the DNSKEY root KSK that was published in August 2010 and will be used until sometime in 2015 or 2016 (encoded in base64):

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcC jFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJR kxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efu cp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA 6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQd XfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhY B4N7knNnulqQxA+Uk1ihz0=

By following the chain of DNSKEY, DS and RRSIG records to the root, any record can be trusted.

These records are enough to prove the integrity of a resource record, but something more is needed in order to prove that a record does not exist. This is where two additional record types, NSEC and NSEC3, come into play.

If a DNS authoritative server knows there is no record for a specific request, it has a way to respond to such requests. When the name asked for does not exist, it returns a message that has return code (RCODE) NXDOMAIN. When the name exists, but the requested type does not, it returns a NODATA response, i.e., empty answer.

These non-existence answers are unauthenticated and could be forged by a third party just like any other DNS response. However, DNSSEC solves this problem by creating a record type that expresses what names exist, and what types reside at each name. This record is called NSEC. An NSEC can be signed by DNSSEC, and validated up to the root. Typically, NSEC is used to cover gaps between all the domains with records in the zone. In most cases, this effectively doubles the number of records in the zone, but allows an authoritative nameserver to reply with a signed response for any question.

The zone ietf.org. uses NSEC records. Asking for ‘trustee.ietf.org’ would give you a positive answer with an IP address and an RRSIG record. Asking for ‘tustee.ietf.org’ would give you a negative answer ‘there are no name between trustee.ietf.org and www.ietf.org’, with a corresponding RRSIG.For example:

Question:

tustee.ietf.org/A

Answer:

trustee.ietf.org.        1683        IN        NSEC        www.ietf.org. A MX AAAA RRSIG NSEC

This means that there are no names the zone in between trustee.ietf.org and www.ietf.org, when sorted alphabetically, effectively proving that tustee.ietf.org does not exist.

RFC5155 defines a obufscated way to deny existence via the NSEC3 record. NSEC3 uses similar logic, but for the names are hashed. Asking for examplf.com (e comes before f) would give you ‘there are no records with hashes between A and B’, where A is the next closest hash lexicographically before the hash of examplf.com, and B is the next closest after.

This post is the first in a series of posts about how Cloudflare does DNS, and our DNS plans. In future posts, we will go into detail about some of advantages and disadvantages of DNSSEC. We will also discuss useful extensions to DNSSEC, like DANE, and how these can be used to secure websites and provide a much stronger form of trust than the certificate authority system. We will also examine how far the effort has come in the decade since the technology was standardized using adoption statistics and trends.

DNSSEC is a valuable tool for improving the trust and integrity of DNS, the backbone of the modern Internet. DNSSEC deployment is still in its infancy, less than five per cent of all zones had been signed as of mid-2014. Though it has its detractors, adoption is increasing and DNSSEC is becoming a core tool in the development of a safer and more trustworthy Internet and CloudFlare is committed to supporting it.

CC BY 2.0 by JD Hancock

Last Monday we announced our SSL for Free plan users called Universal SSL. Universal SSL means that any site running on CloudFlare gets a free SSL certificate, and is automatically secured over HTTPS.

Using SSL for a web site helps make the site more secure, but there's another benefit: it can also make the site faster. That's because the SPDY protocol, created by Google to speed up the web, actually requires SSL and only web sites that support HTTPS can use SPDY.

CloudFlare has long supported SPDY, and kept up to date with improvements in the protocol. We currently support the most recent version of SPDY: 3.1.

CloudFlare's mission to bring the tools of the Internet giants to everyone is two fold: security and performance. As part of the Universal SSL launch, we also rolled out SPDY for everyone. Many of the web's largest sites use SPDY; now all sites that use CloudFlare are in the same league.

If your site is on CloudFlare, and you use a modern browser that supports SPDY, you'll find that the HTTPS version of your site is now served over SPDY. SPDY allows the browser to query for multiple objects in one request, and for the objects to be sent down the wire as they are ready to prevent hold-ups—that can be a big performance win.

Our goal is a faster, safer, more secure Internet. Universal SSL and SPDY for everyone are two big steps in that direction.

CloudFlare’s entire infrastructure is built on modern commodity hardware. Specifically, our web servers are running on CPUs manufactured by Intel that were designed with cryptography in mind.

All Intel CPUs based on the Westmere CPU microarchitecture (introduced in 2010) and later have specialized cryptographic instructions. Important for CloudFlare’s Universal SSL rollout are the AES-NI instructions which speed up the Advanced Encryption Standard (AES) algorithm. There’s also a set of instructions called Carry-less Multiplication (CLMUL) that computes mathematical operations on binary finite fields. CLMUL can be used to speed up AES in Galois Counter-mode (GCM): our preferred mode of encryption due to its resistance against recent attacks like BEAST.

As we described in our primer on TLS, the server picks which algorithm is used in a connection based on the cipher suites supported by the client. In our configuration (available on GitHub), we prioritize AES-based ciphers, and prefer AES-GCM to AES-CBC.

The vast majority of the HTTPS data served by CloudFlare’s servers is encrypted with AES. Here’s the breakdown of ciphers we use on an average day:

AES-CBC: 	62.8013%
AES-GCM: 	36.2813%
3DES: 		0.9170%
RC4: 		0.0003%

AES is practically free of performance cost on our modern processors, and 99% of data enciphered by CloudFlare’s servers uses AES so the cost is trivially small. Note that out of these ciphers, RC4 is the second fastest; however, we de-prioritized it for security reasons, though we couldn’t remove it completely due to some odd client configurations.

Image © Trevor Perrin 2014

There are two potentially costly portions of a TLS connection: the data encipherment and the handshake. With AES-NI and CLMUL data encipherment is essentially free; however, there are two expensive steps in the handshake. One is the the private key operation, and the other is the key establishment (this is described in our Keyless SSL post).

With Universal SSL, both the private key operation and the key establishment use elliptic curve cryptography. The private key operation uses the Elliptic Curve Digital Signature Algorithm (ECDSA), and the key establishment uses Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).

Elliptic curve cryptography allows you to use smaller keys than traditional RSA. For example, a 256-bit elliptic curve key is equivalent in strength to a 3072-bit RSA key. Smaller keys allow elliptic curve cryptography to be around 5-10x faster than RSA in general cases. For Universal SSL, we chose the elliptic curve P-256 with an optimized assembly code implementation by Shay Gueron and Vlad Krasnov (currently at Intel). This implementation was merged into OpenSSL this week, and provides additional speedup of 2-3x for both ECDHE and ECDSA. Choosing this elliptic curve reduced the computational burden of the TLS handshake on our servers by an order of magnitude.

Up until the launch of Universal SSL this week, all but a hundred sites on the Internet used RSA-based certificates. Universal SSL is the first large-scale deployment of ECDSA keys for TLS. This is the first major step towards bringing the advantages of elliptic curves onto the web.

Even with fast elliptic curve cryptography, the asymmetric steps (key establishment and digital signature) are still the most expensive part of a TLS handshake. For returning visitors of a site we have a shortcut that eliminates the need for our servers to perform these expensive operations. The shortcut is called session resumption and it's built into the TLS specification.

In our post about Keyless SSL, we mentioned new work we did to improve session resumption. Resuming a TLS connection is not only faster in terms of latency—there is one less round-trip to the server—but it’s also more lightweight because the server can skip the expensive asymmetric cryptographic operations.

The TLS protocol has two ways to resume a session: session tickets and session IDs. In session ID resumption, the server stores the session information for reuse later. For session tickets, the session information is encrypted by a key known only by the server and sent to the client in the handshake in a “session ticket”. When the client wants to resume a session, it can send the session ticket to the server which can decrypt it and resume the session. By storing the connection information in a way that it can be reused later, the expensive parts of the handshake are not necessary.

The work done by Zi Lin and Kyle Isom for Keyless SSL to share sessions and session tickets across machines allows us to resume connections even if they were made to a different CloudFlare server. For SSL session ticket based resumption (used in Chrome and Firefox), sessions can be resumed worldwide; for session ID based resumption (all other browsers), sessions can be resumed from any machine in the same data center.

CloudFlare can serve any customer’s site, from any CloudFlare server, anywhere in the world—including sites over TLS. This flexibility allows us to efficiently handle attacks, and evenly share the load across our data centers.

Web servers like nginx are designed to use static configurations. If something about a site changes (like the certificate), the server configuration needs to be reloaded. Reloading can cause the server to read data from disk and re-initialize internal state, causing a strain on server resources. Reloading often is necessary when you have millions of customers who are able to change their certificates at any time. At CloudFlare’s scale, this can result in a performance bottleneck.

Lazy loading of certificates helps relieve that bottleneck. Using custom modifications to nginx by CloudFlare engineer Piotr Sikora, we are able to dynamically load certificates into memory only when they’re needed. Now, if one site changes their certificate, the server does not have to reload every certificate. This change allows our servers to scale up to handle millions of HTTPS sites.

Through a combination of modern hardware, modern algorithms, lazy loading, and session resumption techniques, we were able to reduce the CPU usage of Universal SSL to almost nothing.

Hopefully, our experience helps debunk one of the myths about SSL by showing that it can be done on a massive scale with minimal extra burden on web servers.

It turns out it takes a while to deploy SSL certificates for 2 million websites. :-) Even longer when you get a flood of new sign ups. While we'd hoped to have the deployment complete within 24 hours of the announcement, it now looks like it's going to take a bit longer. We now expect that the full deployment will be complete about 48 hours from now (0700 UTC). Beyond that, nothing about the plan for Universal SSL has changed and hundreds of thousands of sites are already active.

In order to get through the highest priority sites first, we've prioritized provisioning the sites with the most traffic.

While you wait for your site to get provisioned, you may see a certificate mismatch error if you try and visit it over HTTPS. (Rest assured, there are no errors if you visit over HTTP.) The errors over HTTPS are expected and normal during the provisioning process. Examples of what these error looks like in various browsers (Chrome, Safari, Firefox, and Internet Explorer) are below:

To give you a sense of our progress provisioning Universal SSL for your sites, we've updated the alert that you see when you login to CloudFlare to show what sites have been enabled and what sites are still pending. It now looks like this:

When the Universal SSL provisioning process is complete, we will also email all our customers. Again, at the current rate, we expect to be finished by Thursday, October 2 at 0700 UTC.

We apologize for the delay. We're getting new sites provisioned as quickly as we can. If you want to see what it looks like when it's working correctly, check out one of the following:

• https://ciaranmcnulty.com/

• https://samsclass.info/

Note that on the latter of these examples you may see a mixed content warning. We expect site owners will clean these issues up by using protocol-relative URLs now that they have HTTPs support. Going forward, we also have some ideas about how we can help automatically resolve mixed content issues.

Thank you for your patience.

CloudFlare’s Flexible SSL mode is the default for CloudFlare sites on the Free plan. Flexible SSL mode means that traffic from browsers to CloudFlare will be encrypted, but traffic from CloudFlare to a site's origin server will not be. To take advantage of our Full and Strict SSL mode—which encrypts the connection between CloudFlare and the origin server—it’s necessary to install a certificate on the origin server.

We made Universal SSL free so that everyone can use modern, strong encryption tools to protect their web traffic. More encrypted traffic helps build a safer, better Internet. In keeping with CloudFlare’s goal to help build a better Internet, we have some tips on how to upgrade your site from Flexible SSL to Full or Strict SSL.

Dealing with Certificate Authorities (CAs) can be frustrating, and the process of obtaining a certificate can be time consuming. In the meantime, you can get started by installing a self-signed certificate on your origin server. This allows CloudFlare to encrypt the communication with the origin, protecting the communication against passive surveillance, but not against active attackers.

Our handy CSR guide for CFSSL describes how to generate a self-signed certificate. Using OpenSSL to create it is another option.

Once you have created a self-signed certificate and private key, you can install them on your origin server. Digicert has a guide for installing a certificate that covers the most popular server software.

Keep in mind that a self-signed certificate is not signed by a trusted CA. This means that you can change your SSL setting from Flexible SSL to Full, but not Full (strict). Full SSL won’t be able to provide authentication, but it will make sure the connection to the origin is encrypted and protected from passive snoopers.

Most CAs offer low-cost or even free certificates. A popular CA that offers free SSL certificates is StartSSL. Buying and installing a trusted certificate on your origin server is currently the simplest way to enable Strict SSL on your site.

To enable TLS on your server, you need both a certificate and a corresponding private key. The first step in obtaining a certificate from a CA is creating a Certificate Signing Request (CSR). A CSR contains your public key and a proof that you have the associated private key. The CA will verify it and give you back a certificate that you install on your web server. We put together a guide to creating a private key and CSR with CloudFlare’s CFSSL tool that you can use, or alternatively, there’s always OpenSSL.

Once you have a certificate installed on your origin server, you can change your SSL setting from Flexible to Full (strict) and have the added benefit of an authenticated and encrypted connection to your origin server.

Soon you will be able to send your CSR to CloudFlare to get a certificate instantaneously, speeding up the certificate acquisition process. This process will be like that of a regular CA, but much faster. These certificates aren't yet trusted by browsers, but will be trusted by CloudFlare, allowing the back end connection to be both encrypted and authenticated. This also protects your site if one of the publicly trusted certificate authorities is compromised by attackers and used to issue illegitimate certificates.

We’re also investigating the possibility of adding a feature called Certificate Pinning. Certificate Pinning would allow you to tell CloudFlare exactly which certificate to trust for your origin. This would allow customers to use hosting services that don’t allow custom certificates to have the benefit of a fully encrypted tunnel, or to simply use a self-signed certificate and get the benefit of both authentication and encryption.

The team at CloudFlare is excited to announce the release of Universal SSL™. Beginning today, we will support SSL connections to every CloudFlare customer, including the 2 million sites that have signed up for the free version of our service.

This morning we began rolling out the Universal SSL across all our current customers. We expect this process to be complete for all current customers before the end of the day. Yesterday, there were about 2 million sites active on the Internet that supported encrypted connections. By the end of the day today, we'll have doubled that.

For new customers who sign up for CloudFlare's free plan, after we get through provisioning existing customers, it will take up to 24 hours to activate Universal SSL. As always, SSL for paid plans will be provisioned instantly upon signup.

For all customers, we will now automatically provision a SSL certificate on CloudFlare's network that will accept HTTPS connections for a customer's domain and subdomains. Those certificates include an entry for the root domain (e.g., example.com) as well as a wildcard entry for all first-level subdomains (e.g., www.example.com, blog.example.com, etc.).

For a site that did not have SSL before, we will default to our Flexible SSL mode, which means traffic from browsers to CloudFlare will be encrypted, but traffic from CloudFlare to a site's origin server will not. We strongly recommend site owners install a certificate on their web servers so we can encrypt traffic to the origin. Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security.

CloudFlare operates at significant scale and we're growing very quickly. To make Universal SSL work at our scale we needed to ensure it wouldn't overwhelm our resources. We had two primary concerns:

1. CPU load

2. IPv4 exhaustion

Terminating HTTPS connections requires more CPU load than terminating HTTP. The additional load varies depending on the particular cipher suite used. For instance, the cutting-edge cipher suite ECDSA imposes significantly less load on our systems as compared with a more traditional cipher suite based on RSA. As it happens, ECDSA also provides a number of performance and security benefits over older cipher suites. We've written in the past about the benefits of ECDSA including the fact that it supports Perfect Forward Secrecy and faster SSL termination (and therefore faster page load times).

IPv4 termination is the other challenge of Universal SSL. The original implementation of SSL encrypted the host header. That meant you were limited to one certificate per IP address. Given that CloudFlare controls a finite number of IP addresses, it would be impossible for us to dedicate a unique IP for every one of our millions of customers.

These challenges required that, for free customers, we limit Universal SSL support to modern browsers. Modern browsers include support for ECDSA, where many legacy browsers do not. Modern browsers also support an extension to the SSL protocol called Server Name Indication (SNI). SNI sends the web site name (the equivalent of the host header) unencrypted, which allows us to return different certificates on an IP address depending on what customer's site is requested. This allows us to serve multiple customers' sites from the same IP.

Generally, if you're running a browser that is less than 6 years old, your browser is modern and Universal SSL on CloudFlare's free plans will work. The two biggest problem children legacy browsers are:

1. Internet Explorer on Windows XP (or older)

2. Android pre-Ice Cream Sandwich

We've been studying browser traffic for the last year in order to determine what percentage of requests come from browsers that qualify as modern. The answer varies widely depending on the region. Globally, more than 80% of requests come from modern browsers, and that percentage is growing quickly.

A recent test showed the percentage of requests in countries around the world that come from modern browsers. Iran is the worst region in the world with only 52.01% of requests coming from modern browsers. Antarctica is the best region in the world with 99.44% of requests coming from modern browsers. You can mouse over different regions to see the percentage of requests that come from modern browsers.

While Universal SSL on our free service requires a modern browser, CloudFlare's paid plans have always and will always support both modern and legacy browsers. In the coming months, because of the benefits of ECDSA certificates, we plan on offering paid users the option to return ECDSA certificates if we detect a modern browser, while reverting to RSA certificate if we detect a legacy browser.

If SSL is a must-have for you, we still recommend using a paid CloudFlare plan (which start as inexpensively as $20/month). If SSL is a nice-to-have, support on the free plan is likely sufficient to serve the vast majority visitors from most regions around the world. Note finally that Universal SSL does not disable your ability to accept unencrypted traffic. HTTP will continue to work as it always has before. You can, however, now use CloudFlare's Page Rules to force all traffic to HTTPS even if you're a free customer. (PS - Going forward, also we plan to support the ability to add HSTS headers.)

One additional benefit of Universal SSL is it allows us to broadly support of the SPDY protocol which requires an encrypted connection. SPDY improves web performance in a number of ways we've written about before. All CloudFlare customers will, by the end of the day today, also have SPDY enabled by default — massively increasing the size of the SPDY universe.

We also have plans to expand the universe of supported browsers slightly by taking advantage of connections that arrive over IPv6 for browsers that don't support SNI. About 16% of unique IP addresses that connect to CloudFlare do so via IPv6 (note: that calculation takes only the first 8 bytes as unique in any IPv6 address connecting to our network). Since IPv6 addresses are virtually infinite, we don't have the same limitations as we do with IPv4 and can therefore return a unique certificate for every IPv6 address.

Our bigger hope, however, is that Universal SSL will be yet another reason, along with Google and Firefox deprecating SHA-1-signed certs and Microsoft ceasing support for Windows XP, to encourage people to upgrade to a modern browser running on a modern OS. Sometimes progress requires sacrificing some backward compatibility. The good news here is that none of CloudFlare's current free customers supported any version of SSL previously, so the encrypted web tomorrow is only better and no worse.

To that end, CloudFlare customers can help encourage the remaining users of old browsers to upgrade using a CloudFlare App. The A Better Browser app can be installed with one click on any web site that uses CloudFlare. It automatically detects if the visitor is using an old browser and adds a banner at the top of the page suggesting that they upgrade.

Last Wednesday we had a CloudFlare Board meeting. We went over our plans for launching Universal SSL and how doing so may hurt our revenue given that SSL is one of the reasons people upgrade to a paid plan. But everyone on CloudFlare's Board was unanimous: even if it does hurt revenue in the short term, it's the right thing to do.

Brad Burnham, who is the partner at Union Square Ventures who led our last round of financing, reminded me during the meeting of the Joi Ito essay about how the Internet is a belief system. Inherent to Joi's point is that small groups of people, working together, can create great things. That, fundamentally, is the Internet.

The team behind Netscape first introduced SSL back in February 1995, originally intended to facilitate ecommerce online. As the Internet grew in importance, governments, ISPs, and hackers began to intercept, throttle, and censor traffic as it flowed across the network to serve their ends. In response, SSL's importance expanded beyond ecommerce to help ensure a free and open web. As Google and the IETF work on the next generation Internet protocols like SPDY and HTTP/2, it's no wonder encryption is at their heart. And so, in order for CloudFlare to fulfill its mission of helping build a better Internet, we knew one of the most important things we could do was enable Universal SSL for all our customers — even if they don't pay us.

Having cutting-edge encryption may not seem important to a small blog, but it is critical to advancing the encrypted-by-default future of the Internet. Every byte, however seemingly mundane, that flows encrypted across the Internet makes it more difficult for those who wish to intercept, throttle, or censor the web. In other words, ensuring your personal blog is available over HTTPS makes it more likely that a human rights organization or social media service or independent journalist will be accessible around the world. Together we can do great things.

The Internet is a belief system. At CloudFlare, we're proud today that we're playing a part in helping advance that belief system. And, having proven that Universal SSL is possible at our scale, we hope many other organizations will follow in turning SSL on for all their customers and at no additional cost.

If you are already a CloudFlare customer, we're rolling out Universal SSL throughout the day today. We expect it will be fully provisioned for most current customers within the next 24 hours. If you're a new customer, note that it will take up to 24 hours from when you sign up to provision SSL for our free service (and, again, if you're in a hurry, it's still instant for all paid plans).

One final note: if you signed up for CloudFlare through one of our hosting partners, it will be a bit longer before we can enable Universal SSL. This is due to a technical limitation on how we need to provision the Universal SSL certificates. We think we can solve the technical limitation and expect that we'll be able to support Universal SSL through partners before the end of the year. Until then, hang tight.

This is a day the CloudFlare team has been looking forward to for the last three years. It took a ton of work. We couldn't have done it without the help of a number of great people both on our own team and at other organizations that provided assistance. Special thanks to Globalsign, Comodo, Ryan Hurst, Christopher Soghoian (ACLU), Peter Eckersley (EFF), and Adam Langley (Google).

Over the next few days, we'll be posting a series of articles about the details behind how we made Universal SSL a reality. There were a number of hard technical, business, and legal challenges we had to overcome to make today possible. The people that worked on solving them are excited to share their stories. Stay tuned.

Update: It's taking us a bit longer to provision Universal SSL for all our customers than we'd originally anticipated. We're now expecting the provisioning process to be complete on Thursday, October 2 @ 0700 UTC. We've published a new blog post on how you can track our progress and what errors you may see if you try and visit your site over HTTPS before the provisioning process is complete.