commit status warning on rules that are working the way I want them too

[jdprovine]

I have a rule that has webex enabled but dones not have ssl enabled and i keep getting a warning on that rule when i commit that says "Applicaiton 'webex-desktop-sharing requires ssl be allowed? But I don't want to allow ssl, so how can I get rid of these warnings so i can tell when i have a legitimate commit warning?

[jdprovine]

@hshawn

Interesting information , we know what we do and don't want to allow and we have decided to not allow ssl, so you would think if you didn't allow a dependencies it should not work but.... when I look in the logs it works just fine and even though I havent allowed ssl or web -browsing I can see it using port 80 and port 443. My first thought is that either the application isn't defined enough or my rule is not.  I could fix it by adding the dependency to the rule or in this case ssl, but I don't want it allowed.

I have a specified source and destination zone, specific source IP, it confined to only two specific regions,  specific application s(set to application default)

[jdprovine]

Okay i am still tracking this for a solution and I got this today in the commit status but i clearing see google-play traffic in the traffic logs. 

commit status

• Application 'google-play' requires 'google-base' be allowed and i can clearly see spotified traffic in the traffic logs

And I also have this in the commit status

• Application 'spotify' requires 'ssl' be allowed

[gwesson]

Sometimes App-ID can determine that the app is google-play without using the application dependencies, so you're able to see the app. An example is one where the client is sending the Client Hello with "play.google.com" in the server_name extension, so it's easy to tell.

But other times the user would have already been logged into google, and the check is against "accounts.google.com". Unless you're doing SSL decryption, you can't see the actual encrypted request to the play store. If you can't see that it's google play and you haven't allowed SSL anywhere in your security policy, there will be situations where a user is denied going to google play but other times it works fine.

The commit warning could probably be "application 'google-play' requires 'google-base' to be allowed for reliable detection of 'google-play'", but that may just be too wordy and may even generate more questions about what specific scenarios will cause it to be matched versus not. It's much simpler to state the dependency as a requirement, even if there are conditions that will sometimes allow for detection. 

[BPry]

It's sometimes hard to actually lay out the application dependency simply due to the fact that some users utilize SSL-Decryption and others don't. There are quite a few apps that the dependency isn't as necissary when running SSL-Decryption, but it needs to be there for people who are not utilizing that feature. 

[jdprovine]

@gwesson

So in other words it can be hit or miss, that doesn't sound good.  But my biggest issue is that i want to clean up the commit status message and I was thinking if I am not allowing it, via dependencies, it just shouldn't work

[jdprovine]

@BPry

I am not doing ssl decryption at all on my firewall. I was just trying to follow the best practices rules that says to clean up your commit status errors so that you can get better error information, but so far it appears the only way to clean up the commit status message is to add the dependencies to the rule,which I don't want to allow and the fact that if it is a true dependency its seems like a bug that it actually allows it on a hit or miss basis

[BPry]

@jdprovine,

If you allow it further up in your configuration I wouldn't be terribly worried about it. The traffic will transition from the rule allow SSL to the more specific app-id policy without issue. As of yet, I don't think there is a way to actually fully dismiss these warnings. 

[jdprovine]

@BPry

"If you allow it further up in your configuration" allow what?

From what I can see its the rule I don't have google-base allowed but do have google-play allowed, that google-play is working on even though it give a google-base dependency warning. To me if it is dependent on something, it shouldn't work without it and it if does there is something wrong

[BPry]

@jdprovine,

If you aren't running SSL decryption you are likely have a rule somewhere in your policy that is allowing "SSL" on 443.

It can be difficult on a firewall to properly identify google-base traffic, and it's likely getting labeled as 'SSL'. Once the traffic can properly be identified as google-play the traffic will start hitting the rule that allows this traffic. 

[jdprovine]

@BPry

thats the thing we specifically left ssl off that rule cause we didn't want it to be used on it

[BPry]

@jdprovine,

So you don't have SSL allowed in your rulebase anywhere else? 

[jdprovine]

@BPry

Yes we have it allowed in other rules but not in the specific rule with google-play because we do not want ssl to be used for the pc's on that rule going to the internet

I have set up a specific pc allowed to only the US internet with google-play allowed

[BPry]

@jdprovine,

See that's how this rule is allowing access.

google-play has an application dependency of google-base, which you aren't allowing. Thing is, google-base is getting allowed because the firewall is classifying the traffic as SSL, which you are allowing. Once the firewall has enough imformation to properly identify the traffic it's getting matched to google-play. 

If you were to look through your traffic logs and gather a sample of destination addresses that are currently matching 'google-play' and simply queary the log specific to those addresses you'll likely see the traffic switching between SSL and google-play. 

[Remo]

It really depends on the actual use case. When you have a general webaccess rule that allows users to browse the internet, then it's not a big deal.

If you don't allow internet access but you want to allow webex for example, then it is quite a difference if you also allow ssl or not.

The "issue" is that the description might let others think they really NEED to allow the dependencies to make the rule work while it is not needed. It's just not only a binary decition we have here. But for everyone who knows what they are doing, these commit warnings are annoying.

But at least the initial question if there is a way to ignore/hide/whatever these warnings is answered - there isn't a way.

[jdprovine]

@Remo

Long term it could be more of annoyance it could obscure new error messages, as noted in the best practices. Its not really a general use internet access rule it is very specific.  We want one pc access to google-play and only google play in the US. If something is truly a dependency it should not work without it and if it does what does that say about your rule