Skip to content
Cloudflare Docs

TLS decryption

Cloudflare Gateway can perform SSL/TLS decryption ↗ in order to inspect HTTPS traffic for malware and other security risks.

When you enable TLS decryption, Gateway will decrypt all traffic sent over HTTPS, apply your HTTP policies, and then re-encrypt the request with a user-side certificate. Gateway will decrypt and re-encrypt traffic regardless of HTTP policy action, including Do Not Inspect.

Cloudflare prevents interference by decrypting, inspecting, and re-encrypting HTTPS requests in its data centers in memory only. Gateway only stores eligible cache content at rest. All cache disks are encrypted at rest. You can configure where TLS decryption takes place with Regional Services in the Cloudflare Data Localization Suite (DLS).

Cloudflare supports connections from users to Gateway over TLS 1.1, 1.2, and 1.3.

Enable TLS decryption

  1. In Zero Trust ↗, go to Settings > Network.
  2. Turn on TLS decryption.

Inspection limitations

Gateway does not support TLS decryption for applications which use:

Incompatible certificates

Applications that use certificate pinning and mTLS authentication do not trust Cloudflare certificates. For example, most mobile applications use certificate pinning. Cloudflare does not trust applications that use self-signed certificates instead of certificates signed by a public CA.

If you try to perform TLS decryption on an application with an incompatible certificate configuration, the application may return an SSL or trust error and/or fail to load. To resolve this issue, you can:

  • Add a Cloudflare certificate to supported applications.
  • Create a Do Not Inspect policy to exempt applications from inspection. The Application selector provides a list of trusted applications that are known to use embedded certificates. Note that if you create a Do Not Inspect policy for an application or website, you will lose the ability to log or block HTTP requests, apply DLP policies, and perform AV scanning.
  • Configure a Split Tunnel in Include mode to ensure Gateway will only inspect traffic destined for your IPs or domains. This is useful for organizations that deploy Zero Trust on users’ personal devices or otherwise expect personal applications to be used.

Alternatively, to allow HTTP filtering while accessing a site with an insecure certificate, set your Untrusted certificate action to Pass through.

Google Chrome automatic HTTPS upgrades

Google Chrome can automatically upgrade HTTP requests to HTTPS requests, even when you select a link that explicitly declares http://. When you use Gateway to proxy and filter your traffic, this upgrade can interrupt the connection between your Zero Trust users and Gateway.

You can turn off automatic HTTPS upgrades via a Gateway pass through policy, a Chrome browser flag, or a Chrome Enterprise policy.

To disable automatic HTTPS upgrades for a URL across your Zero Trust organization, create a Gateway pass through policy.

  1. Deploy a custom root certificate.

  2. Create an HTTP policy to match the domain of the URL being automatically upgraded. For example:

    SelectorOperatorValueAction
    URLinexample.comAllow

  3. In Untrusted certificate action, choose Pass through.

  4. Select Create policy.

The pass through policy will bypass insecure connection upgrades for any device connected to your Zero Trust organization. For more information, refer to Untrusted certificates.

ESNI and ECH

Websites that adhere to ESNI or ECH standards ↗ encrypt the Server Name Indicator (SNI) during the TLS handshake and are therefore incompatible with HTTP inspection. This is because Gateway relies on the SNI to match an HTTP request to a policy.

You can still apply all network policy filters except for SNI and SNI Domain. To restrict ESNI and ECH traffic, an option is to filter out all port 80 and 443 traffic that does not include an SNI header.

FIPS compliance

By default, TLS decryption can use both TLS version 1.2 and 1.3. However, some environments such as FedRAMP may require cipher suites and TLS versions compliant with FIPS 140-2. FIPS compliance currently requires TLS version 1.2.

Enable FIPS compliance

  1. In Zero Trust ↗, go to Settings > Network.
  2. Turn on TLS decryption.
  1. Select Enable only cipher suites and TLS versions compliant with FIPS 140-2.

Limitations

When FIPS compliance is enabled, Gateway will only choose FIPS-compliant cipher suites when connecting to the origin. If the origin does not support FIPS-compliant ciphers, the request will fail.

FIPS-compliant traffic defaults to HTTP/3. Gateway does not inspect HTTP/3 traffic from most browsers, including Chrome, Firefox, and Safari. To enforce your HTTP policies for this HTTP/3 traffic, you must disable QUIC in your users’ browsers.

Cipher suites

A set of encryption algorithms for establishing a secure communications connection. There are several cipher suites in wide use, and a client and server agree on the cipher suite to use when establishing the TLS connection. Support of multiple cipher suites allows compatibility across various clients.

The following table lists the default cipher suites Gateway uses for TLS decryption.

Name (OpenSSL)Name (IANA)FIPS-compliant
ECDHE-ECDSA-AES128-GCM-SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256✅
ECDHE-ECDSA-AES256-GCM-SHA384TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384✅
ECDHE-RSA-AES128-GCM-SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256✅
ECDHE-RSA-AES256-GCM-SHA384TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384✅
ECDHE-RSA-AES128-SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256❌
ECDHE-RSA-AES256-SHA384TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384✅
AES128-GCM-SHA256TLS_RSA_WITH_AES_128_GCM_SHA256✅
AES256-GCM-SHA384TLS_RSA_WITH_AES_256_GCM_SHA384✅
AES128-SHATLS_RSA_WITH_AES_128_CBC_SHA❌
AES256-SHATLS_RSA_WITH_AES_256_CBC_SHA❌

For more information on cipher suites, refer to Cipher suites.

Cloudflare DashboardDiscordCommunityLearning CenterSupport Portal
Cookie Settings