Demystifying SSL Decryption

Websites have been around since the early 90s, relying on the HTTP protocol. With HTTP, all of the communication between the client and web server is not encrypted. If an attacker could position themself somewhere within the communication path, they would be able to see all of the data being transferred in clear text. You can think about it like a CB radio. Anyone who wants to tune into a specific channel, can eavesdrop on others chatting, as long as they're in range. They could also speak up and pretend to be someone they are not.

Luckily there was a better way. Netscape invented HTTPS in 1994, which leverages encryption, so that if an attacker was in between yourself and the web server, all of the information would still be encrypted. Secure web browsing has transformed the Internet allowing for online banking, shopping and everything in between to occur with great safety. The problem with encrypted traffic, is that security devices including firewalls, had no way to inspect this traffic. An attacker could easily leverage this limitation, to drop in a virus, communicate with a command and control server on the Internet or worse yet, copy sensitive data from an environment offsite. So how do we address this?

Enter SSL Decryption

So how do we break SSL? By design, it's not that easy. SSL leverages one-way math, so the encryption cannot be broken without significant brute-force attempts of reversing complex equations. Instead of 'cracking' the encryption, SSL decryption basically performs a man-in-the-middle type attack. 

When a client connects to a website, normally there would only be a single session that passes through the firewall. With SSL decryption, 2 sessions will ultimately get created. 

• One between the client and firewall, pretending (Spoofing if you will) to be the website. 
• Then a second, from the firewall to the actual website, spawned on behalf of the user.

Now spoofing an HTTPS website normally will not work, because there's a certificate installed which vouches that a website is who they say they are. Most browsers will display a lock next to the URL showing that the website is using HTTPS with a valid certificate. The browser inherently trusts this certificate and otherwise would provide a warning if the client was presented with a certificate it did not trust. So how does the firewall accomplish this amazing feat?

It requires that a root or intermediate certificate be installed, so that the firewall can generate and sign trusted certificates on-the-fly. The same root or intermediate certificate in-turn needs to be trusted on all of the devices that will pass through the firewall with SSL decryption.

Bringing It All Together

This sounds rather complex at first, but once all of the pieces are setup correctly, it's rather seamless. A client attempts to connect a secure website via HTTPS. The firewall pretends to be the website, thus creating a trusted certificate on-the-fly. The firewall has a copy of the traffic that is no longer encrypted to inspect it and verify there's nothing malicious contained within it. The firewall spawns a new connection on behalf of the user, to the real destination website, then bridges these 2 sessions. The end result is verified, safe, beautiful HTTPS connectivity.