TLS decryption

Cloudflare Gateway can perform SSL/TLS decryption Open external link 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.

​​ Enable TLS decryption

1. In Zero Trust Open external link , go to Settings > Network.
2. Scroll down to Firewall.
3. Turn on TLS decryption.
4. (Optional) Select Enable only cipher suites and TLS versions compliant with FIPS 140-2.

​​ Limitations

Gateway does not support TLS decryption for applications which use:

• Embedded certificates
• Self-signed certificates
• Mutual TLS (mTLS) authentication
• ESNI and ECH handshake encryption

​​ Incompatible certificates

Applications that use embedded certificates and mTLS authentication do not trust the Cloudflare certificate. For example, the vast majority of mobile applications use embedded certificates. Conversely, 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, these applications may not load or may return an error. You can resolve the issue by adding the Cloudflare certificate to the application (if supported by the application) or by exempting the application from TLS decryption.

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

To bypass TLS decryption, add a Do Not Inspect HTTP policy for the application or domain. The HTTP policy builder provides a list of trusted applications that are known to use embedded certificates. When accessing a Do Not Inspect site in the browser, you will see a Your connection is not private warning, which you can proceed through to connect.

HTTPS traffic from Do Not Inspect applications will not be intercepted by Gateway or subject to your HTTP policies. You can, however, still apply network policies to these applications.

​​ ESNI and ECH

Websites that adhere to ESNI or ECH standards Open external link 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.

​​ 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

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