3 reasons SSL encryption gives a false sense of security

In early 2015, enterprise security teams were still absorbing the lessons of the previous year’s SSL flaws. Heartbleed and POODLE had shown that the encryption protecting e-mail, e-commerce, online banking, voice-over-IP and remote health services could itself be a point of weakness. Ananda Rajagopal, then vice president of product management at Gigamon, argued that organisations had come to treat SSL as a guarantee when it was not one.

His case rested on three points: attackers could abuse SSL itself, many monitoring tools could not see inside encrypted sessions, and the tools that could decrypt traffic often slowed down badly when they did.

The context: SSL under pressure in 2014

SSL was the protocol that major browsers and websites used to encrypt sensitive data, such as card numbers, in transit. In 2014 two flaws dented that reputation.

Heartbleed was a bug in the OpenSSL implementation that leaked private keys and user data. Rajagopal described how it let an attacker coax a server into handing over sensitive information, including the private keys behind its encryption. With those keys, he said, an attacker could read protected communications or impersonate the server without leaving a trace.

POODLE was found by Google’s security team in October 2014. It exploited how SSL 3.0 handled padding in cipher block chaining mode, and it let an attacker who forced a browser to fall back from TLS to SSL 3.0 recover protected data such as secure cookies.

Reason one: attackers hide inside encryption

Rajagopal said encryption worked for attackers as well as defenders. Encrypted channels could be used to leak confidential files, and malware such as the Zeus botnet had been hidden in SSL sessions once thought safe. In his words, criminals were increasingly using SSL sessions to get past network defences.

He backed this with two figures. An NSS Labs study estimated that 25% to 35% of enterprise traffic was SSL-encrypted and rising, and higher in some industries. He also cited a Gartner forecast that by 2017 more than half of network attacks on enterprises would use encrypted traffic to bypass controls, up from under 5% in 2015.

Reason two: tools that cannot see inside

The second problem was visibility. Inline devices such as application delivery controllers and firewalls could inspect SSL, Rajagopal noted. Out-of-band security and performance monitoring tools often could not reach encrypted content, so they could not analyse usage patterns, threats or application performance. Unmonitored encrypted traffic therefore became a route for malware to work unseen.

Reason three: decryption slows everything down

Where tools did decrypt, the cost was high. Rajagopal pointed out that administrators were moving to larger cipher keys, and he cited an NSS Labs finding of an 81% performance degradation in existing SSL architectures.

Inline tools such as SSL proxies and application load balancers, he said, struggled to handle traffic from many network TAPs and to copy decrypted traffic to several monitoring tools. They also lacked traffic intelligence for unencrypted traffic.

Gigamon’s proposed answer

Rajagopal’s remedy was to decrypt once, in dedicated hardware, and share the result. Gigamon offered this through its Visibility Fabric platform. Its GigaSMART traffic-intelligence engine decrypted SSL and passed the traffic to analysis tools, and extra modules could be added to a node or cluster as decryption demand grew.

Gigamon said this removed the need for separate decryption licences on each tool. To limit exposure of sensitive data, decrypted traffic could be sliced to drop irrelevant or private payload, and fields could be masked. Private keys were protected with a password separate from the general administrator password.

How the protocol changed afterwards

The weaknesses Rajagopal pointed to were not the end of SSL as a name, but they were the end of SSL as a protocol. SSL 3.0, the version POODLE targeted, was formally deprecated in 2015 by RFC 7568. A variant of POODLE that affected TLS was announced in December 2014, which showed the problem was not limited to the oldest protocol.

TLS 1.3 was defined in August 2018, and RFC 8996 deprecated TLS 1.0 and 1.1 in 2021. TLS 1.3 removed older weak ciphers and key exchange methods and requires forward secrecy, which prevents a stolen long-term key from exposing past sessions. Security vendors now describe most named SSL/TLS attacks, including POODLE, as depending on servers that still support outdated protocols or weak cipher suites.

The visibility problem Rajagopal described is a separate matter from the protocol flaws. It comes from the volume of encrypted traffic and the limits of the tools watching it, not from a bug in any one version. Whether the Gartner forecast for 2017 came true is not something the available sources confirm.