topic Re: SSL decryption using incorrect security policy in General Topics

SSL decryption using incorrect security policy

ClintL — Tue, 31 Mar 2015 18:21:18 GMT

Hello all,

I am testing out SSL decryption on a few categories. For now I am using a system generated certificate and it works in decrypting the categories I have selected. The problem is that once it is decrypted, it doesn't use the proper security policy. We have AD integration and URL filtering set up between certain groups. My user ID has elevated browsing privileges but after the session is decrypted it uses the policy I have set up when the firewall doesn't know who the user is so I am getting blocked. Any idea why it wouldn't use the correct security policy when the log view and blocked page are showing my user ID?

Re: SSL decryption using incorrect security policy

reaper — Thu, 02 Apr 2015 12:28:46 GMT

Hi Clint

Can you also include a screenshot of the security policy?

The security policies are processed top to bottom with the first match (not "best" match) being the rule that is used to pass traffic, so if your top rule does not have a source user restriction this would be normal.

have you set that rule to use source user "unknown" or "any" ?

regards

Tom

Re: SSL decryption using incorrect security policy

ClintL — Thu, 02 Apr 2015 13:06:39 GMT

Here you go. The rules work fine with no decryption but when it is turned on for some reason it jumps over "Netit".

Re: SSL decryption using incorrect security policy

rfrazier — Thu, 02 Apr 2015 15:27:11 GMT

My guess is that the app is now "web-browsing" due to decryption, but the port is still 443. You're using application-default as the service for the first rule (and I'm assuming "web-browsing" is included in that filter) so that would only match if web was on 80, but I'm guessing that you have port 443 included in the "service-web" service group on the other rule, and "web-browsing" included in "web-services".

Re: SSL decryption using incorrect security policy

ClintL — Thu, 02 Apr 2015 15:28:49 GMT

I think you may be correct, sir. I'll give it a try here shortly and let you know.

Edit: That was it. Thanks!