​Epic Internet failure looms in SSL blind spots

Two-thirds of Internet traffic will be encrypted by 2016, according to a survey by intelligent network policy control solutions vendor Sandvine¹. Popular websites, as well as email, instant messaging, and FTP leverage encryption to keep data secure and private. But when organisations start encrypting application traffic, they often encounter obstacles such as performance degradation on their application servers.

Encryption has more serious ramifications - it makes network security tools blind to application traffic. Security solutions that include next-generation firewalls, intrusion prevention, and advanced threat protection platforms are unable to inspect packets and mitigate threats when traffic is encrypted.

To resolve this issue, organisations can deploy SSL inspection platforms to decrypt SSL traffic and forward it to third-party security devices for analysis. For outbound traffic, organisations own the end points, but not the SSL certificates and keys. Because they own the end points, they can configure the end points to trust the SSL inspection platform. This allows the SSL inspection platform to decrypt outbound traffic transparently.

Protecting corporate servers
Decrypting inbound traffic destined to internal application servers differs from decrypting outbound traffic because organisations own the SSL keys. Two main ways to decrypt inbound SSL traffic sent to internal servers are

• Reverse proxy mode: SSL traffic is terminated on the SSL inspection devices and sent in clear text to inline or non-inline security devices. This mode is also referred to as “SSL offload.”
• Passive non-inline or inline mode: SSL traffic is decrypted using a copy of the server SSL keys. SSL traffic is not modified by the SSL inspection platform except—potentially—to block attacks.

In reverse proxy mode, the SSL inspection platform can potentially also accelerate SSL performance and load balance servers.

In passive non-inline mode, the SSL inspection platform can be installed transparently without needing to update network settings. However, in passive non-inline mode, organisations cannot easily block attacks. Although organisations may be able to send TCP resets from non-inline devices, this is a best-effort approach and will not effectively block all attacks, including single-packet attacks.

The biggest flaw with passive mode is its lack of support for strong encryption methods like Perfect Forward Secrecy (PFS) because the SSL inspection platform does not participate actively in the SSL key negotiation.

Many organisations are transitioning to PFS for the following reasons:

• PFS ensures that if an SSL key is compromised in the future, criminals or government organisations cannot decrypt the data. Each session has its own unique key, so each individual session must be cracked—which is a nearly impossible task.
• PFS mitigates many types of SSL vulnerabilities. For example, with the notorious Heartbleed bug, if an SSL private key is compromised, hackers cannot monitor and decrypt communications. This is because each SSL session is encrypted with a unique session key.

Leading SSL proponents like the Electronic Frontier Foundation (EFF) are urging application owners to switch to Perfect Forward Secrecy. And many organisations are heeding their call. Web properties including Dropbox, Facebook, Google, LinkedIn, Microsoft Outlook.com, Twitter, Tumblr, Yahoo and more now use PFS.

Unfortunately, organisations that deploy an SSL inspection platform that supports only passive mode will be hamstrung—unable to implement strong security ciphers like Elliptic Curve Diffie Hellman Exchange (ECDHE) without breaking their SSL decryption architecture. SSL inspection platforms deployed in passive non-inline mode are an epic security fail.

Key features to consider when evaluating an SSL inspection platform include:

• Eliminate unwelcome production surprises by ensuring that an SSL inspection platform can handle future throughput requirements.
• Safeguard the company from malware, Trojans and data breaches by intelligently routing traffic, supporting transparent deployment, and integrating with a variety of security solutions.
• Minimise risk and maximise uptime, performance and overall capacity of security devices with automatic downtime detection and load balancing.

An advanced application delivery controller (ADC) will tick all these boxes, ensuring that organisations choosing the appropriate device will be able to plug SSL decryption blind spots and eliminate nightmares of epic failure.

¹ Sandvine Global Internet Phenomena Spotlight, 2015