I started to blog when I was already working on virtualization technologies, but before this I was a security consultant, and I still hold my CISSP certification. So, for once I’m writing something about security more than virtualization, because this news about SSL totally deserves an article.
TLS is hard… let’s keep SSL for a while
I’ve read an article from The Register few weeks ago, and one phrase was perfect to summarize the content:
The Payment Card Industry Security Standards Council (PCI SSC) has decided to delay the deadline for migration from Secure Sockets Layer (SSL) to Transport Layer Security (TLS)
You can read the official document from the PCI Council here. Simple as it’s written, this is a bad bad news for security. First, the scope: the PCI Council is the one who decides the security standards that every bank and credit card company has to follow. That’s why I immediately thought this topic would have been important to discuss.
SSL, the cypher protocol used to encrypt communications during transactions (involving money in this case) has been broken since many years by now, and that’s the reason that new and improved technologies like TLS have been developed. Encryption is an ongoing cycle of new algorithms introduced into the market, then broken by some new research (or the brute force of new CPU generations able to compute the keys…), while a new and more robust algorith superseeds the previous one.
This is what happened also with SSL: SSL v1 was originally developed by Netscape but never released, and the first public version was v2.0, released in 1995. This is 21 years ago, and many improvements and releases have followed the original one. I’ve created this table as a summary (you can read the complete history here):
| PROTOCOL | RELEASED | RFC | KNOWN ATTACKS | DEPRECATED |
| SSL v1.0 | n/a | |||
| SSL v2.0 | 1995 | 2011 | ||
| SSL v3.0 | 1996 | 6101 | 2014 – POODLE | 2015 |
| TLS 1.0 | 1999 | 2246 | 2014 – POODLE TLS (misconfigured TLS) | |
| TLS 1.1 | 2006 | 4346 | ||
| TLS 1.2 | 2008 | 5246 | ||
| TLS 1.3 | TBD |
I said in the title that security many times is a legacy problem: people needs to keep existing protocols even if they are not secure, because too many users are relying on them and the sudden disablement of the old protocols could lead to massive disruption of services. Take for example the jump between SSL 3.0 and TLS 1.0, that is the topic of the PCI Council: the differences between TLS 1.0 and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0.
TLS 1.0 can downgrade the connection to SSL 3.0 (thus weakening security), so PCI Council planned to jump directly to the more secure TLS 1.1. Some may argue, reading the previous statement, that the jump to TLS 1.0 would have been easier: just start using TLS 1.0, so that native TLS clients would have been immediately able to leverage this protocol (that is not insecure yet) while old clients could have still be able to connect via SSL 3.0. In March 2011 a new major revision of all TLS protocols made in RFC 6176 removed the backward compatibility with SSL so that TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0. Still, downgrade to SSL 3.0 was possible, also because SSL 3.0 was deprecated only later in 2015, so after this revision.
Whatever is the reason, the final effect is that still we can have, in 2016, companies using insecure SSL versions to protect the communications we do with them, and still be totally PCI compliant… Sounds stupid, isn’t it? And it’s even more stupid if you read some of the reasons stated in the document (phrases have been rewritten in my own words…):
– TLS 1.1 is required by 2018, when it will be 12 years old, TLS 1.2 is “preferred” because it will be “only” 10 years old in 2018
– some old “point of interaction” (read it, peripherals…) are not vulnerable to SSL (are you sure?), so even if they are old as the universe, they are good to go
– this is the best one “We’re working very hard with representatives from every part of the ecosystem to make sure (the switch) it happens before the bad guys break in,”
Yeah, sure… While you are working hard, the bad guys have already broke in many times: POODLE was disclosed in October 2014, and it made SSL 3.0 totally insecure. Keeping backwards compatibility with SSL 3.0 after POODLE is, how can I say it politely, a TOTALLY STUPID move. And POODLE has not even been the only one (ever heard of HeartBleed?), and those are just the disclosed vulnerabilities, who knows how many more are around that are known by bad guys and not by us.
Final Notes
The legacy problem, if you are dealing with security involving people and/or their money, is an unjustifiable lame excuse.
Let me rewrite the honest version of the statement: “We are making huge amounts of money by transacting your operations. Replacing many old devices we use would cost us too much money compared to what we would like to spend, so please let us make more money before we finally decide to make your transactions more secure. Oh, and if anything happens between now and 2018, well, ops…”
Next time you are looking for a bank or another company to deal with your money via electronic means, don’t just look if they are PCI compliant, because we just learned that it’s nothing more than a statement written on paper. Dear PCI guys, security is something else…
(ps: you can check your online banking security or other websites with tools like Qualys SSL Server Test)