AWS and Google are notably absent from the group, though Microsoft and IBM are on board.
“I love my domain registrar.” Has anyone ever said this? From before Cloudflare even launched in September 2010, our early beta customers were literally begging us: "Will you please launch a registrar too?!" Today we're doing just that, launching the first registrar we hope you’ll be able to say you love. It's built around three principles: trust, security, and always-fair pricing. And it’s available to all Cloudflare customers.
Cloudflare has actually run a registrar for some time. Like many of our best products, it started by solving an internal issue we had. Cloudflare has several mission-critical domains. If the registration of these domains were ever compromised, it would be, in a word, bad.
For years, we worked with our original domain registrar to ensure these domains were as locked down as possible. Unfortunately, in 2013, a hacker was able to compromise several of the systems of the registrar we used and come perilously close to taking over some of our domains.
That began a process of us looking for a better registrar. Unfortunately, even the registrars that charge hefty premiums and promise to be very secure turn out to have pretty lousy security. Continue reading
Every website, large or small, started with an idea, rapidly followed by registering a domain. Most registrars offer promotions for your initial domain registration and then quietly hike the price with each renewal. What they don’t tell customers is that the price they pay to a registry, for your registration, is set by the registry. In some cases, we’ve found registrars charging eight times the wholesale price for a domain renewal.
Today, we’re launching Cloudflare Registrar, the first domain registrar you can love. Cloudflare Registrar will never charge you more than what we pay to the registry for your domain. No markup and no surprise fees. For eight years Cloudflare has built products that make the internet faster and safer. It's time for us to start where your internet journey starts, your domain.
When you register a domain, you become the owner, or registrant, for that domain for a set period of time. Now that you are the registrant, you can create an authoritative record that tells the world the nameservers for your domain. The domain name system, or DNS, uses those nameservers to direct traffic to the IP address of your server.
Today, we’re excited to announce the launch of the Bandwidth Alliance, a group of cloud providers that have agreed to reduce data transfer fees for mutual customers.
Three things were required to make the Bandwidth Alliance a reality:
Typically, as traffic moves across the Internet, packets are exchanged between multiple networks as they Continue reading
At Cloudflare, our mission is to help build a better Internet. That means making the Internet faster, safer and smarter, but also more efficient alongside our cloud partners. As such, wherever we can, we're on the lookout for ways to help save our common customers money. That got us looking into why and how much cloud customers pay for bandwidth.
If you're hosting on most cloud providers, data transfer charges, sometimes known as "bandwidth” or “egress” charges, can be an integral part of your bill. These fees cover the cost of delivering traffic from the cloud all the way to the consumer. However, if you’re using a CDN such as Cloudflare, the cost of data transfer comes in addition to the cost of content delivery.
In some cases, charging makes sense. If you're hosted in a facility in Ashburn, Virginia and someone visits your service from Sydney, Australia there are real costs to moving traffic between the two places. The cloud provider likely hands off traffic to a transit provider or uses its own global backbone to carry the traffic across the United States and then across the Pacific, potentially handing off to other transit providers along the way, until Continue reading
Today Cloudflare opened the door on our beta deployment of QUIC with the announcement of our test site: cloudflare-quic.com. It supports the latest draft of the IETF Working Group’s draft standard for QUIC, which at this time is at: draft 14.
The Cloudflare Systems Engineering Team has a long history of investing time and effort to trial new technologies, often before these technologies are standardised or adopted elsewhere. We deployed early experiments in standards such as: HTTP/2,
TLS1.3, DNSSEC, DNS over HTTP, Encrypted SNI, when they were still in incubation. We committed to these technologies in their very early stages because we believed that they made for a safer, faster, better internet. And now we’re excited to do the same with QUIC.
In this blog post, we will show you how you can unlock the cloudflare-quic.com achievement and be some of the first people in the world to perform a HTTP transaction over the global internet using QUIC. This will be a moment that you can tell your grandkids about - if they can stop laughing at your stories of cars with wheels and use of antiquated words like: “meme” and Continue reading
Six o’clock already, I was just in the middle of a dream, now I’m up, awake, looking at my Twitter stream. As I do that the Twitter app is making multiple API calls over HTTPS to Twitter’s servers somewhere on the Internet.
Those HTTPS connections are running over TCP via my home WiFi and broadband connection. All’s well inside the house, the WiFi connection is interference free thanks to my eero system, the broadband connection is stable and so there’s no packet loss, and my broadband provider’s connection to Twitter’s servers is also loss free.
Those are the perfect conditions for HTTPS running over TCP. Not a packet dropped, not a bit of jitter, no congestion. It’s even the perfect conditions for HTTP/2 where multiple streams of requests and responses are being sent from my phone to websites and APIs as I boot my morning. Unlike HTTP/1.1, HTTP/2 is able to use a single TCP connection for multiple, simultaneously in flight requests. That has a significant speed advantage over the old way (one request after another per TCP connection) when conditions are good.
But I have to catch an early train, got to be to work by nine, so Continue reading
Today we announced support for encrypted SNI, an extension to the TLS 1.3 protocol that improves privacy of Internet users by preventing on-path observers, including ISPs, coffee shop owners and firewalls, from intercepting the TLS Server Name Indication (SNI) extension and using it to determine which websites users are visiting.
Encrypted SNI, together with other Internet security features already offered by Cloudflare for free, will make it harder to censor content and track users on the Internet. Read on to learn how it works.
The TLS Server Name Indication (SNI) extension, originally standardized back in 2003, lets servers host multiple TLS-enabled websites on the same set of IP addresses, by requiring clients to specify which site they want to connect to during the initial TLS handshake. Without SNI the server wouldn’t know, for example, which certificate to serve to the client, or which configuration to apply to the connection.
The client adds the SNI extension containing the hostname of the site it’s connecting to to the ClientHello message. It sends the ClientHello to the server during the TLS handshake. Unfortunately the ClientHello message is sent unencrypted, due to the fact that client and server don’t share Continue reading
Cloudflare launched on September 27, 2010. Since then, we've considered September 27th our birthday. This Thursday we'll be turning 8 years old.
Ever since our first birthday, we've used the occasion to launch new products or services. Over the years we came to the conclusion that the right thing to do to celebrate our birthday wasn't so much about launching products that we could make money from but instead to do things that were gifts back to our users and the Internet in general. My cofounder Michelle wrote about this tradition in a great blog post yesterday.
Personally, one of my proudest moments at Cloudflare came on our birthday in 2014 when we made HTTPS support free for all our users. At the time, people called us crazy — literally and repeatedly. Frankly, internally we had significant debates about whether we were crazy since encryption was the primary reason why people upgraded from a free account to a paid account.
But it was the right thing to do. The fact that encryption wasn't built into the web from the beginning was, in our mind, a bug. Today, almost exactly four years later, the web is nearly 80% encrypted thanks to Continue reading
I have always loved birthdays. It is a chance to get together with loved ones, a chance to have fun and a chance to reflect on anything you want to keep doing or change in the upcoming year. At Cloudflare, we’ve embraced celebrating our birthday as well.
This week, Cloudflare turns 8 years old. It feels like just yesterday that Matthew, Lee, Matthieu, Ian, Sri, Chris, Damon and I stepped on stage at Techcrunch Disrupt to launch Cloudflare to the world. Since then, we have celebrated our birthday every year by giving a gift back to our customers and the Internet. This year, we plan to celebrate each day with a new product benefiting our community. Or in other words, it is a weeklong birthday celebration. Like I said, I love birthdays!
The Cloudflare team when we launched the service at Techcrunch Disrupt during September 27 to 29, 2010 – Matthieu, Chris, Sri, Ian, Lee, Matthew, Michelle and Damon.
While I can’t share exactly what we’re releasing every day — after all who doesn’t like a surprise? — I wanted to share some thoughts on how we decide what to release birthday week.
Our mission at Cloudflare is to help Continue reading
When you visit a secure website, it offers you a TLS certificate that asserts its identity. Every certificate has an expiration date, and when it’s passed due, it is no longer valid. The idea is almost as old as the web itself: limiting the lifetime of certificates is meant to reduce the risk in case a TLS server’s secret key is compromised.
Certificates aren’t the only cryptographic artifacts that expire. When you visit a site protected by Cloudflare, we also tell you whether its certificate has been revoked (see our blog post on OCSP stapling) — for example, due to the secret key being compromised — and this value (a so-called OCSP staple) has an expiration date, too.
Thus, to determine if a certificate is valid and hasn’t been revoked, your system needs to know the current time. Indeed, time is crucial for the security of TLS and myriad other protocols. To help keep clocks in sync, we are announcing a free, high-availability, and low-latency authenticated time service called Roughtime, available at roughtime.cloudlare.com on port 2002.
It may surprise you to learn that, in practice, clients’ clocks are heavily skewed. A recent study of Continue reading
What could go wrong?
Two years ago this week Cloudflare introduced Opportunistic Encryption, a feature that provided additional security and performance benefits to websites that had not yet moved to HTTPS. Indeed, back in the old days some websites only used HTTP --- weird, right? “Opportunistic” here meant that the server advertised support for HTTP/2 via an HTTP Alternative Service header in the hopes that any browser that recognized the protocol could take advantage of those benefits in subsequent requests to that domain.
Around the same time, CEO Matthew Prince wrote about the importance and challenges of privacy on the Internet and tasked us to find a solution that provides convenience, security, and anonymity.
From neutralizing fingerprinting vectors and everyday browser trackers that Privacy Badger feeds on, all the way to mitigating correlation attacks that only big actors are capable of, guaranteeing privacy is a complicated challenge. Fortunately, the Tor Project addresses this extensive adversary model in Tor Browser.
However, the Internet is full of bad actors, and distinguishing Continue reading
This article will talk about our approach to network security using technologies like RPKI to sign Internet routes and protect our users and customers from route hijacks and misconfigurations. We are proud to announce we have started deploying active filtering by using RPKI for routing decisions and signing our routes.
Back in April, articles including our blog post on BGP and route-leaks were reported in the news, highlighting how IP addresses can be redirected maliciously or by mistake. While enormous, the underlying routing infrastructure, the bedrock of the Internet, has remained mostly unsecured.
At Cloudflare, we decided to secure our part of the Internet by protecting our customers and everyone using our services including our recursive resolver 1.1.1.1.
A prefix is a range of IP addresses, for instance, 10.0.0.0/24
, whose first address is 10.0.0.0
and the last one is 10.0.0.255
. A computer or a server usually have one. A router creates a list of reachable prefixes called a routing table and uses this routing table to transport packets from a source to a destination.
On the Internet, network Continue reading
We have talked about the BGP Internet routing protocol before. We have talked about how we build a more resilient network and how we can see outages at a country-level via BGP. We have even talked about the network community that is vital to the operation of the global Internet.
Today we need to talk about why existing operational practices for BGP routing and filtering have to significantly improve in order to finally stop route leaks and hijacks; which are sadly pervasive in today’s Internet routing world. In fact, the subtle art of running a BGP network and the various tools (both online and within your a networks subsystems) that are vital to making the Internet routing world a safe and reliable place to operate need to improve.
Internet routing and BGP and security along with its operational expertise must improve globally.
Nothing specific triggered today’s writing except the fact that Cloudflare has decided that it's high-time we took a leadership role to finally secure BGP routing. We believe that each and every network needs to change its mindset towards BGP security both on a day-by-day and a long-term basis.
It's time to stop Continue reading
Cloudflare first started talking about DNSSEC in 2014 and at the time, Nick Sullivan wrote: “DNSSEC is a valuable tool for improving the trust and integrity of DNS, the backbone of the modern Internet.”
Over the past four years, it has become an even more critical part of securing the internet. While HTTPS has gone a long way in preventing user sessions from being hijacked and maliciously (or innocuously) redirected, not all internet traffic is HTTPS. A safer Internet should secure every possible layer between a user and the origin they are intending to visit.
As a quick refresher, DNSSEC allows a user, application, or recursive resolver to trust that the answer to their DNS query is what the domain owner intends it to be. Put another way: DNSSEC proves authenticity and integrity (though not confidentiality) of a response from the authoritative nameserver. Doing so makes it much harder for a bad actor to inject malicious DNS records into the resolution path through BGP Leaks and cache poisoning. Trust in DNS matters even more when a domain is publishing record types that are used to declare trust for other systems. As a specific example, DNSSEC is helpful for preventing Continue reading
This post describes how to use Cloudflare's IPFS gateway to set up a website which is end-to-end secure, while maintaining the performance and reliability benefits of being served from Cloudflare’s edge network. If you'd rather read an introduction to the concepts behind IPFS first, you can find that in our announcement. Alternatively, you could skip straight to the developer docs to learn how to set up your own website.
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. Continue reading
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, Continue reading
The Internet is an amazing invention. We marvel at how it connects people, connects ideas, and makes the world smaller. But the Internet isn’t perfect. It was put together piecemeal through publicly funded research, private investment, and organic growth that has left us with an imperfect tapestry. It’s also evolving. People are constantly developing creative applications and finding new uses for existing Internet technology. Issues like privacy and security that were afterthoughts in the early days of the Internet are now supremely important. People are being tracked and monetized, websites and web services are being attacked in interesting new ways, and the fundamental system of trust the Internet is built on is showing signs of age. The Internet needs an upgrade, and one of the tools that can make things better, is cryptography.
Every day this week, Cloudflare will be announcing support for a new technology that uses cryptography to make the Internet better. Everything we are announcing this week is free to use and provides a meaningful step towards supporting a new capability or structural reinforcement. So why are we doing this? Because it’s good for the users and good for the Internet. Welcome to Crypto Week!
JAMstack Radio is a show all about the JAMstack, a new way to build fast & secure apps or websites. In the most recent episode, the host, Brian Douglas, met with Kenton Varda, tech lead for Cloudflare Workers and author of Sandstorm.io to discuss some of the infinite uses for running code at the edge.
Listen to what Kenton had to say about serverless technology in this twenty two minute podcast here:
Here's the transcript of the podcast as well:
Brian Douglas: Welcome to another installment of JAMstack Radio. In the room I've got Kenton Varda from Cloudflare.
Kenton Varda: Thanks for having me.
Brian: Thanks for coming all the way across San Francisco to chat with me in person. I'm curious who Kenton is, but I'm also curious what Cloudflare is. Can you answer both questions? Let's start with, "Who is Kenton?"
Kenton: I'm an engineer. I'm the architect of Cloudflare Workers. In a past life I worked for Google for several years. I was once known as the "protocol buffers guy," I was the one who open sourced that. And I founded a company called Sandstorm that was later acquired by Cloudflare.
Brian: I'm Continue reading
In October of last year we announced the launch of Cloudflare Workers. Workers allows you to run JavaScript from 150+ of Cloudflare’s data centers. This means that from the moment a request hits the Cloudflare network, you have full control over its destiny. One of the benefits of using Workers in combination with Cloudflare’s cache is that Workers allow you to have programmatic, and thus very granular control over the Cloudflare cache.
You can choose what to cache, how long to cache it for, the source it should be cached from, and you can even modify the cached result after it is retrieved from the cache.
We have seen many of our existing customers use Workers to enhance their usage of the Cloudflare cache, and we have seen many new customers join Cloudflare to take advantage of these unique benefits.
You can always have more control, so today we are announcing support for the Cache API! As some of you may know, Cloudflare Workers are built against the existing Service Worker APIs. One of the reasons we originally chose to model Cloudflare Workers after Service Workers was due to the existing familiarity and audience of Service Continue reading