- Top 10 Recession-Proof IT Jobs
- 7 Hot IT Jobs That Will Land You a Higher Salary
- Link Building Strategies and Tips for 2014
- Top 10 Accessories for Your iPad Air
Part 1 | Part 2 | Next-gen firewalls require external visibility tools SonicWall stands tall in SSL decryption testing | Test methodology | Palo Alto next-gen firewall stacks up well Check Point takes best approach to URL filtering | Fortinet has highest catch rate in IPS testing Basic firewall functionality: Check Point's maturity shows through | Test archive
Network World - 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.
The story was not nearly as good with the other firewalls. Check Point's Security Gateway has a more elaborate and better thought-out configuration system with more bells and whistles. For example, with the Security Gateway you could exempt all domains in a certain category (such as financial services) from being inspected. The Security Gateway also passed all of our SSL validation checks, detecting revoked and self-signed certificates just fine. However, the Security Gateway can only inspect HTTP traffic on known SSL ports. This means that an application that runs over non-standard ports won't be inspected, and neither will any application that uses a different protocol — such as email, instant messaging, or file transfer.