ASA CX content filtering, looking for suggestions

[oguevara08]

I wanted to get some feedback on how the rest of you security folks are doing web content filtering.

The CX does a great job with HTTP but when it comes to HTTPS it leaves a lot to be desire. When the CX first went live, it was configured to decrypt all HTTPS traffic and Deny transactions to servers "Using an untrusted certificate" and "If the secure session handshake fails" turned on.

Immediately I started to implement the "Do not decrypt" policy and it worked great for most websites experiencing HTTPS decryption issues. Other websites required that HTTPS certificate be imported to the CX for it to work.

However, due to the constant "error:140920E3:SSL routines:SSL3_GET_SERVER_HELLO:parse tlsext" I experimented with different work a rounds till I found these articles.

http://www.exploresecurity.com/the-small-print-for-openssl-legacy_renegotiation/

https://www.digicert.com/news/2011-06-03-ssl-renego.htm

TAC's suggestion was to create a deny statement (using an object group that defines the FQDN) at the top of the ACL that send the traffic from the ASA to the CX. This was the only way to keep the CX deny "Using an untrusted certificate" and "If the secure session handshake fails" decryption settings turned on.

Now I feel I am back at square one as the number of exceptions have grown exponentially. This has led me to believe that I need to revisit the way that content filtering is being implemented. My goal is to apply a simple yet scalable solution. As I see it, I can continue to add to the "ASA to CX" exemption list, this is not a scalable solution as it requires all FQDN to be defined (ex. bank.com, server1.bank.com, server2.bank.com, etc). The alternative is to relax the CX decryption configurations which I feel is the equivalent of removing a car's airbags for weight reduction to make it faster.

Any input would be appreciated!

[Marvin Rhoads · Accepted solution]

I've come to the conclusion that SSL decryption is only possible where a robust PKI has been deployed in an enterprise. Even then we would ideally use a dedicated SSL decryption appliance so we can hand the CX (or ASA with FirePOWER service module) plain old http for inspection.

The software modules just don't have the processing power to be able to do line rate decryption for any but the most modest throughput rates.

Also, the CX is being deprecated going forward in favor of the FirePOWER modules so you won't see any significant new feature addressing this shortcoming on the CX.

[oguevara08]

First let me say thanks Marvin, your post have always been very helpful.

I was afraid this was the direction Cisco was heading after hearing about the FirePOWER announcement. It makes me sad that I did not know of this move before my organization pulled the trigger on the CX/PRSM.

Can you point me in the right direction for some reading material on the SSL appliance?

[Marvin Rhoads]

You're welcome.

The rebranded Sourcefire SSL appliance family are now the "Cisco SSL appliance" series. It comes in three models with 1.5 to 3.5 Gbps of inline decryption performance whose capabilities are outlined here:

http://www.cisco.com/c/en/us/products/security/ssl-appliances/models-comparison.html

FYI to give you an idea the list prices range from about US$55k-85k (not including Smartnet cost). SSL decryption isn't cheap.