Time to follow the RFC’s (Request for Comments) ?
During the last year, there have been discussions in the industry about the usage of SSL version 3.0 (including early TLS) and how it has been considered not to be secure enough to be used in a PCI environment. Since PCI DSS only states that SSL version 2.0 is forbidden and afterward only specifies the use of strong cryptology, it appears strange that we still would allow SSL version 3 in a CDE environment after the publication of RFC 7568 (Deprecating Secure Sockets Layer Version 3.0).
This became possible since the PCI SSC determined that there where many devices that circulated who only supported older version of the protocol and the replacement would not be possible to enforce over a short period of time. Therefore, they defined a gracing period, initially set to June 2016. So in effect, they would allow it for an additional year, despite the published RFC.
Since then the industry has been trying to comply with the new requirements and it became apparent that the gracing period would not suffice. Therefore, they just released a new announcement setting the final transition date to June 2018. Effectively setting a 3-year transition period for this vulnerability.
However, this gracing period should only be used as an exception (where it’s justifiable due to hardware/configuration constraints) and not a standard mitigation action, since postponing taking action against securing you card holder data environment isn’t the best course of action that you can do.
The exception is only to be considered if you can justify it based on constrains or technical limitation which has been communicated as below:
“We will continue to encourage everyone to complete migration as soon as possible and not to look at the extended Compliance period as a reason to delay taking action. All entities using SSL/early TLS should have a Risk Mitigation and Migration Plan outlining their plans for transition to a more secure protocol and how they will manage risk in the interim” – PCI SSC
I would like to visualize the reason why you should strongly consider removing the support for both SSL version 3.0 and the early TLS versions as stated in the PCI DSS update. The way I have chosen to visualize this is by comparing the release years with other current events in the world, which we should be able to relate to. Therefore, I selected some major events like Disney movies release years and of course, some relevant gaming news. As you will be able to see, some of these specifications have been around for some time. Like for instance SSL version 2, which dates back to the original release of Command and Concur.
For the SSL version 3 specification release year, I’ve chosen the release of the Nintendo 64 game console in order to showcase from which era it actually belongs to. Also the modern browser of Internet Explorer 3.0 was also release the same year and it’s things from this time period that you rely on for securing your transmissions.
TLS version 1.0 was released in the previous millennium, so it has been plenty of time to implement this protocol. The same goes for TLS version 1.1 which was released 2006 (10 years ago) and of course TLS version 1.2 which is the new kid on the block and thus only have been available since 2008 (8 years). In that last number lies an interesting fact, the first Android phone became available in that year. This is important since in the first versions of Android, you have support for neither TLS 1.1 nor 1.2.
The means of mitigating the issues is either to disable the protocol or have means to protect against the attack that is described in the link collection below.
Sources:
Exploiting POODLE: https://patzke.org/implementing-the-poodle-attack.html
Wikipedia: https://en.wikipedia.org/wiki/Transport_Layer_Security
RFC (https://www.ietf.org/): 6101, 6176, 7568, 2246, 4346 and 5246.