PCI Council published several materials that should help to understand the problem and guide the providers with migration effort:
• Bulletin on Migrating from SSL and Early TLS
• Information Supplement on Migrating from SSL and Early TLS
• FAQs: 1372, 1373
PCI TLS migration can be summarized in two steps, depending on the payment channel used to process the card authorisation/payment:
1. For card-present transactions install the latest updates or perform upgrade of the software on payment terminals, according to guidance provided by POS terminal provider.
2. For card-not-present transactions processed as “e-commerce” amend the configuration on www servers and “API host” servers to eliminate the cipher suites that are considered to be “weak” or for which known vulnerabilities have been published, for example: BEAST, POODLE, Heartbleed, Logjam, Sweet32, ROBOT, etc.
Internal usage of TLS over LAN: be compliant with PCI DSS “strong cryptography”
Described above usage of TLS and selection of TLS cipher suites refers to external facing server-side devices that are used either by web browsers or “API clients” (mobile/web application) to secure transfer of card data over public networks in line with requirement 4.1 and 4.2 of PCI DSS. The standard does not require to encrypt transmission of card data inside the organisation’s network – cardholder data can be sent within private networks in clear text, so no encryption is needed (or “weak encryption” is allowed) for transmission of sensitive card details over LAN.
In terms of the internal usage of TLS as valid “strong cryptography” mechanism per PCI DSS, for example to achieve compliance with requirement 8.2.1 of rendering all authentication credentials unreadable during transmission, if password hashing is not in use during authentication (POP3, IMAP, SMTP, AUTH, MySQL), it is vital to ensure that all systems and their internal components support communication over higher version of TLS (v1.2 is “strongly encouraged” by the PCI Council). On the example of “programming/computing/storage” environment based on Microsoft products it is important to ensure that all system modules support TLS higher than v1.0: Win Server, MS SQL, ADO.NET client, .NET framework, etc.
TLS (Transport Layer Security) and its earlier version SSL (Secure Sockets Layer) is a set of cryptographic protocols used to secure data in-transit. It’s most popular usage is to encrypt the exchange of data between user’s browser and www server over https. It is used however in many other forms of communications where there is a need to provide data integrity and privacy/confidentiality, for example: host-to-site VPN tunnels like OpenVPN, OpenConnect, and its commercial implementation e.g. Cisco AnyConnect or Juniper Pulse Secure, secure email connections over STARTTLS, or encrypted VoIP over SIP (Session Initiation Protocol).
SSL was designed to work over TCP (Transmission Control Protocol) but there is also a standard for UDP (User Datagram Protocol), namely DTLS (Datagram Transport Layer Security). Most TLS programming libraries are free and licenced as open source software – detailed comparison can be found on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
Broadly speaking each TLS session in a browser consists of two (layers) protocols:
• TLS handshake is the initial layer used to exchange the information needed to secure the transfer of data by both sides: specific version of TLS, suggested and accepted cipher suites, format of messages, order of exchange, etc.
• TLS record protocol is the exchange of data between a user and a server and is responsible for encrypting and authenticating the messages, but also dividing and reassembling sent messages.
Hardening external TLS – choosing the secure cipher suits
To secure TLS communication certain ciphers must be disabled on “server-side” devices responsible for establishing TLS handshake: www/API servers, load-balancers, firewalls, WAFs (Web Application Firewalls) and any other device that is responsible for accepting incoming TLS connections to IT environment. Initial guidance can be found for example on Mozilla Wiki as “Recommended” or “Intermediate” configuration for TLS servers.
The main problem with eliminating most of available cipher suits is the possibility of cutting off users with older devices/browsers that will not be able to establish the connection after removal of all supported cipher suits on their client side, and therefore rejecting to provide service to retail customers, or alternatively forcing them to upgrade their outdated devices. It seems like there is very little choice in terms of secure TLS cipher suites:
• RC4 is not recommend in TLS implementation after multiple vulnerabilities were published in 2013 by N. AlFardan, D. Bernstein, K. Paterson, B. Poettering, J. Schuldt.
• MD5 was officially classified as "cryptographically broken and unsuitable for further use" by the Software Engineering Institute in 2010.
• Poodle attack that downgrades SSL/TLS connection to earlier versions eliminated initially all SSL implementations, and in 2014 also specific TLS 1.0-1.2 protocols due to exploits that target CBC (Cipher Block Chaining) encryption mode.
• Sweet32 vulnerability almost eliminated the usage of 3DES algorithm for symmetric encryption, so broadly speaking we are left with AES (AES GCM is preferred), or less popular ChaCha20 (a variant of Salsa20/20) published by Daniel J. Bernstein in 2008.
• Recent “re-discovery” of ROBOT attack eliminated the usage of RSA for secure key exchange, however Rivest-Shamir-Adleman algorithm is still considered to be safe for TLS signatures.
• Logjam attack on weak Diffie-Hellman (<=1024 bit) mandates the usage of ECDHE (Elliptic-curve Diffie–Hellman) or stronger but slower Diffie-Hellman key exchange (>2048 bit).
• Due to collision in SHA-1 discovered earlier but confirmed practically only this year hashing should be used with higher implementation of “signature algorithms”, namely SHA-2 family (SHA256, SHA384, SHA512).
• For Message Authentication HMAC based on SHA-2 is preferred, or Daniel J. Bernstein’s Poly1305, typically used in conjunction with ChaCha20 (ChaCha20+Poly1305).
• For digital signatures which are responsible for encrypting a representation of a message (a message digest), RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm) are acceptable, but DSA newer implementation ECDSA (Elliptic Curve Digital Signature Algorithm) is recommended.
• PCI Council from July 2018 mandates the usage of secure version of TLSv1.1 or TLSv1.2, so all earlier implementations of TLS/SSL must be abandoned.
• Forward Secrecy which prevents compromising of past session keys in case of compromise of long-term keys is only available in TLS with the usage of Diffie-Hellman or Elliptic-curve Diffie–Hellman key exchange.
To validate how changes introduced on a server side are going to impact end-user devices and which of them are not going to be able to complete TLS handshake successfully, and therefore initiate TLS connection it is worth to perform a handshake simulation with each of the test devices and specific configuration that is going to be used against the server. For initial overview of impact on most popular operating systems (Android, Apple iOS, MS Windows) and browsers (Chrome, Mozilla, MS IE) test your new settings with “SSL Labs” provided by Qualys, Inc. and examine “Handshake Simulation” section: https://www.ssllabs.com/ssltest/analyze.html
Hardening example on most popular web-servers: MS ISS/Apache HTTP/Nginx
Configuration of selected TLS cipher suites on Microsoft’s web server: Internet Information Services (IIS) on Win Server 2008/2012/2016 can be done by changing manually the entries in the system registry. The easiest way however to apply chosen cipher suites on MS ISS is to install the free tool offered by Nartac Software “IIS Crypto”, which offers easy to use tick-boxes to implement required TLS configuration.
Most popular Linux based web-servers: Apache HTTP and Nginx, can be easily configured with the use of online tool maintained on Mozilla GitHub: “SSL Configuration Generator” that enables to choose desired parameters, server version, etc. and advises the required configuration that can be amended within minutes by copying the content of the wizard and pasting it directly into the server console.
TLS cipher suites verification
After examining the available cipher suites administrators may not be left with much choice to provide the service to retail customers. In fact, more less similar problem is faced by TLS standard regulators (ietf.org) which defer to publish the long-awaited update of TLS to version 1.3. Newest implementation should resolve most security issues with TLS protocol but also simplify full TLS handshake from two round-trips to only one round-trip and therefore speed up the load of TLS sites over slower connection.
There are several tools available that can help with identifying which TLS cipher suites are setup on the server-side:
• NMAP scripting engine: https://svn.nmap.org/nmap/scripts/ssl-enum-ciphers.nse
• CipherScan: https://github.com/mozilla/cipherscan
• SSLyze: https://github.com/nabla-c0d3/sslyze
• SSL Scan: https://github.com/rbsec/sslscan
• SSL Labs
• High-Tech Bridge
• SSL Shoper
Cloudflare blog about implementation of TLS v1.3 at https://blog.cloudflare.com/tls-1-3-explained-by-the-cloudflare-crypto-team-at-33c3/.
Cisco publication: “Next Generation Encryption” at https://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html.
eSTREAM, the ECRYPT Stream Cipher Project at http://www.ecrypt.eu.org.