CAIRO, Egypt, 6th December, 2015: Secure Sockets Layer (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, .
Glen Ogden, Regional Sales Director, Middle East at A10 Networks says that 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 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.
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:
· 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 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 .
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:
· Each session has its own unique key, so each individual session must be cracked—which is a nearly impossible task.
· 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 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 in Egypt 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.