In this post, SIP Architect Rohit Upasani discusses the technical aspects of TLS 1.2, its benefits in securing customer data and why the PCI SSC has called for migration to it before June 30th 2018.
Securing data while it transmits between applications is critical to ensure no eavesdropping or rogue entity tampers the data.
When it comes to the payment card industry, the PCI security standards council constantly monitors and empowers organisations so customer account data can be handled in more secure ways. PCI DSS v3.1 proposed phasing out the vulnerable Secure Sockets Layer protocol (SSL)/early versions of Transport layer security (TLS), which is no longer considered to be secure enough for payment card information.
Here is some technical guidance on what this means to your business and the actions you may need to take to upgrade your security protocols:
Securing the communication
Internet communications based on TCP/IP protocol, such as HTTP, is not secure because all communication goes via plain text. Any confidential or sensitive information sent using plain text is not considered suitable for normal web traffic and certainly not for financial transactions.
After all, web servers that use less secure way to communicate with clients are considered easy targets for denial of service and other types of data security attacks.
Why is TLS needed in first place?
The primary goal of TLS protocol is to achieve Cryptographic security in communication between applications.
TLS protocol is the successor to SSL. If we keep aside the small differences the two protocols are largely the same. SSL was originally released in 1995 by Netscape and has undergone different versions to cope with security flaws; this has been subsequently replaced by TLS v1.0.
PCI-DSS defines security standards to ensure card holder data is secure while it transmits from one entity to another. The guidelines of using strong cryptographic therefore means using secure protocol such as TLS is recommended.
How TLS works
TLS uses a set of cryptographic algorithms to authenticate and encrypt network connection between two web entities.
The client and server uses a TLS based ‘handshake’ before any higher level communication (e.g. web traffic, Email etc) takes place; they agree on the protocol version, cryptographic algorithms and optionally authenticate each other. By doing so, the secure attributes for a session are negotiated and enforced.
What are the drawbacks in SSL and Early TLS?
It is vital to ensure security standards are maintained, as attacks on data using old systems may not be sufficient to block them. For example;
BEAST – discovered in 2011, an attacker can exploit vulnerabilities in SSL3.0/TLS1.0 and gain access to authentication data passing through secure web sessions.
POODLE – discovered in 2014, systems using SSL3.0 appear to be prone to this kind of attack in which attackers can gather information from a secure web session, including passwords and cookies.
There are other similar security vulnerabilities like CRIME, BREACH, which effectively compromise the security of web sessions as provided by SSL/TLS1.0. Online and e-commerce environments using SSL or early TLS are most susceptible to these vulnerabilities and should be upgraded immediately.
How TLS v1.2 overcomes vulnerabilities
TLS v1.2 increases security of communication by adding far more powerful techniques to build cryptographic primitives than ever before. This includes:
- PRF definition refinement – Pseudorandom function(PRF) are vital tools used to build cryptographic primitives e.g. one-way hash function or public key cryptography. TLS v1.2 removes security flaws by replacing hash functions MD5 and SHA-1 to SHA-256 for PRF.
- Enhanced client and server capabilities to negotiate hashes and signature algorithms
- Enhanced cipher suite with advance encryption algorithm(AES)
The way forward and PCI Security Council recommendation
The PCI Security Standards Council recommends migration from SSL or early TLS to TLS v1.2 without delay. It suggests:
- Upgrading to a secure version of TLS that is implemented securely and configured to not accept fall back to SSL/early TLS.
- Setting up a strongly-encrypted session first (e.g. IPsec tunnel), then sending data over SSL within the secure tunnel.
The PCI Security Standards Council has put a deadline in place of 30th June 2018 for all organisations following its best practices to migrate from SSL/TLS to TLS v1.2 or higher. The time to act is now. If you require guidance on migrating to TLS v1.2 or higher, contact our technical team at PCI Pal for support.