May 07, 2012, 11:54 AM — If one of the main advantages of a next-generation firewall is application and protocol identification and control, then SSL decryption is a basic requirement. We looked at the SSL decryption capabilities of the next-generation firewalls to see how well they would be able to discover applications, protocols, and URLs hidden within encrypted connections.
When SSL decryption is in place, the firewall performs a "sanctioned man-in-the-middle attack." This means that the firewall intercepts the SSL connection and performs a man-in-the-middle attack to decrypt the contents. Because the attack is done with the permission of the enterprise, it's called "sanctioned.''
This requires that the enterprise have a private certificate authority that is trusted by all users behind the firewall, and that the certificate authority can issue a "signing" certificate. The signing certificate is loaded into the next generation firewall, and for every SSL connection, the firewall generates a new certificate in real-time and uses it to secure the SSL connection between the end-user and the firewall, replacing the original certificate. The firewall then secures the connection using the original certificate. Because the firewall is stacking together two encrypted connections, it can see the traffic, unencrypted.
The only next-generation firewall we tested that did a good job of SSL decryption was SonicWall. With two check boxes, we were able to enable SSL decryption and then apply the next-generation firewall features to the traffic. Four more check boxes enable anti-virus, anti-spyware, intrusion prevention, and content filtering on the SSL traffic. The configuration, including loading our own certificate authority certificate, was simple and fast, and the decryption worked. Additional features we were looking for, such as the ability to exempt traffic from decryption by IP address, user group, or certificate common name (such as "www.bankofamerica.com" or "www.kaiserpermanente.org") were no problem.
We also tested that the SonicWall system could pass through certain errors to clients, such as a self-signed certificate (SonicOS figured that one out) or a certificate that was revoked by the issuer (not detected by SonicOS), and discovered that there is still some work to be done.