|
|
|
|
|
SSL Security Epic Fail: When Your SSL Decryption Solution Prevents Better Security
Published Dec 6, 2015
|
SSL is everywhere. Today, many of the most popular websites leverage encryption to keep data secure and private. On top of that, other applications such as email, instant messaging, and FTP use SSL or its successor TLS to encrypt traffic. Need proof that SSL is ubiquitous? According to Sandvine, two thirds of Internet traffic will be encrypted by 2016.
When organizations start encrypting application traffic, they often encounter obstacles such as performance degradation on their application servers. Encryption has other, more serious, ramifications; it makes network security tools blind to application traffic. Security solutions like next-generation firewalls, intrusion prevention, and advanced threat protection platforms cannot inspect packets and mitigate threats when traffic is encrypted.
To solve this issue, organizations can deploy SSL inspection platforms to decrypt SSL traffic and forward it to third-party security devices for analysis. For outbound traffic, organizations own the end points but not the SSL certificates and keys. An SSL inspection platform can decrypt traffic when configured as a transparent forward proxy or an explicit proxy.
Protecting Corporate Servers
Decrypting inbound traffic destined to internal application servers is different than decrypting outbound traffic because organizations own the SSL keys. There are two main ways to decrypt inbound SSL traffic sent to internal servers:
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, organizations cannot easily block attacks. Although organizations 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.
However, the biggest flaw with passive mode is that it does not support strong encryption methods like Perfect Forward Secrecy because the SSL inspection platform does not actively participate in the SSL key negotiation.
Why should you care about Perfect Forward Secrecy (PFS)? Many organizations are transitioning to PFS because:
PFS ensures that if an SSL key is compromised in the future, that criminals or government organizations 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 organizations are heeding their call. Web properties such as Dropbox, Facebook, Google, LinkedIn, Microsoft Outlook.com, Twitter, Tumblr, Yahoo and more now use PFS.
Unfortunately, organizations that deploy an SSL inspection platform that only supports 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 a security epic fail.
Posted by
VMD - [Virtual Marketing Department]
|
|
|
