Sweet32 (CVE-2016-2183) and Cloudflare

Sweet32 or CVE-2016-2183 is a vulnerability in the use of the Triple DES (3DES) encryption algorithm in the Transport Layer Security (TLS) protocol. This vulnerability is a type of cryptographic attack known as a "Birthday Attack" that exploits the probability of finding collisions in a given ciphertext. Birthday attacks are so called because they are based on the probability that two or more people in a group of 23 share the same birthday is greater than 50%; such a result is called a birthday paradox.

Because 3DES has a 64-bit block size there is a high probability that given 2^32 blocks, you will encounter two blocks that collide. Once a collision has been found between two ciphertext blocks, you can work out how the corresponding plaintext blocks are related. This knowledge combined with several other attributes allows the decryption of the encrypted text.

Practicality

This attack only affects ciphers with a 64-bit block size.

To succeed, the attacker needs to collect at least 32GB of data from a single TLS session.

In many scenarios, recovering only the xor between two plaintext blocks is not sufficient for an effective attack. However the attack will be effective if a fixed secret is sent repeatedly, or some fraction of the plaintext is known.

This is currently only a proof of concept attack - there are no known examples of this in the wild. The PoC specifically mentioned in the paper that disclosed this issue assumes some authentication token is passed between the server and client for all of its communications (token could be a cookie of credentials used in basic authentication). The attacker then runs a malicious JavaScript in the origin of the website which is being attacked. A BEAST-style attack can then be used to extract the cookie.

What does this mean for PCI?

Sweet32 has been given a CVSS score of 5.0. Under PCI guidelines the presence any vulnerability with a CVSS score greater than 4.0 is considered a failure in a PCI vulnerability scan. However this does not mean that the an organization will fail a PCI audit or lose its PCI status. Following PCI guidelines any vulnerability like this should be evaluated to determine whether there is mitigation in place.

If the vulnerability has been mitigated then the ASV responsible for scanning the organization should mark it as a false positive.

If the vulnerability has not been mitigated then the QSA or ASV should identify the vulnerability to the organization and allow them time to remediate the issue before triggering a rescan.

Only if a vulnerability with a CVSS score greater than 4.0 remains unmitigated with no action plan to resolve it should it be considered a PCI failure.

What is Cloudflare doing about this?

Cloudflare has implemented two changes to address this issue:

As there is no legitimate traffic on TLS 1.1 or TLS 1.2 using 3DES, we have dropped 3DES for TLS 1.1 and 1.2.

A significant amount of traffic from legacy Windows XP based systems still use 3DES on TLS 1.0. As a result the decision has been made to mitigate the vulnerability in this case. Since the vulnerability requires the attacker collect 32GB of data from a single long lived TLS session, we have configured our systems to re-key TLS 1.0 sessions using 3DES after an unspecified volume of data, long before the necessary 32GB. This prevents an attacker from collecting enough data, and therefore renders the attack impractical.

What if I use Cloudflare but still fail compliance due to Sweet32?

Automatic scans, such as those carried out by PCI ASV's look for the presence of vulnerabilities. They do this by detecting whether a potentially vulnerable service is present before confirming that the version matches one known to be vulnerable. However they do not confirm whether or not a suspected vulnerable service is actually exploitable. This is because taking that extra step can be destructive should it successfully trigger a vulnerability. This means these services are also unable to tell when a vulnerable service has been modified or mitigated to make it safe.

In the case of the Sweet32 vulnerability, switching off the vulnerable 3DES cipher on TLS 1.1 and TLS 1.2 was an easy decision. For those versions of TLS, the browsers that are capable of using 3DES are also capable of using more secure ciphers. However in the case of TLS 1.0, it is not quite so simple. For many browsers on legacy operating systems - such as Windows XP - and many embedded devices, TLS 1.0 and 3DES is the primary choice. Removing this choice would effectively stop these devices from being able to work with encrypted TLS connections. This is why we made the decision to mitigate the vulnerability rather than simply turning it off.

For an attacker to successfully exploit this attack they have to collect 2^32 blocks or roughly 32GB of data from a single TLS session. So to prevent exploitation, we modified our version of this cipher to force the session to re-key after an unspecified, much smaller amount of data has passed over the wire. By preventing an attacker from collecting the necessary amount of data, we prevent attackers from being able to exploit this vulnerability.

What should I tell my PCI auditor if they detect the presence of Sweet32?

Please pass the above statement on to them. Tell them that while they may still detect the presence of Sweet32 on TLS 1.0, it is a false positive. The vulnerability has been completely mitigated. The PCI Council makes it clear to ASVs that any vulnerabilities which have been fully mitigated or marked as a false positive must not be used against a site seeking PCI certification. Furthermore in the PCI ASV program guide the PCI council states that "The ASV is REQUIRED to investigate false positives with a CVSS Base score at or above 4.0 (failing score).", which would apply in the case of Sweet32.