Introducing SSL for SaaS

If you’re running a SaaS company, you know how important it is that your application is performant, highly available, and hardened against attack. Your customers—and your revenue stream—depend on it. Putting your app behind a solution such as Cloudflare is an obvious move for your own infrastructure, but how do you securely (and easily) extend these benefits to your customers?

If your customers interact with your app on your domain and don’t care about branding under their custom or “vanity” domain (or aren’t paying you for the ability to do so), the solution is straightforward: onboard your domain to Cloudflare and serve the app at either https://app.yourcompany.ltd or https://yourcustomer.yourcompany.ltd. But if your customers want to host your application, portal, content management solution, etc. on their own domain for improved SEO and discoverability, e.g., https://app.yourcustomer.site the solution is not so easy.

Easily extend the benefits of Cloudflare to your customers, one hostname at a time

Until today, your best bet was to ask them to CNAME over to your infrastructure, have them generate a private key and CSR, send the latter to a CA for signing, and then securely provide you with the Continue reading

Introducing Dedicated SSL Certificates

When we launched Universal SSL in September 2014 we eliminated the costly and confusing process of securing a website or application with SSL, and replaced it with one free step: sign up for Cloudflare.

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.

More control and personalization

But along the way we heard from customers who wanted more control over the certificates used for their domains. They want Continue reading

Introducing CloudFlare Origin CA

Free and performant encryption to the origin for CloudFlare customers

In the fall of 2014 CloudFlare launched Universal SSL and doubled the number of sites on the Internet accessible via HTTPS. In just a few days we issued certificates protecting millions of our customers’ domains and became the easiest way to secure your website with SSL/TLS.

At the time, we "strongly recommend[ed] that site owners install a certificate on their web servers so we can encrypt traffic to the origin." This recommendation was followed by a blog post describing two readily-available options for doing so—creating a self-signed certificate and purchasing a publicly trusted certificate—and a third, still-in-beta option: using our private CA. Even though out-of-pocket costs of acquiring public CA certificates have since fallen to $0 since that post, we have continued to receive requests from our customers for an even easier (and more performant) option.

Operating a public certificate authority is difficult because you don't directly control either endpoint of the HTTPS connection (browser or web server). As a result, public CAs are limited both in their ability to issue certificates optimized for inter-server communication, as well as in their ability to revoke certificates if they are compromised. Continue reading

TLS Certificate Optimization: The Technical Details behind “No Browser Left Behind”

Overview

Back in early December we announced our "no browser left behind" initiative to the world. Since then, we have served well over 500 billion SHA-1 certificates to visitors that otherwise would not have been able to communicate securely with our customers’ sites using HTTPS. All the while, we’ve continued to present newer SHA-2 certificates to modern browsers using the latest in elliptic curve cryptography, demonstrating that one does not have to sacrifice security to accommodate all the world’s Internet users. (If you weren’t able to acquire a SHA-1 certificate before CAs ceased issuing them on 2015/12/31, you can still sign up for a paid plan and we will immediately generate one to serve to your legacy visitors.)

Shortly after we announced these new benefits for our paid Universal SSL customers, we started hearing from other technology leaders who were implementing (or already had implemented) similar functionality. At first glance, the logic to identify incoming connections that only support SHA-1 seems straightforward, but as we spoke with our friends at Facebook, Twitter, and Mozilla, I realized that everyone was taking a slightly different approach. Complicating the matter even further was the fact that at CloudFlare we not only Continue reading

Change the (S)Channel! Deconstructing the Microsoft TLS Session Resumption bug

Initial Problem Report

Several months ago we started hearing occasional reports from .NET developers that they were having trouble maintaining HTTPS sessions with one of our customer’s websites. Establishing connections worked just fine but they would periodically get disconnected, resulting in an exception that crashed their application. Around the same time, we also started hearing reports that two other Microsoft products—Internet Explorer and its heir-apparent, Edge—were also having trouble with our edge.

Just a few weeks prior, we had updated our handling of TLS session tickets to be more performant and more secure. We suspected these improvements were the trigger and focused our investigation there. What we learned was that the problem ran much deeper than .NET or IE. It went all the way down to the SChannel security package, which provides TLS functionality for a vast array of Microsoft applications.

TLS Session Tickets

Before diving into the story further, however, it’s helpful to understand exactly what TLS session tickets are, how they’re beneficial to HTTPS, and what optimizations CloudFlare does to use them at scale. (If you’d like to skip over the primer and jump right to the punchline, go ahead and click here.)

Overview

First introduced in Continue reading

Introducing Partner Analytics

CloudFlare has over 5,000 partner hosting providers. Every day, thousands of our partners' customers take advantage of CloudFlare to help them be faster and more secure. The benefits to our partners aren't just happier customers, they also translate into real savings. In the last month, for instance, we saved our partners more than 25 Petabytes in aggregate bandwidth. In addition to bandwidth savings, in that same period, we stopped more than 65 billion malicious requests that would have otherwise impacted our partners' infrastructure. Now we've broken out the bandwidth and performance data by partners so they can see the savings and protection we're delivering.

Back when we launched the CloudFlare Partner Program four years ago, we periodically distributed these figures as high level summaries of bandwidth saved, threats blocked, and number of domains protected and accelerated via each partnership. Our partners knew anecdotally from their own logs and operating expenditures that CloudFlare was reducing their costs and greatly improving their customers’ experiences, but we did not yet have the tools to help demonstrate these benefits on a repeatable and granular basis.

It wasn’t that we didn’t want to provide this data, it was that our tremendous growth rate had stretched Continue reading