Five principles for applied research
Cloudflare Research was founded two years ago with a broad mandate: use fundamental and applied computer science to help build a better Internet. In practice, that means the team operates like a support organization inside the company, identifying and nurturing ideas that are three to five years from production. Five operating principles guide that work, each illustrated by a real project that has moved from question to deployed feature.
Innovation comes from all places
Research is most effective when it isn't confined to a lab. Cloudflare Research embeds with product, engineering, and ETI teams to learn what problems are worth solving, and reaches outward to visiting researchers, academia, standards bodies, and conferences. The team includes both specialists and generalists, and its work spans the full stack — from initial idea to prototype to production code. Research interns play a key role in evaluating and de-risking ideas before they're handed off to the teams that will own them long-term.
A good example is the work on password security. Have I Been Pwned, a service that tells people whether their passwords have appeared in known breaches, runs on Cloudflare. But the setup exposed a privacy problem: the service necessarily sees every password submitted to it. A solution first emerged from the support engineering organization, which developed an approach based on k-anonymity. That work revealed a much deeper problem space, and the research team brought in outside expertise, including Thomas Ristenpart at Cornell Tech.
The collaboration produced a new protocol, published as "Protocols for Checking Compromised Credentials" at ACM CCS 2019. Building a working version required a visiting researcher, and the project gained momentum internally when another Cloudflare team wanted Web Application Firewall capabilities for detecting breached passwords. The result was a customer-facing feature that also advanced the state of privacy-preserving authentication technology.
A question-oriented approach
The research team takes a question-first stance, even toward products that are already solving real problems. The questions are broad: How will social and geopolitical forces change what we build? Which assumptions in existing systems reflect the homogeneous experiences of their creators? What new hardware, computing paradigms, or user expectations are on the horizon? By focusing on questions that can't be answered in the short term, the team has a chance to see around corners.
The SSL/TLS Recommender grew out of a valid product critique. Cloudflare made SSL certificates free and automatic, but its "Flexible SSL" mode leaves the connection between Cloudflare and the origin server unencrypted for backward compatibility. The so-called "mullet" criticism noted that encryption covered the front half of the connection but not the back. Most security risk sits between the user and Cloudflare — at the ISP or in a coffee shop — so Flexible SSL customers were still far better off. But a few isolated failures to use the most secure configuration produced real security problems.
With help from research interns with scanning and measurement expertise, the team built a crawling tool to quantify how much improvement was possible. It turned out to be a lot. The team connected that scanning infrastructure to Cloudflare's product, and the SSL/TLS recommender has since helped thousands of customers secure their sites. The project also left researchers with tools to keep studying why websites fail to encrypt parts of their backends.
Build the tools today for tomorrow's issues
Thousands of companies depend on Cloudflare's infrastructure, which means preparing for worst-case scenarios is part of the job. The team's approach mirrors that of a forestry service or public health department: identify areas of future risk, explore the fundamentals, build expertise validated in peer-reviewed venues, gain operating experience with prototypes, and build relationships with people who can help in a crisis.
That kind of preparation led to a deep look at IPv4 address exhaustion. There are only about four billion potential IPv4 addresses — fewer than the number of humans, let alone connected devices. Cloudflare's anycast architecture already challenges one fundamental assumption: a server IP address doesn't correspond to a specific machine. Any server can serve any customer site, which lets the service scale with minimal effort.
That raised a follow-up question: if an IP address doesn't need to map to a specific server, what else could be decoupled from it? Could hostnames be decoupled from IPs? The team ran an experiment serving all free customers in an entire region from the same IP, in a cross-organizational effort involving the DNS team, the IP addressing team, and the edge load balancing team. The experiment proved that a single IP could serve millions of services, though it also exposed risks. The work was published at ACM SIGCOMM 2021, and it led to a project to re-architect Cloudflare's authoritative DNS system for far greater flexibility.
From Paper to Production
A significant part of Cloudflare's research mission involves taking ideas from academic papers and internal brainstorms and turning them into real, deployed systems. The path from a theoretical concept to a production service often requires solving challenges that only appear at scale, and the payoff is a deeper understanding of the problem than any simulation can offer.
The company’s work on Oblivious DNS is a prime example. When Cloudflare launched its 1.1.1.1 recursive DNS service in 2019, it did so with DNS-over-HTTPS (DoH) to encrypt queries in transit. However, DoH alone does not hide the user's IP address from the resolver. While Cloudflare had privacy policies and audits in place to minimize IP retention, the real question was whether the service could be designed to not require that sensitive data in the first place. The Onion Resolver was a step in that direction but proved too slow for everyday use. The challenge of creating a cryptographically private DNS with acceptable performance remained an open problem.
The solution emerged from a combination of new academic research and industry collaboration. Knowledge of a novel proxying technique called Oblivious DNS, along with Apple and Fastly working on similar problems, led to the creation of Oblivious DoH (ODoH). The protocol was published and discussed at the IETF, which is critical for a standards-dependent system like DNS. The research team built an early prototype on Cloudflare Workers to measure performance and validate the approach, publishing their findings in a paper at PoPETS 2021. The success of that experiment led to a production implementation for 1.1.1.1, with open-source code released in Go, Rust, and a Workers-compatible version. The protocol has also been integrated into tools like dnscrypt to encourage wider adoption.
The Value of Follow-Through
Academic culture often rewards the initial breakthrough, not the long, difficult process of making it work in the real world. At Cloudflare's scale, the follow-through is where the most valuable insights are found. A minor inconvenience in a lab can become a major obstacle when handling millions of requests per second, and vice-versa: a small detail in a paper can unlock massive potential for improvement.
This ability to experiment in a live environment is a unique advantage. With nearly every user on the Internet touching Cloudflare's network directly or indirectly, the team can observe the real-world impact of ideas that previously existed only in theory. This is especially true for cryptographic tools like zero-knowledge proofs, which have been studied for decades but are only now finding practical applications in the modern web.
Why CAPTCHAs Are on the Way Out
Not all research questions are deep networking puzzles. Some are about improving the immediate user experience. CAPTCHAs, a common tool for blocking bots, are notoriously frustrating and are often inaccessible to users with disabilities. While the Bots team has used machine learning to reduce the number of CAPTCHAs shown, a better solution was sought.
This search led to the development of the Cryptographic Attestation of Personhood (CAP). Instead of asking a user to perform a human task, CAP asks them to prove they have trusted physical hardware, using the widely deployed WebAuthn standard. This allows users to authenticate with a hardware security key or a device’s built-in biometric system. The project also raised important questions about privacy and user perception. In collaboration with an intern experienced in anonymous authentication, the team published a paper at SAC 2021 that uses zero-knowledge cryptography to add privacy features, answering questions about what data is and is not collected. The ubiquity of Cloudflare’s network allows the team to deploy this new authentication method to millions of users and study how it is received.
A Research Roadmap on the Blog
Over the next several days, the Cloudflare blog will feature a series of posts focusing on its research. Look for a new landing page with resources, technical deep dives into research papers and standards like the ones mentioned above, and details on how to collaborate with the team.
