Please see the latest news from the PCI Council on this topic published 12/18/2015 which extends migration dates to 2018:Date Change for Migrating from SSL and Early TLS
In April 2015 the PCI Council released “PCI-DSS v3.1”. Additionally released was an information supplement entitled “Migrating from SSL and Early TLS” which clarified risks associated with SSL/TLS and remediation strategies, including mitigation & migration plans. For example, they have clarified that SSL and early TLS cannot be used as a security control after June 30th, 2016 at which point it will become an automatic fail for PCI, and the mere detection of one of these weak ciphers on a Quarterly ASV Scan will be marked as a PCI Fail. However, in the meantime SSL and early TLS can still be used on existing implementations, and so currently during an ASV Scan you will not automatically fail for the detection of one of these weak ciphers.
However, vulnerabilities using SSLv3 or early TLS still need to be remediated, as they always have under the established PCI Requirements. Per page 6 of “Migrating from SSL and Early TLS”:
“Additionally, all SSL/TLS vulnerabilities that score CVSS 4 or higher on an ASV scan, or are ranked as “high” on an entity’s internal vulnerability scan, must be addressed within the required timeframe (e.g. quarterly for ASV scans) in order to meet PCI DSS Requirement 11.2. Follow defined vulnerability management processes to document how SSL/TLS vulnerabilities are addressed –for example, where it is used only for POI communications that are not susceptible to the exploits, or where it is present but is not being used as a security control (e.g. is not being used to protect confidentiality of the communication).”
This means if your scan shows a vulnerability such as QID 38603 POODLE that leverages SSLv3, this would still be marked as a PCI Fail. You can work to submit this as a PCI False Positive Request along with documentation showing the ASV that you have successfully mitigated the risk, i.e. are not currently vulnerable/exploitable, or have compensating controls in place which successfully mitigate the attack vector. Essentially, you will still need to verify that there is no ‘Real-World Risk’ at which point it can be approved as a PCI False Positive Request.
Merchants should focus on Mitigating any SSLv3 or early TLS vulnerabilities now, if they cannot completely remove them from their Cardholder Data Environments, and on Migrating completely away from these controls prior to the June 2016 deadline.
Migrating from SSL and Early TLS