7 common misunderstandings about SSL encryption

By Duncan Hughes, Systems Engineering Director, EMEA, A10 Networks.

The amount of Internet traffic secured via SSL encryption is surging to new heights every day – it's estimated that nearly 70 percent of all web traffic uses SSL encryption and 86 percent of that uses advanced encryption methods like Elliptical Curve Cryptography (ECC) and Perfect Forward Secrecy (PFS).

Despite the potential blind spot introduced by encrypted traffic, which makes it harder to detect malware and other cyber threats, some companies elect to go without the ability to inspect this encrypted SSL traffic at all. Why? Because there are a host of misperceptions regarding SSL-encrypted traffic.

Here, we separate fact from fiction and share seven common SSL misperceptions and the reality.

SSL is complicated, slow, requires many resources to inspect and introduces new risks for networks. Actually, these days, it's possible for SSL processors to reach speeds as fast as 44,000 SSL connections per second (CPS) for 128B file sizes. And by using application delivery and server load balancing technology, you can offload the compute-intensive SSL/TLS processing from web servers for faster processing of SSL traffic.

We don't expect any increases in overall SSL traffic. Some customers claim that as they're transitioning to using traffic-heavy applications such as Office 365, their SSL traffic nearly doubled. Introducing new business tools requires a better understanding of new demands on your network – and an even greater need to inspect the traffic that's coming into your network.

I already know what's happening with our network traffic. In reality, many IT professionals don't realise how much encrypted traffic is on their network until they actually install SSL/TLS encryption solutions – especially those that support protocols other than HTTPS and can detect SSL/TLS on non-standard ports. SSL/TLS encryption in high-throughput, high-connection-rate scenarios can give enterprises assurance with their email platforms that can effectively become a "ransomware killer."

I already have an encryption solution, so don't need a dedicated appliance. While it's true that many all-in-one solutions can process encrypted traffic, there is often an SSL performance tax associated. Can you sacrifice security for performance, or vice versa? Having a dedicated appliance for SSL encryption takes the processing demands off your other appliances, meaning you don't suffer the SSL performance hit.

Security solutions introduce unexpected expenses. What if I discover that I need additional IPS, NGFW or web proxy to inspect all the clear text traffic? Will I have to buy another A10 appliance to support this "newly" introduced capability? After the initial A10 capital expenses, customers don't have to pay for additional features such as server load balancing, as this is part of A10's no-license model. We have had several customers identify the need for additional security platforms to inspect all the clear-text SSL/TLS traffic.

I have to rip and replace if I want to install A10. Actually, we seamlessly integrate with the existing network, whether it is in L2 or L3 mode, complementing different security products you may already have installed. With A10 providing the decryption services, existing security devices like NGFWs need not to worry about decryption and can scale their inspection capabilities, which wouldn't have been possible otherwise.

Encrypted data is secure data and performing a "break and inspect" puts your keys at risk. In order to perform decryption, you're trusting an additional key, but how do you know that key is adequately protected? A10 offers customers the choice to have an onboard FIPS 140-2 level 3 validated Hardware Security Module (HSM) to protect the keys without compromising performance. A10 also allows for integration with a Thales nShield Network HSM that might already exist in the network. The HSM integration is intended to detect and protect against attempts at physical access, use or modification of the cryptographic module.

Those are just a few of the common misconceptions about SSL encryption.