Sunset of SSL Extended
By David Gamey - 22 Dec 2015.
If you’ve been struggling with keeping up with various SSL vulnerabilities and planning an orderly cutover to TLS then the recent announcement by the PCI Council has extending the sunset date for the transition from SSL to TLS 1.1 and 1.2 should come as welcome relief.
SSL the ever ubiquitous security hallmark of the Internet age is proving to be more difficult to retire than previously thought. And like the protesting peasant in Monty Python’s “Bring Out Your Dead” sketch it does not want to go quietly into the night.
The newly updated mandate still requires that organizations are able to support TLS 1.1 or 1.2 by June 2016 but allows up to an additional two years for organizations to complete the sunset of SSL. This allows organizations to support the stronger protocols where it can be used and to work through legacy connections in a more orderly fashion. The exemption for POI devices that can be shown to have secure use cases remains in place.
The council has prepared several communications including a blog article, a press release, and webinar that our own David Gamey participated in as a subject matter expert.
This decision was based on significant feedback from industry and security experts that considered factors such as the availability of TLS 1.1 and 1.2 in deployed solutions, a variety of different SSL use cases, contractual and logistical limitations, and risk.
- Browsers using SSL are still the highest risk.
- Non-browser applications, such as business to business connections, will need to be evaluated on their use cases.
- POIs are generally the lowest risk.
Let’s be clear SSL as a general purpose security protocol is broken and the continued effort to nurse it along and deal with the security or insecurity numerous special use cases is simply unsustainable. SSL (and TLS 1.0) need to be replaced as quickly as possible and applications which can’t be easily replaced need to be evaluated and prioritized. This extension allows organizations to do precisely that.
Some Other References:
- "Recommendation for Key Management, Part 1 Revision 3 [2012]" http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57part1rev3_general.pdf covers key management and isn't about protocols
- "Guidelines on Securing Public Web Servers[2012]" http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf speaks to configuring public web servers with SSL 3.0
- "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementation [2014]" http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf rejects SSL because "it is not approved for use in the protection of Federal information because it relies in part on the use of cryptographic algorithms that are not Approved".
- Paper describing POODLE https://www.openssl.org/~bodo/ssl-poodle.pdf
- An article discussing POODLE countermeasures http://www.zdnet.com/article/when-poodles-attack-ips-and-ngfw-are-your-first-defense/