Between SSL-cylla and Charib-TLS

By Jacob Ansari, Manager, Schellman & Company, Inc.

Securing encrypted Internet traffic transmissions, such as those between web browsers and web servers, is decidedly not simple. Despite the fact that well-established protocols, namely Secure Sockets Layer (SSL) and Transport Layer Security (TLS), have seen use for many years, they still have some complexities and security vulnerabilities. The most recent version of the Payment Card Industry Data Security Standard (PCI DSS), version 3.1, published in May 2015, specifically addressed some of the problems arising from vulnerable versions of SSL and TLS, and set the stage for a more rigorous approach to evaluating the security of the transport-layer protocols and mechanisms used for secure data communications. Unfortunately, navigating the particulars of communications protocols and cryptographic implementations can prove challenging. Further, some of the requirements to remove old, insecure protocols have proven particularly challenging for some organizations and in December 2015, the PCI SSC extended its deadline to eliminate SSL and early TLS by a full two years. Perhaps to best clear up some of the confusion around good security practice for these protocols, consider three elements: protocol versions, cipher groups, and software versions.

The last 12 to 15 months has seen a significant upheaval in the threat landscape for securing Internet communications. In late 2014, security researchers at Google published the details of an attack they called POODLE (for Padding Oracle on Downgraded Legacy Encryption), which exploited a deficiency in one of the most common security protocols used on the Internet, Secure Sockets Layer (SSL), and allowed an attacker to determine the encryption key used in a supposedly secure connection and decrypt the data in transit. Despite the fact that this particular protocol was developed by Netscape in the 1990s and had been replaced by a better protocol called Transport Layer Security (TLS), version 3 of the SSL protocol (SSLv3) remained in popular use for many years. Further research revealed that version 1.0 of TLS had similar weaknesses that allowed a similar attack: decrypting web traffic with comparatively little reference data and computing power. Security practitioners and standards organizations began advising against the use of SSLv3 or TLSv1.0, which, while entirely correct from a security perspective, has caused no small difficulty for endpoints that don’t support TLSv1.1 or v1.2, such as older versions of Internet Explorer and numerous Android devices that no longer get software updates from their manufacturer. This issue, in particular, has had a cascading effect, where organizations that interact with endpoints like old browsers often hesitate to disable support for these vulnerable protocols, particularly TLSv1.0, and then the organizations that interface with them find themselves faced with the need to continue this support. While the complexities of negotiating the interactions amongst clients and servers and differing organizations mean that eliminating vulnerable protocols will take careful planning and disciplined execution, organizations should not hesitate to eliminate actively the use of SSLv3 and TLSv1.0, as these versions of the protocols are fundamentally insecure, and attacks against them will become easier and more widespread.

Beyond the question of protocol version, when a client and server first begin communication, they negotiate the means by which they will communicate. This also includes the groups of cryptographic ciphers they use, commonly known as cipher suites. Like protocol versions, most systems open negotiations using the best options, but many systems will allow other, more insecure cipher suites for communication. Without getting too far into the technical details, a cipher suite consists of a key-exchange protocol, usually Diffie-Hellman or RSA, which is used to prevent attackers from impersonating legitimate sites; a symmetric-key cipher used to encrypt the messages that go back and forth; and a cryptographic hash function, used to verify that an error or attack didn’t alter the message in transmission. Over the years, certain ciphers and key lengths proved less resistant to attacks given currently available computing power, and security experts no longer consider them effective for secure communications. Nevertheless, many servers and clients still support their use, and this can lead to some significant security problems such as the attacks from 2015 called FREAK and Logjam. Properly securing this environment usually involves making configuration changes to only support cipher suites that contain only strong encryption.

The last major area is hardly unique to software used for securing data transmission: patches and security updates. The software used to establish TLS connections for web servers, and other types of systems has complexities and bugs and security weaknesses like any other piece of software. In fact, because of the complexity of doing cryptography right, popular implementations often release frequent updates to address security deficiencies, and, like any other vulnerability management process, organizations looking to defend against insecure transmission situations should pay attention to these releases and apply the fixes promptly.

Despite the many security vulnerabilities and potential pitfalls in using TLS, it remains an effective mechanism for securing Internet traffic transmissions. That said, it requires proper configuration and use and regular maintenance, just like any other piece of software. It has some unique properties in that advances in knowledge of vulnerabilities and security research can render previously sufficient controls inadequate quickly, but a careful and disciplined security operations practice can usually manage these issues.