As of March 25, 2021, the Internet Engineering Task Force (IETF) released RFC 8996, which formally deprecated the use of TLS v1.1—a deprecation that is a result of evolving cryptographic standards. Some of the primary reasons for the shift to TLS 1.2 include:
-
Versions 1.1 and 1.0 lack support for current and recommended cryptographic algorithms and mechanisms.
-
Versions 1.1 and 1.0 require the implementation of older cipher suites that are no longer desirable for cryptographic reasons.
-
There is a lack of support for current recommended cipher suites, especially authenticated encryption with associated data (AEAD) ciphers, which were not supported prior to TLS 1.2.
-
The integrity of the handshake depends on SHA-1 hash, allowing an attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash.
(Please refer to the RFC for full details.)
As PCI QSAs, we are often asked which TLS protocols are acceptable for use regarding the cardholder data environment. Though the PCI DSS itself does not mandate specific industry standards for meeting strong cryptography, it does recommend that entities monitor changes to industry standards and best practices for cryptographic protocols, and where applicable, make changes to apply minimum cryptographic standards within their environments, especially with respect to securing sensitive information such as authentication credentials and cardholder data. Furthermore, PCI DSS actually does require that all cryptographic implementations—including TLS—use and support modern cryptographic algorithms, secure configuration settings, and other features as needed to meet the intent of strong cryptography.
As is actually stated in FAQ #1491, “this means that every TLS implementation, irrespective of the protocol version, must apply strong cryptography using an appropriate cipher suite to implement a secure key exchange algorithm, strong cryptography, and an appropriate message authentication for strong cryptography and security protocols.” Notably, there are a few critical areas within the PCI DSS where the use of strong cryptography using TLS comes into play:
-
Requirement 2.3: Encrypt all non-console administrative access to systems in-scope for a PCI DSS assessment using strong cryptography. This includes non-console connections to systems over Remote Desktop Protocol, SSH, as well as any web-based administrative consoles (which could use TLS v1.1).
-
Requirement 4.1: Use strong cryptography and security protocols when transmitting sensitive cardholder data over open, public networks.
-
Requirement 8.2.1: Use strong cryptography to render all authentications credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
What Should I Do Next?
While the PCI SSC has not specifically commented on the deprecation of TLS v1.1, they have reiterated the guidance provided in FAQ #1491 mentioned above. Entities planning for their annual PCI assessment should begin taking steps immediately to determine where TLS v1.1 may exist in their environments. Reviewing internal and external vulnerability scan reports is a good starting point, since the protocol should now start flagging as a high or critical finding. Not only will the scans identify already known instances of TLS v1.1, but they should also identify any instances that may have not been previously known. Once identified, organizations can then start developing a path forward, including removing cases of TLS v1.1 where possible, or implementing an appropriate compensating control for those that may require additional time to resolve. Consider checking with your assessor on whether the compensating control being considered is likely to be acceptable for your assessment.
Some might say the writing has been on the wall since August 29, 2019, when NIST published SP 800-52 Rev. 2, Guidelines for TLS Implementations. Be that as it may, efforts should be made to remove deprecated protocols, including TLS v1.1, as soon as possible to ensure that the security of the cardholder data environment is not impacted. As cryptographic protocols continue to evolve, entities should continue to review industry standards and best practices regarding such while monitoring for new vulnerabilities to existing protocols.
About the Author
More Content by Jeff Lasker
