Learn how to configure Cloudflare to meet PCI scan requirements and understand what mitigations Cloudflare has in place for earlier versions of TLS/SSL.

Overview

Both TLS 1.0 and TLS 1.1 are insufficient for protecting information due to known vulnerabilities. Specifically for Cloudflare customers, the primary impact of PCI is that TLS 1.0 and TLS 1.1 are insufficient to secure payment card related traffic.

PCI standards recommend using TLS 1.2. Below, you can review our list of recommended Cloudflare SSL configurations for PCI compliance.

Also see what mitigations Cloudflare implements against vulnerabilities for TLS 1.0 and 1.1.

Recommended Cloudflare SSL configurations for PCI compliance

• Set the Minimum TLS Version to TLS 1.2 or newer

Set Minimum TLS Version to 1.2

To configure your Cloudflare domain to only allow connections using TLS 1.2 or newer protocols:

1. Log in to the Cloudflare dashboard.

2. Click the appropriate Cloudflare account for the domain.

3. Ensure the proper domain is selected.

4. Click on the Cloudflare SSL/TLS app.

5. Scroll to the Minimum TLS Version section.

6. Select TLS 1.2.

Failed PCI Scans from Security Metrics

If you are experiencing failed PCI Scans from Security Metrics, please follow our recommendations below.

Issue #1 - CPE Based Vulnerabilities for Linux 2.6.18 - 2.6.22

The scanner has detected the hosts behind IP addresses fronting 'customer website' to be Linux 2.6.18 - 2.6.22 and missing patches for several high severity vulnerabilities.

Answer: Cloudflare has confirmed with our internal system dashboard and noted that we don't have these older kernel versions, Linux 2.6.18 - 2.6.22 running in our environment. The oldest version we can find is 4.19.78. Please work with your Security Metrics contact to let them know that this should be filed as a false positive.

Issue #2 - SSL Certificate for www.csutomerwebsite.com Cannot Be Trusted

The following certificate was part of the certificate chain sent by the remote host, but it has an invalid OCSPResponse signature : |-Subject : C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=customerwebsite.com |-OCSP Signature : Decryption Failed. Note: It is possible that signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that SecurityMetrics either does not support or does not recognize

Answer: Security Metrics has confirmed that this is a false positive. Their validation mechanism doesn't fully support OSCP stapling. Please work with your Security Metrics contact to let them know that this should be filed as a false positive.

Cloudflare mitigations against known TLS vulnerabilities

There are several mitigations Cloudflare performs against known vulnerabilities for TLS versions prior to 1.2. For example, Cloudflare does not support:

1. Header compression in TLS
2. Header compression in SPDY 3.1
3. RC4
4. SSL 3.0
5. Renegotiation with clients
6. DHE ciphersuites
7. Export-grade ciphers

Cloudflare mitigations protect against several attacks:

• CRIME
• BREACH
• POODLE
• RC4 Cryptographic Weaknesses
• SSL Renegotiation Attack
• Protocol Downgrade Attacks
• FREAK
• LogJam
• 3DES is disabled entirely for TLS 1.1 and 1.2 and Cloudflare implements mitigations for TLS 1.0

Cloudflare provides additional mitigations for:

• Heartbleed
• Lucky Thirteen
• CCS injection vulnerability

Cloudflare has patched all servers against these vulnerabilities. Also, the Cloudflare WAF has rules to mitigate several of these vulnerabilities including Heartbleed and ShellShock.

HTTP/2 and HTTP/1.1 Cleartext Detection (Paid Plans Only):

Use Cloudflare WAF rule 100015 to restrict connections to only port 80 and 443 if you aren't using other open Cloudflare ports. You can find WAF rule 100015 in the Cloudflare UI for your domain:

1. Click the Cloudflare Firewall app.
2. Click the Managed Rules tab.
3. Click Advanced under the Cloudflare Managed Rules section.
4. Enter 100015 in the search field and click Search.
5. Set the Mode of rule 100015 to Block.

Once enabled, the additional Cloudflare ports are still open, but no data is sent to those ports as the WAF blocks the request with an HTTP 403 response.

Return of Bleichenbacher's Oracle Threat (ROBOT)

Security scans that note the presence of ROBOT while on Cloudflare are a false positive. Cloudflare checks padding in real time and swaps to a random session key if the padding is incorrect.

Web Application Cookies Not Marked Secure

The Cloudflare cfduid cookie is used for security purposes and cannot be disabled. The cfduid cookie doesn't contain any confidential or sensitive information and is used to note whether a user has passed javascript challenges such as used by Under Attack Mode.

Sweet32 (CVE-2016-2183)

A vulnerability in the use of the Triple DES (3DES) encryption algorithm in the Transport Layer Security (TLS) protocol. Sweet32 is currently a proof of concept attack, there are no known examples of this in the wild. Cloudflare has manually mitigated the vulnerability for TLS 1.0 in the following manner:

• attacker must collect 32GB of data from a single TLS session
• Cloudflare forces new TLS 1.0 session keys on the affected 3DES cipher well before 32GB of data is collected

Related resources

More articles on TLS, cipher, browser, and protocol support

undefined

• Using Minimum TLS Version in Cloudflare SSL/TLS - Transport Layer Security (TLS) guarantees encrypted communications between a client and a web server via HTTPS. It replaces the now deprecated Secured Sockets Layer (SSL) protocol.