It has been a rough year for the SSL protocol.
In actuality, researchers and hackers alike have been poking holes in Secure Sockets Layer (SSL) and its newer cousin, Transport Layer Security (TLS), for some time. But the past 12 months have highlighted serious challenges facing the protocol, from Heartbleed and POODLE to FREAK and now Bar Mitzvah, among many others.
The stark reality for enterprises is that between protocol vulnerabilities, unnecessary features and implementation errors, virtually no business use case involving SSL/TLS can be considered totally secure.
"There have been known issues with older versions of SSL and TLS for quite a while," said Wim Remes, manager of strategic services for EMEA at Boston-based security vendor Rapid7 LLC, noting that advances in computing power and sophisticated attack techniques have taken their toll over the years. "These cryptographic protocols were developed with the knowledge available at that time, and taking into account the computing power available at that time."
TLS 1.3 is expected to be released this year. In the meantime, however, experts say organizations will have little choice but to study SSL/TLS flaws and risks, put additional mitigations in place, and stay vigilant.
Three primary SSL security issues
In essence, Remes said, there are three main issues plagueing SSL/TLS security.
First, some of the algorithms that are still supported have known weaknesses, but can't be easily phased out because many end-user devices do not support newer protocols; second, the scrutiny facing OpenSSL following its recent security flaws has resulted in more vulnerabilities being found at a faster rate than ever before; and third, configuration errors during implementation often leave organizations unknowingly vulnerable.
"Misconfigurations are, in my opinion, the biggest problem," Remes added. "These can only be fixed if the owner of the system has the necessary knowledge to understand the issues and how to fix them without breaking their system for the users."
A common mistake for website owners is to rely on vendor defaults for their websites rather than explicitly configuring security in a way that is appropriate for their sites, said Ivan Ristic, head of vendor Qualys Inc.'s SSL Labs group in Redwood Shores, Calif. Vendor and operating system defaults are traditionally loose, he explained, and might contain features that are deemed insecure.
The three most-publicized vulnerabilities are Heartbleed, POODLE (which stands for Padding Oracle On Downgraded Legacy Encryption) and a series of OpenSSL vulnerabilities, noted Kevin Epstein, vice president of advanced security and governance at Sunnyvale, Calif.-based data security vendor Proofpoint Inc. Epstein noted that those issues reflect "code challenges" as opposed to implementation issues.
"There are many applications with patched, secure SSL that have improperly implemented the code, leading to security issues," Epstein explained.
Epstein noted common website implementation mistakes include a variety of certificate errors, as well as compatibility-related errors.
"Certificate errors often enable untrusted parties to appear to offer secure connections to trusted sites," Epstein said. "Compatibility-spawned errors can enable connecting browsers to negotiate use of insecure forms of encryption, such as TLS 1.0 (subject to the BEAST attack)."
High-value websites, said Ristic, need additional security guarantees.
"Since about 2008, there's been a steady process of innovation and introduction of new features that allow those high-value sites to be better protected," he said. "Some of those new features include HTTP Strict Transport Security, Content Security Policy, Public Key Pinning, and Certificate Transparency."
Deploying HTTP Strict Transport Security in particular ensures that only encrypted content can be sent from a particular website and also addresses certificate warnings, Ristic noted, removing the ability to click through a warning and fall prey to a man-in-the-middle attack.
Waiting for TLS 1.3: SSL security best practices
When TLS 1.3 becomes a reality, Remes argued that the biggest challenge will be the adoption rate.
"While we can expect Web servers to start supporting TLS 1.3 fairly quickly, browsers will not follow as fast," he said. "We see many mobile users running outdated versions of Android with the pre-configured browser that no longer gets updated by the handset's vendor, for example. That's a significant portion of the mobile user base."
Remes said that full adoption of TLS 1.3 can only be expected when both servers and clients all support it.
"I believe that organizations should make TLS 1.3 a priority on their road map," Remes added, "and monitor closely as their user base closes the gap so older versions can be disabled as soon as possible."
In the meantime, he advised organizations to review their TLS configurations and installations.
"Make sure that only safe algorithms are supported and that everything is configured as it should be," Remes said. "The Heartbleed vulnerability, as an example, was found in a heartbeat extension that very few SSL/TLS implementations actually needed. It was (and is) possible to disable this extension upon installation.
"As with any software, only the functionality that is needed should be installed," Remes added. "This reduces the attack surface and ensures that you do not need to support and manage functionality that is not necessary for your infrastructure."
Learn how one vendor is offering a free public SSL tester to test any website or server for SSL vulnerabilities.