The group that manages the Payment Card Industry Data Security Standard quietly announced in February that an imminent update was coming to its payment card and application requirements related to the use of the SSL encryption protocol. Since then, there has been growing concern among merchants about what the changes mean to them.
The confusion among retailers generally can be boiled down to two questions:
- What will the new updates require me to do?
- What happens to my TSL/SSL certificates?
First let’s explain what’s going on: On Feb. 13, the PCI Security Standards Council informed its assessor community that SSL (Secure Sockets Layer) – a protocol designed to ensure that data provided between a web server and a web browser, such as credit card information, remains secure – is no longer an acceptable way to provide “strong cryptography.” This is due to a number of known fundamental vulnerabilities – some of which, such as Heartbleed, we have documented here, here and here – that essentially make SSL, as an encryption mechanism, obsolete.
In March, the council made the news official by offering additional information (PDF) in the form of an FAQ, including encouraging merchants to upgrade to SSL’s successor, a much-stronger protocol known as Transport Layer Security (TLS). Think of TLS – the current version is 1.2 – as a more evolved version of SSL. With the migration, retailers are getting rid of the old stuff that doesn’t work very well anymore.
The PCI council also stated that later this month it will publish an update (version 3.1) to the PCI DSS. An update to the Payment Application DSS (PA-DSS) is scheduled to follow. Merchants will be given a certain amount of time to implement the changes.
While the council doesn’t plan to immediately crack the whip on retailers, many of whom are still getting comfortable with the 3.0 versions of both payment standards, businesses should become familiar with their new payment security responsibilities.
So let’s go back to the earlier questions:
For merchants, such as e-commerce companies, accepting payments in card-not-present environments, they must disable SSL and configure their web servers to use the most recent version of TLS. If they outsource the management and maintenance of their commerce environment to a hosting provider, then they must ensure that the vendor will do this for them. Card-present merchants, on the other hand, must consult with their point-of-sale and payment application vendors to ensure the payment-acceptance software they are using is not communicating with the SSL protocol.
Nothing, unless you have reason to believe that you were compromised with one of the recent SSL exploits. Your certificates are, essentially, files that store cryptographic key information and identification information for whom the certificate was issued. The SSL or TLS protocol is just part of the way the server defines the ‘rules’ for how that encryption is implemented into the conversation between the client and server.
Retailers of all types should stay on top of this developing situation, considering what we know about the dangers of SSL as an encryption protocol, as well as the fact that a business may be able to outsource certain commerce responsibilities to a third-party, but not its liability associated with a data breach.
So, those are the basics of what you need to know. If you have any additional questions or concerns, please leave them in the comments.
Note: This blog post was adapted from an original piece by Dan Kaplan on the SecureTrust blog.