Introducing SSL/TLS Recommender

A Smarter Path to Stronger Origin Encryption

Cloudflare’s Universal SSL, introduced seven years ago, was a turning point for Internet security. Before it, HTTPS deployment was largely limited to sites handling clearly sensitive data — passwords, credit card numbers — because the technical barrier to entry was so high. Universal SSL made encrypted connections available to any site, for free, and doubled the number of HTTPS-enabled sites on the web in the process.

That push was driven by a changing threat landscape. Tools like Firesheep made it trivial for attackers on public Wi-Fi to intercept session data. The Snowden revelations demonstrated how easily governments could collect unencrypted traffic at scale. More recently, Chromium has moved toward loading websites over HTTPS by default. Encryption is no longer a nice-to-have; it is a baseline expectation for the modern Internet.

But encrypting the link between a visitor’s browser and Cloudflare is only half the story. The connection between Cloudflare and the origin server — where the actual content lives — also needs to be secure. Weaker configurations on this backend link can leave traffic exposed even when the user-facing connection is fully encrypted.

Cloudflare’s SSL/TLS Recommender addresses this gap. It analyzes your existing origin configuration and provides guidance for moving to the strongest encryption mode your setup can support. The Recommender has been available since August 2020 in the SSL/TLS tab of the Cloudflare dashboard for self-serve customers, and more than 500,000 zones have adopted it. As of today, the tool is available to all Cloudflare customers.

Why the Backend Connection Matters

When a visitor loads content through Cloudflare, they connect over HTTPS. But Cloudflare must then fetch that content from your origin server. If that fetch happens in plaintext — or over a weak TLS version — the data is vulnerable at that stage. An attacker who can observe traffic between Cloudflare and the origin can see exactly what your users are seeing.

Misconfigured origin settings are common. Many servers support strong encryption but are set to accept weaker older protocols due to legacy clients or simply default configuration. The result is a lower level of encryption than both Cloudflare and your origin are capable of, with no benefit to compatibility.

How the Recommender Works

The Recommender examines several signals to understand your current setup:

• Whether your origin is currently serving valid certificates that can handle a full handshake
• Which SSL/TLS modes your origin actually supports when Cloudflare attempts connections
• Any errors or inconsistencies in how the origin responds to encrypted requests

Based on that analysis, it determines the most appropriate SSL/TLS mode for your zone — ranging from Off (no encryption to origin) to Full (strict), which requires a valid certificate on the origin and encrypts every connection with a full handshake. The recommendation is displayed directly in the SSL/TLS tab, along with one-click activation so you can apply the stronger setting immediately.

For example, if your zone is currently in Flexible mode but your origin presents a valid, trusted certificate, the Recommender will suggest moving to Full (strict). If the origin certificate has issues, it will steer you toward a mode that still enables encryption without breaking the connection, and will flag what needs to be fixed to go further. The tool only recommends changes it is confident will not interrupt service.

Guided Migration for Enterprise Customers

Enterprise customers often have complex, multiple-origin architectures where sweeping changes pose too much risk. For these deployments, Cloudflare is adding an extension to the SSL/TLS Recommender that guides users through migrating to stronger configurations in steps, rather than all at once. Rolling updates and staged validation give you control over how and when encryption changes go live across all your origin settings.

The Recommender has already simplified the decision-making process for hundreds of thousands of zones. Now that it is broadly available, we expect the default configuration across the Cloudflare network to shift further toward full encryption — moving the Internet one solid step closer to a default-secure architecture.

Choosing how Cloudflare talks to your origin

Cloudflare’s reverse proxy sits between visitors and origin servers. When a visitor requests content that isn’t cached, the edge server opens a new connection to the origin. That backend connection can be plain HTTP or HTTPS, which encrypts requests and responses with TLS. HTTPS is the secured form of HTTP and should be used whenever possible to avoid data leaks or tampering. Origins can further authenticate themselves by presenting a valid TLS certificate, preventing active monster-in-the-middle attacks. Certificates can come from a public CA like Let’s Encrypt or Cloudflare’s Origin CA, and origins can also enable authenticated origin pull so only Cloudflare can connect. A more secure alternative is Cloudflare Tunnel, where a lightweight daemon on the origin establishes private tunnels to Cloudflare data centers, letting you lock down the server to only accept routed requests.

Cloudflare cannot always use HTTPS to reach an origin. Some origins, such as certain shared hosting providers and even some government sites, have no TLS support at all and rely on Cloudflare to encrypt the visitor-facing leg of the connection. Probing an origin for TLS support turns out to be unreliable because many sites only partially support HTTPS. A single customer site may be served from multiple origins with different TLS capabilities — some support HTTPS on the landing page but not on every resource, and content may differ between HTTP and HTTPS versions. These inconsistencies stem from misconfigurations, developer mistakes during HTTPS migration, or intentional design.

Research from Northeastern University, the Max Planck Institute for Informatics, and the University of Maryland quantifies the problem: 1.5% of surveyed sites had at least one page unavailable over HTTPS even though the protocol worked on other pages, and 3.7% served different content over HTTP versus HTTPS for at least one page. Always forcing the most secure TLS setting on a resource can therefore break site functionality.

SSL/TLS encryption modes

Cloudflare relies on you to indicate your origin’s TLS support via the zone’s SSL/TLS encryption mode. The available modes are:

• Off — No encryption on either the client-to-Cloudflare or Cloudflare-to-origin connection. Only used by a few customers for legacy or test reasons; never recommended.
• Flexible — Clients use HTTPS to reach Cloudflare, but requests to the origin are HTTP-only. Intended as a last resort for origins without TLS support.
• Full — Encrypts requests to the origin when clients connect via HTTPS, but Cloudflare does not validate the origin’s certificate. Suitable for origins with self-signed certificates, but leaves you vulnerable to an active attacker presenting a fake certificate. HTTP client requests result in HTTP requests to the origin.
• Full (strict) — Cloudflare validates the origin certificate, which must be issued by a public CA or Cloudflare Origin CA. HTTP requests result in HTTP requests to the origin, same as Full. This is the strongly recommended mode when your origin supports it.
• Strict (SSL-Only Origin Pull) — All traffic to the origin goes over HTTPS, even if the client request was HTTP. This is an Enterprise-only option. Most customers should instead use Always Use HTTPS with Full or Full (strict) to redirect visitors to HTTPS content.

The encryption mode is zone-wide — the same policy applies to all subdomains and resources — though you can refine it with Page Rules. A misconfiguration can easily break the site. For example, if a zone is set to Full or Full (strict) but serves some assets from an HTTP-only subdomain, those assets will become unavailable to HTTPS visitors.

Why the backend connection matters

A proxied visit involves two connections: the front-end between visitor and Cloudflare, and the back-end between Cloudflare and origin. While the front-end often has the largest attack surface, insecure backend connections invite trouble. With Flexible mode, an origin connected through an untrustworthy ISP could have its plaintext traffic inspected by on-path middleboxes, leaking confidential data. Moving to Full or stronger encrypts that traffic and blocks basic snooping.

With Full mode, certificates aren’t validated. An attacker in the same shared hosting facility as your origin could ARP-spoof traffic meant for it and present a fake certificate. Cloudflare would accept it, and the attacker could inspect, filter, or inject malicious JavaScript into responses. Using a valid, Cloudflare-trusted certificate with Full (strict) prevents Cloudflare from trusting the fake and blocks the hijack. Securing the backend only improves security posture, so the recommendation is to use the highest encryption mode your origin can support.

Default settings aren’t forever

When Universal SSL launched, Cloudflare aimed to push sites away from plain HTTP. Zones without TLS support were defaulted to Flexible to preserve functionality, and that mode remains available because some customers still need it. Newly onboarded zones default to Full if a TLS certificate is detected, otherwise Flexible. These defaults can become stale as a site evolves — for example, after moving to a host that supports origin certificate installation. An origin that can serve all content over TLS should at least be on Full; one with a valid certificate should be on Full (strict) to resist monster-in-the-middle attacks.

Combining academic research and engineering experience, the Cloudflare Research team built a tool to keep encryption both easy and secure as origins change. That tool is SSL/TLS Recommender.

How Cloudflare Decides When You Can Tighten TLS

Cloudflare's SSL/TLS Recommender is designed to answer a specific question: when can a customer move to a more secure encryption mode without breaking their site? The feature, available from the SSL/TLS tab in the Cloudflare dashboard, uses the zone's currently configured option as a baseline for expected behavior. It runs a series of checks to see if an upgrade is possible, then emails the zone owner with its recommendation if one exists. The tool deliberately avoids suggesting downgrades, even if the current configuration is faulty (such as an HTTP-only origin paired with Full mode).

Simple Upgrades: Full to Full (Strict)

The most straightforward case is moving from Full to Full (strict). Since all resources are already served over HTTPS, the Recommender only needs to validate the TLS certificates for the domain and every subdomain, which may live on separate origin servers.

Complex Upgrades: Flexible or Off to Full

Upgrading from Off or Flexible to Full is more involved. A site qualifies only if every resource is reachable over HTTPS and the content served over HTTP matches what HTTPS returns. The Recommender performs this verification in three steps:

• Crawl the site. For large properties where scanning every link is impractical, the crawler tests only a subset up to a set threshold, trading thoroughness against potential false positives. When the crawl yields too few links, the Recommender supplements results with samples from recent visitor requests to keep confidence high. The crawler identifies itself with the Cloudflare-SSLDetector user agent and is registered as a known good bot. Like other Cloudflare crawlers, it ignores robots.txt unless a rule explicitly targets its user agent, so that crawl restrictions do not skew the recommendation.
• Fetch over both protocols. The tool downloads each link's content over HTTP and HTTPS using only idempotent GET requests, avoiding any modification of origin server state.
• Compare content. A similarity algorithm, adapted from the TMA Conference 2020 paper "A Deeper Look at Web Content Availability and Consistency over HTTP/S", scores how closely the two versions match. The method is built to stay accurate even when pages contain dynamic content.

Conservative by Design

The Recommender prioritizes working sites over stronger encryption. It will decline to issue a recommendation if the zone is non-functional, if the owner blocks all bots, or if misconfigured SSL-specific Page Rules interfere with scanning. This means the feature is not a diagnostic tool for broken domains, but a safeguard for locking down zones that are already healthy.

Questions and feedback can be sent to [email protected].

The project is led by the Cloudflare Research team with contributions from across the company. The current iteration was built by interns Suleman Ahmad (now full-time), Talha Paracha, and Ananya Ghose, with Matthew Bernhard laying the groundwork in an earlier version.