I have an ASA 5512X with CX Module (version 188.8.131.52) that we have configured to do some content filtering. It was working fine with content control when we realized that certain blocked sites, like Facebook, were not being blocked. The reason for this is that this, and other sites often either seem to default to https or this can be typed in manually as the address by the user.
After some searching, I discovered the decryption policies, and enabled these so that all https traffic is inspected. This worked fine, until all https traffic (even those that were not blocked by my policies) began timing out about an hour later. It was not being blocked, just timing out. This occured in all sites that had https, like Google.
We decided that the CX module was causing this after a reload of the entire ASA led to it working, until the very second could ping or log into the CX module web GUI.
I called Cisco's support, and after about 90 minutes, we realized that the CX module service "TLS Proxy" was setting itself to "False" randomly and this stopped all https/SSL traffic. We could reload the services, but this stopped all traffic while things were being reloaded, and TLS Proxy just turned itself back off after working initially, some minutes later. After some frustration, we decided to route the https traffic around the CX module by adding a service policy specifically for it and leaving http traffic redirection to the module.
The next morning, TLS Proxy seemingly turned itself back on and then back off again. This seems to ocurr at random, though it is set to "False" much more than "True". We've only see it set itself to "True" once thus far. I am waiting for a call back from Cisco, but in the meantime, has anyone experienced this behavior? This is becoming very frustrating at this point.
There is not a resolution, but there is a work around. Originally we set the decryption policy only to decrypt sites that we wanted to block. For us these are streaming sites, social media, etc.
However, it appears that the CX module attempts to decrypt everything and does not follow the policy as set and this evidently causes some sort of issue with the TLS Proxy service and causes it to be set to false at random intervals. These intervals are more frequent when there is heavier internet traffic at certain times of the day.
The work around is to create a do not decrypt policy at a lower priority than the decrypt policy to serve as a "catch all". This has proven to work successfully for about 3 months.
Cisco did file a bug and marked it "fixed". I don't understand how they can mark it "fixed" by issuing a work around.