On January 30, 2015, QSAs received the latest edition of the Council’s Assessor Newsletter. Buried in that edition was the following statement.
“Notice: PCI DSS and PA-DSS v3.1 Revisions Coming
In order to address a few minor updates and clarifications and one impacting change, there will be a revision for PCI DSS and PA-DSS v3.0 in the very near future. The impacting change is related to several vulnerabilities in the SSL protocol. Because of this, no version of SSL meets PCI SSC’s definition of “strong cryptography,” and updates to the standards are needed to address this issue. (Highlighting emphasis added by the PCI Guru)
We are working with industry stakeholders to determine the impact and the best way to address the issue. While we do not have the final publication date, our goal is to keep you apprised of the progress and to provide you with advanced notification for these pending changes. We are also preparing several FAQs that will accompany release of the revised standards.
Should you have any questions, please contact your Program Manager.”
Because the announcement was titled about the coming v3.1 revisions to the PCI DSS and PA-DSS standards, I am sure a lot of QSAs missed this pronouncement.
Not that this should be a surprise to any QSA as the POODLE vulnerability effectively killed SSL. The Council has now officially announced that SSL is no longer deemed to be strong cryptography.
Therefore, those of you still using SSL to secure transmissions containing cardholder data (CHD) need to stop that practice as soon as possible and convert to TLS or IPSec.
UPDATE: On February 13, 2015, the PCI SSC issued an update to their original announcement in the Assessor Newsletter.
PCI Guru 
A short survey from the SSC has hit my inbox, the questions are about how many are using SSL, TLS, or both, and what the remediation times are.
Same here. Looks like the Council is reaching out to the community to find out what is workable.
How can you tell if a particular website is using TLS or SSL in its certificate? I’ve tried various openssl methods of analyzing the certificate, and can’t figure it out.
I use the Qualys SSL Testing site – https://www.ssllabs.com/ssltest
There is not a way to tell by looking at the certificate. The only way to tell is by interrogating the actual response returned by the server. The ssllabs.com site, as mentioned, will do the trick for any externally facing site. For internal sites, it will not help. For checking internal sites, you can use OpenSSL.
OpenSSL’s s_client command allows you to issue an HTTPS client query, and you can specify which protocols or cipher suites you want it to use. For example:
> openssl s_client -connect web.myhost.com:443 -ssl3
That will make an HTTPS connection to web.myhost.com on port 443 using SSLv3 only. If it connects successfully (it will show connection details like the cipher suite used, session ID, etc.), then the server supports that protocol version. If it fails (looks similar to success, but does not have any data in the detail fields), it does not. For checking the full range of protocols you would use:
-ssl2 (SSLv2 which, hopefully, no one is still supporting)
-ssl3
-tls1
-tls1_1 (TLSv1.1)
-tls1_2
If you are on a Windows platform, you can get pre-compiled versions of OpenSSL, or compile it yourself with very little effort.
Hope that helps.
Kurt
They should be more precise and specifically mention SSLv3.
The prior versions of SSL have serious flaws, so it technically involves all versions of SSL. Only SSLv3 was acceptable until POODLE was discovered.
The point being that for example TLS 1.0 is actually SSL 3.1 in the protocol messages.
People in my professional circles are upset at this.
PCI SSC has always referred to NIST for the definition of “strong cryptography” and now they are by passing this practice, it is unprecedented and I believe dangerous
POODLE has demonstrated weaknesses in SSLv3 implementation of HTTP. We all agree secured web traffic should be using up to date mecanisms, like TLSv1.2 and GCM ciphers. That is is simple and easy part, web browsers are up to date, by their makers, and web servers are a target and need to stay up to date.
But condemning SSLv3 altogether brings down POS terminals, that DO NO use HTTP, they use serial over IP or other protocols, and most are built over SSL and TLSv1. And until it is demonstrated that POODLE applies, SSLv3 should not be eradicated with such dramatic fashion.
It is as though the PCI SSC is playing the perception game. And all the while, Target leading the way a year ago, POS’es running on Windows are flowing CHD out to black markets with no stopping in sight…
Until we see how SSL is actually dealt with in the DSS, we might be jumping the gun. Definitely using SSL on public networks is finished. Using it internally may still be allowed albeit with a CCW. We will have to see what v3.1 of the PCI DSS and the Reporting Template will actually give us.
NIST is referenced for guidance, not definition. The SSC cunningly includes provision for evolving security practices throughout the DSS.
It is not cunning so much as an understanding that what might be secure today, may not be secure tomorrow. That way they do not have to issue constant updates as the threat landscape changes.
The next bag of encryption fun will be the weak RC4 ciphers people have re-enabled to allow Windows XP/IE users to connect to payment sites due to CBC cipher severity score going above 5 and causing scans to fail.
Once RC4 goes above severity 5, bye bye XP/IE combos as that will be the last cipher it supports…..and loads of websites with “Please get a modern browser” messages.
Although, if I didn’t work for the government, I’d have got rid of IE8 support ages ago, but unfortunately we have to be inclusive and can’t force people to buy modern operating systems with modern browsers.
Do you reckon the score for RC4 ciphers will be going up soon? I heard it was being attacked more so seemed likely to me. I’m guessing it will be a PCI fail vulnerability in the next 12 months.
No idea if RC4 will be next to go. MD5, SHA-1 and SHA-2 are still around and they all have various known flaws as well.
We went through the browser battles early on with online banking here in the US. The federal regulators pushed that through on the banks, so it was a regulatory issue not any one bank doing it which made it more “acceptable”. There still was pain in customer service calls from people running 95/98/ME/2000, but it died off within six to nine months. The government here are driven by FISMA which also can therefore be used as a scapegoat for the various agencies and departments.
With respect, SHA-1 and SHA-2 do not belong in the same category as MD5. MD5 is plain-and-simple broken. SHA-1, which uses a similar structure, has theoretical weaknesses, but it is still not feasible to generate actual collisions. Doing so is only a matter of time (my guess is probably ~ 1 year), which is why Microsoft, Mozilla, and Google all have plans to drop SHA-1 before 2017. SHA-2, which has a structure very similar to SHA-1, does not have any practical attacks either, but given its similarity to SHA-1, it is not unreasonable to think that SHA-2 will start showing cracks within the next couple years.
As to RC4, I would argue that it is right on the cusp of actually being worse than no encryption at all. It creates the appearance of security, but it does not really provide it. At least if it was clear text and you *knew* it was clear text, you might be able to apply some mitigating controls.
Add into the mix triple DES (3DES) and you have a perfect storm. NIST has been warning people for years that 3DES was nearing the end of its security with only the 168-bit form being deemed still secure. However, with the advent of the Cloud, I am sure that 3DES will see its life come to an end in the next few years.
As to the various SHA attacks. From my reading, the exploits had been proven and were no longer theoretical. I know in the forensic field they have run into issues with SHA-1 collisions. So the flaws in the algorithm have been observed.
So, for a site taking credit cards, what changes would need to be made? For a site that is taking credit cards directly running through a POS system?
I’m confused by your point of sale (POS) comment. Not sure what exactly you mean by it. I’m assuming that you mean a Web site collects cardholder data (CHD) and then transmits it electronically to a person who them enters that information manually into a POS system.
Any Web site that is processing, storing or transmitting CHD needs to disable SSL and only use TLS. This can be done with the SSL/TLS certificate by getting new certificates that only support TLS. YOu can also configure the Web application server such as Tomcat, Apache, Internet Information Server (IIS), etc. to reject SSL connections over HTTPS if you do not change the certificate. This link can provide you with a list of solutions based on your application server. https://zmap.io/sslv3/servers.html
I think that the point here is that some of the POS systems utilise payment software installed on the POS which talks to the PED over USB. I’ve come across payment software installed on POS systems which utilise SSL to talk to the payment gateway for authorisation/settlement. Its interesting since the payment gateway will have a much harder job in switching from SSL since they will need to wait for all the payment software instances to be upgraded.
Interesting. Since that SSL would not be on a public network and over USB, it could still be relied upon because of those facts although you would need to do a CCW to explain that.
The way our customer’s systems process cards is that a customer walks up at a fast food counter or goes through the drive thru, orders their food, then hands the cashier a card. That card is swiped directly on the POS terminal that is connected to an internal network to a server that is the ONLY piece of equipment facing the Internet. The server computer sends the card through an SSL connection using software loaded on the computer. I am just curious if there is anything that needs to be changed on the back office computer or should it all be handled by the software and the web address used to process the cards? I have no direct connection to the website processing cards nor do I have a direct connection to the software used at the terminal or on the server. I work for a reseller/vendor that supplies the systems.
I’m just curious for an FYI on our part because the sites would call us rather than calling the equipment vendor for questions/answers.
That SSL connection over the Internet from the server to the processor is the problem and should be converted to TLS.
It would depend if the POS is doing the payment on behalf of the PED. I’ve come across PEDs that send the CHD over USB to the POS and then some client software is installed which is interacting with said PED. The CHD is sent from the POS client software to the payment gateway (over the internet) using SSL.
That is how Target and other retailers were breached. Most large retailers are using a solution that takes unencrypted data from the point of interaction (POI – aka card terminal) through a serial/USB connection and then encrypt it and transmit it from the POS PC. Encryption can be everything from SSL, DUKPT, 3DES and AES.
What does mean for https? Can cardholders not enter card data through a website anymore?
TLS replaces SSL. However, older versions of TLS are at issue as well, so you will need to use TLS v1.2 or greater.
And for what it is worth, if you used the AES cipher suites in GCM mode (only available in TLSv1.2) you get a significant performance boost. Depending upon what you are comparing it to, you could expect improvements of 50+%.