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.
Enable TLS decryption
- In Zero Trust, go to Settings > Network.
- Scroll down to Firewall.
- Turn on TLS decryption.
- (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 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.
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.
Cipher suites
The following table lists the cipher suites Gateway uses for TLS decryption.
Cipher suite | Default | FIPS-compliant |
---|---|---|
CHACHA20-POLY1305-SHA256 | ✅ | ✅ |
ECDHE-ECDSA-AES128-GCM-SHA256 | ✅ | ✅ |
ECDHE-ECDSA-AES256-GCM-SHA384 | ✅ | ✅ |
ECDHE-RSA-AES128-GCM-SHA256 | ✅ | ✅ |
ECDHE-RSA-AES256-GCM-SHA384 | ✅ | ✅ |
ECDHE-RSA-AES128-SHA | ✅ | ❌ |
ECDHE-RSA-AES256-SHA384 | ✅ | ✅ |
AES128-GCM-SHA256 | ✅ | ✅ |
AES256-GCM-SHA384 | ✅ | ✅ |
AES128-SHA | ✅ | ❌ |
AES256-SHA | ✅ | ❌ |