SSL decryption and AppID

[Anon1]

Today we use "ssl" AppID in firewall rules. In case we would enable SSL decryption, is it needed to add the AppIDs of the decrypted traffic to the firewall rules, e.g. web-browsing, java, flash, or is the AppID staying "ssl" even when traffic is decrypted?

[cpainchaud]

with decryption, SSL will become another application so you will have to update the rule.

[Anon1]

This behavior makes no sense to me. In this case the rule would then e.g. have ssl+web-browsing, and I cannot use "service = application-default" because it would then allow also port 80, which I don´t want. It would also allow unencrypted traffic to the target server which I don´t want either.

[cramman]

i'm not sure i understand your rationale.

if you enable web-browsing and "application-default" then plaintext html based traffic will be allowed on port 80 and 8080.

if you don't want unencrypted traffic to the target server, don't allow it.

[Lucky]

Hi Anon1,

let me try to explain it from the other angle 🙂

Once your traffic is decrypted, such sessions will not have application ssl but will be whatever they are; for example:

- if your user was browsing https encrypted page, and it is decrypted, it becomes web-browsing,

- if your user was listening to youtube music, after decryption, instead of ssl such stream will be youtube app,

- if your user was browsing facebook and their session is decrypted, app will be facebook-base,

- if you were accessing Nagios over the https it will become app nagios after decryption....

Please take all examples of final application above with a grain of salt, I just typed it out of my head and was guessing application names. I am trying to illustrate that previously encrypted session contents were tagged as ssl application, but now they are becoming plain-text (after decryption) and firewall will evaluate applications for whatever they are.

Implicitly, previous security and other policies for ssl traffic now have to include whatever apps those become after decryption (if you want to hit the same rule, right?)

Bottom line is, ff it is decrypted, it will not be ssl anymore and it will be different app, so you will have to adjust your security policies to reflect such change in traffic visibility. Does it make sense with this explanation, a bit more? I just re-explained what cpainchaud wrote. In such case, you need to enable decryption and use application that you expect it to become.

Now, I will not remove top part of the text but I have re-read your question, and from your second post it seems that you are trying actually to have inbound decryption for the server that is hosted on your side? If that is the case, it will be a bit more complex: you need to allow ssl from Untrust to Untrust and to that specific public IP address in one policy, and in another you need to allow application from Untrust towards the DMZ and local IP with the app you expect (web-browsing?). You don't need to use "any" app anywhere, but you need two rules: one for incoming encrypted flow (allow ssl) hitting public IP on the firewall, and another rule for specific application (allow web-browsing? citrix? whatever) towards the private IP in the DMZ (whatever inside zone you have).

Let me know if I completely misunderstood everything 🙂

Regards

Luciano

[BenjAudy.MTL]

Hi Lucky,

Does that mean the rule for the decrypted traffic should not use "application-default", since the decrypted traffic is still on port 443 and not the default port 80 for web-browsing? Or is the firewall smart enough to refer to the original encrypted traffic when we refer to that service?

Thanks,

Benjamin

[Lucky]

Hi Benjamin,

I am not completely sure now what direction are we talking about 🙂 In any case, I would try with application-default service and if that does not work I would change service to any or try to investigate a bit more why does that exactly happen.

Copied from help of the firewall (I open that question mark so often to check things):

application-default—The selected applications are allowed or denied only on their default ports defined by Palo Alto Networks. This option is recommended for allow policies because it prevents applications from running on unusual ports and protocol which, if not intentional, can be a sign of undesired application behavior and usage.
Note that when you use this option, the device still checks for all applications on all ports but, with this configuration, applications are only allowed on their default ports and protocols.

So, with above in mind, again - if you did not change ports intentionally or go exotic with your setups, I think application-default would work.

Small disclaimer: I am still reluctant or a bit uncomfortable to make such general recommendation in either direction, I would rather help in understanding and everyone makes their own decisions at the end. We are all trying to enhance security of our networks here, and that means taking any recommendation with grain of salt and thinking how does it apply to your network.... I think it depends a lot on the granulation of the rules... for my home I have crude and rudimentary config, for work I always pay much more attention and spend more time thinking about it.

[Anon1]

Hello all,

thank you for your extensive answers, much appreciated and helped me to understand the behavior. I also found a KB article about it: https://live.paloaltonetworks.com/t5/Configuration-Articles/After-Configuring-SSL-Decryption-Web-Bro...

I wish you could configure SSL decryption in a way that it does not change the AppID but just scans for threats and viruses in the content. Like this it makes large rulesets even larger and more complicated.

[Lucky]

Hey Anon1,

no problem. Thanks for sharing the link - it turns out I was wrong baudy, chances are you will have problems leaving it as application-default, it needs to be changed to either app you need or to any.

Anon1 - don't be discouraged, if it is inbound than it's ok and easy - it will be only one app and you already know what is it 🙂

In your case, considering your last link, it is outbound decryption - than, treat it as you treated it before, no additional rules are required? Because, now that you decrypt it does not mean you need to work more, it only means that you see more of your traffic. Same rules as before will apply (provided you change once from application default to individual applications in sec. policies or create an app group to ease that process if you will re-use app list). It requires _some_ work, in the worst case creating an app group and adding apps you needed once. Than in the rest of the rules only a small change is needed, from application default to your custom application list.

Regards

[gary.paybins]

Sorry ONLY port 80 is allowed when the app is web-browsing https://applipedia.paloaltonetworks.com/

the decrypted traffic will be identified as web-browsing on port 443 and be denied unless a custom ssl is also permitted in the rule

[DustinS.]

If anyone is still researching this topic, the behavior was changed in 9.0.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmdLCAS