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