I came across some strange behaviors on a Palo Alto Networks firewall: Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections revealed an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”. What?
During troubleshooting I found the following facts. (Capturing on a Palo Alto Networks firewall PA-5050 with PAN-OS 7.1.14.) Running a custom Java application the connections aborted while the traffic log on the Palo showed the following. Note the “deny” Type while “allow” Action:
Using the packet capture feature on the Palo Alto itself on the “receiving” stage we could verify that the application sent an “Alert Level: Fatal, Certificate Unknown”, followed by a FIN, ACK:
Interestingly, using the packet capture on the “firewall” stage revealed an additional RST, ACK packet from the original source to the internal client. But since we did not see this packet on the receiving stage it was inserted by the Palo Alto:
With these captures in mind one of my colleagues told me that he has already seen this behaviour in some other cases that were all related to certificate pinning issues. That is: the custom application does recognize any TLS Man-in-the-Middle attacks since it does only allow connections to its pinned server certificate. But since we used TLS inspection at this firewall, the certificate was unknown to the application which terminated the session. Of course I am not happy with the traffic log on the Palo which did not clearly reveal for what reason it “policy-denied” the session!
Later on I searched on my Palo Alto lab unit for sessions with ( subtype neq end ) and ( action eq allow ), i.e., denied connections that have an action of allow as well. Indeed I found some with “session end reason” of either “decrypt-unsupport-param” or “decrypt-error“. Well, this at least gives some information about the root cause rather than a simple “policy-deny”:
Featured image ““The question is not what you look at, but what you see.” – Henry David Thoreau” by Sam Antonio Photography is licensed under CC BY-NC-ND 2.0.
Hi
I think this also applies to FortiGate devices.
I think I read about this in fortigate flags, “may_dirty” and “dirty” sessions.
Thanks! This Helped A lot
Hallo Johannes,
danke für deinen Blogbeitrag. Dachte schon ich wäre der einzigste mit dem Problem.
Wir haben dieselben Logeinträge type “deny”, action “allow” mit der session end reason “decrypt-error”. Nur leider handelt es sich uns nicht um ein selbstgeschriebenes Programm, sondern um den offiziellen Dropbox-Client. Im Grunde bleibt nur die Möglichkeit die Dropbox IPs aus der Decryption auszuschließen?!
Gruß
Christian
Hi Chris,
ja, genau so ist es. Ich vermute, dass wir die nächsten Jahre noch vermehrt solche Probleme sehen werden. Sprich: Dass es eine zentrale TLS-Interception irgendwann nicht mehr geben wird, weil sie quasi nur noch aus “Ausnahmen-zur-Nicht-Entschlüsselung” bestehen werden… Mal gucken.
Ciao
Johannes
Thank you. Very helpful.