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. In the ASA CX, SSL Decryption is handled by a separate set of policy rules, essentially defining which traffic is decrypted and which is not. From a management point of view, configuration and control of the SSL Decryption part of the ASA CX is outstanding. We started by installing our own certification authority, which is trusted by all systems in our lab, into the ASA CX, a simple matter. Then, we enabled decryption for all traffic and let er rip.
At first glance, the ASA CX worked great, catching SSL on non-standard ports, and extending application identification even into encrypted sessions. And for the most part, the ASA CX SSL decryption is just fine and didn't create any performance problems in our limited lab testing. But it's not perfect.
The biggest issue we ran into was application identification of encrypted traffic. Although the ASA CX does a good job of decrypting and re-encrypting SSL traffic, the application identification engine doesn't work properly for many protocols. It's not a complete failure — the most important protocol that most people care about, HTTP, is successfully unpacked and identified. But security managers who want to identify and control non-HTTP other protocols which might be blocked by policy can't see into the encrypted session. For example, the ASA CX was great at identifying unencrypted IMAP on standard and non-standard ports. But if we opened up a connection to an IMAP server on the standard IMAP-over-SSL port, the ASA CX didn't identify the traffic as IMAP, but just as SSL. We had the same issue with SMTP using standard ports. Once the traffic was encrypted, the ASA CX didn't identify these protocols. For HTTP traffic, there wasn't a problem — the ASA CX unpacked encrypted HTTP just fine and identified applications, such as Google Mail and Facebook inside of the encrypted session.
Early on, we also had smaller issues with some SSL negotiation that the ASA CX didn't like, and hence inappropriately blocked. This first showed up in our lab's iPhone and iPad, which started behaving poorly and couldn't communicate back to the iCloud mother ship. The problem was easy to see in the ASA CX logs, but there was no simple solution other than to exempt certain IP addresses at iCloud from SSL decryption. Problem solved, but maintenance and documentation headache begun. And we didn't know how that would affect other controls. For example, we tried blocking iTunes installation of applications, which didn't work. Was that because the SSL wasn't being properly decrypted, or was it just a bug in the iTunes blocking?
Sign up for CIO Asia eNewsletters.