I am toying with https inspection. I am wondering now with the WCCP redirect from the firewall for https on two of our test IP's (before rolling it in production), if I need to basically duplicate all of my Access Policies on the Decrypt Policies. Is Access Policies just for http websites and Decrypt Policies just for https websites, or am I wrong?
Lets say you want facebook blocked. In Access Policies it is blocked by default, unless you fall into an upper category like AD group Management for example. Well facebook has both an http and an https (now increasingly more common) site. So could they just circumvent this block by typing in https? They can do that now (since were not inspecting https), but we want to put a stop to that.
I tested and put drop for social networking but we just get a page cannot be displayed then on our test machine. We don't even get redirected to our server hosting the "you are blocked" page.
You want to monitor Social Networking in HTTPS and block it in the Access policy.
The HTTPS proxy settings just deal with whether or not to decrypt the data. Access policies still do the actual access limitations.
Ok so its fine to have a global decription policy that has everything set to monitor, and just continue to let the access policy do all the work?
At least if you "hit" on an access policy, the WLC forwards us to our customized block page. In decryption policy if you hit drop, quite understandably so you just get a page cannot be displayed (since it is dropped of course).
When would the "decrypt" option be a good idea?
I set decrypt on stuff that's marginal... We don't block it, but has a better chance of having malware, etc.
Here's a partial list of what we decrypt