Best way to block HTTPS categories in WSA

[dkorell]

I am implementing HTTPS decryption and ready to move past the pass-through everything phase (taking baby steps to implement) and start decrypting and blocking. For blocking a category (like Adult), I was going to drop it in the decryption policy even though it's also blocked in the access policy. I figure why let it continue on to the access policy just to be blocked there. But I found this in Cisco documentation:

"If you want to block a particular URL category for HTTPS requests, choose to decrypt that URL category in the Decryption Policy group and then choose to block the same URL category in the Access Policy group."

Can anyone explain why I wouldn't just drop it to begin with? As far as I can tell I still get a block page between the two with the only difference being the Reason field stating "Unknown" when dropped and "Block-WebCat" when it goes to the access policy.

[Ken Stieers]

I don't know about your users, but I would get calls about that.  If its misclassified, you have a chance of figuring out that the issue is misclassification, not some other weirdness.

In my opinion, its clearer to think of the decryption policy as JUST decryption, and then use the access policy for access.  I think there are some technical reasons in the guts of the WSA for doing it this way too, but I don't remember what they are...

[dkorell]

And then I find this in another Cisco page. No consistency apparently. Thanks for your input and I do think that only letting the decryption policy pass-through or decrypt is a valid idea.

"If you must drop an HTTPS request, drop it in the Decryption policies, not in the Access policies. Otherwise, it consumes more CPU and memory for a dropped transaction first to be decrypted and then to be dropped."

http://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/118885-technote-wsa-00.html

[Paul Cardelli]

Yes, next to the Drop there is a ? bubble and when you click on it:

No end-user notification will be provided for dropped HTTPS connections. Use this setting with caution.

I took this as, don't use this option unless you have a special case as the end user will not get any block message, the page will simply look broken. I spent a good week cleaning up a lot of decryption rules that had drops. Instead I set them to decrypt, and had them blocked in my access rules if appropriate. This cut down on the number of individual decryption rules. I now just create such rules for special cases and custom categories.

[Handy Putra]

If you have decryption policy set to drop, from user perspective the browser will give its own browser block page such as "page can not be display" instead of block page coming from WSA. If you set to decrypt first then set to block in the access policy, the user will then get the block page from the WSA. However this is an old behaviour, in current AsyncOS version (start from 7.7 if i'm not mistaken), the appliance has option to decrypt first from HTTPS proxy page before going to decryption policy. The option for this in Security Services -> Https Proxy -> Decrypt for End-User Notification/Decrypt for End-User Acknowledgement, the option for that is to either decrypt or disable. If its set to disable then the above behaviour apply. If it is set to decrypt then in decryption policy you can simply set to drop action and the user still get block page from WSA. However in the reality (not seen from users) the actual traffic is still being decrypt first then block because in order for WSA to send its block page the encrypted traffic will require to be decrypted first. Doing so, does need extra resources for the WSA to do this and if you have massive requests per second and the appliance will require to do this very often, may impact performance else set the Decrypt for End-User Notification/Decrypt for End-User Acknowledgement option in HTTPS proxy page to disable and set drop in decryption policy so the request will simply drop (not block) from WSA however the users will get browser block page instead of WSA block notification. Hope this clear things up

[dkorell]

Thanks for the response. That was very informative. I already had Decrypt for End-User Notification enabled so for testing purposes I disabled it and tried going to a blocked site as configured in the decryption policy and I got a page that basically said it wasn't available. I then changed to decrypt and allowed the access policy to do its thing and I then got a block page.

Although I see a benefit in dropping categories in the decryption policy I have about 10 different access policies with varying permissions. If I set categories that vary between the policies to decrypt then I basically just need one decryption policy. If I try to match my access policies then I'm going to end up with an equal number of decryption policies.

[Handy Putra]

Thats correct, however if you decrypt all the HTTPS traffic, depends on the number of your requests going to the appliance since it might impact the performance due to decryption is quite expensive.

Also some HTTPS sites might not like the traffic being decrypted therefore  some HTTPS sites might have issues or not even loads up or getting browser block even though it is been decrypted and allow from access policy

[Prab]

Hi all,

It is better to drop the request in the Decryption Policy itself, in case you are dropping/blocking it later in Access Policy too. Decryption policy comes before Access policy.

Why waste CPU cycles?

For eg: If you plan to block Alcohol category then just use the action "Drop" in the decryption policy. In this case the WSA will asap drop the request going to alcoholic websites and does not require any further access policy checks.

However you need to take care of the EUN (End User Notifications) in case you want to show a https block page to the user when he/she tried to access a website that is https and is blocked in decryption policy.

Below is the notification page when the "Astrology" category was set to "block" action in the Decryption policy itself.

Below is the notification page when the "Astrology" category was set to "decrypt" action in the Decryption policy and later the action set to "block" in the Access policy.

Hope it helps.

Thanks & regards,

Prab :)