SSL Inbound decryption woes

[cryptochrome]

Hi there,

we just configured our first SSL Inbound decryption, but we have some trouble and need help troubleshooting it.

Very simple setup:

Webserver in DMZ zone

Firewall policy: from:untrust to:dmz; src:any; dst:webserver; app:ssl,web-browsing; service:service-http(s); action:allow

Decryption policy: from:untrust to:dmz; src:any; dst:webserver; action:decrypt

The webserver's certifictate and key have been imported to the firewall.

Accessing the webserver from an external PC: Traffic gets decrypted perfectly.

Accessing the webserver from an iPhone and from and Android device: Traffic is *not* being decrypted.

In all cases the source IPs were completely random and are not subject to any firewall rule. This is reproducible and I tried to find out why it would decrypt in one case but not in another.

Any ideas? Is there a way I can troubleshoot this other than looking at the traffic logs, which don't contain any helpful information?

Thanks

[mikand]

First of all I would try without the inbound inspection to verify that there isnt something else thats borked.

Then I would verify that I have the inbound inspection properly setup including:

Block sessions with unsupported version

Block sessions with unsupported cipher suites

Block sessions if resources not available

Verify then in monitor -> logs -> traffic that when you visit using browser (from computer and not iPhone/Android) that the traffic is really decrypted (should be a checkbox in the "Decrypted" part to the right of the popup - you get the popup if you click on the magnify-icon to the left of the traffic log row). Then do the same for the visit from your iPhone/Android device and compare.

Third I would take a tcpdump of the traffic which your iPhone and Android produces to look into which cipher suites are being requested and what is actually happening on the line (preferly compare this with the traffic generated when your browser from your computer (non iPhone/Android device) visits this https-site).

For example PA has problems with newer versions of TLS (not supported at all) and the inbound inspection wont work at all if DH (Diffie Hellman) is being used for obvious reasons (both would the tcpdump help you with to find out).

[Ameya-Kawimandan]

As far I understand , the unsupported modes and failures would be bypassed and not decrypted, unless you have configured a Decryption Profile and checked the options to Block sessions in case these checks fail.

[cryptochrome]

Hi Mikand,

thanks for the detailed instructions. Actually, I already did all of that except for the tcpdumps. The decryption policy is definitely ok (else it wouldn't decrypt the non-iPhone sessions). We also have a decryption profile that specifically blocks unsupported versions/ciphers and if ressource is unavailable. This means these sessions are supposed to blocked, but they are not. They are just not being decrypted.

What bugs me the most is that there is simply no information on the box about what's going on. At least not obvious. The traffic log is not helpful at all, since all it tells me is whether a session was decrypted or not. It doesn't tell me why. There is nothing in the system logs either. The exclude-cache is empty. I love PAN, but in this area they need to improve. A lot.

I am going to ask the customer to send me the server's certificate so I can check whether it uses Diffie Hellman. That's about the only thing left I can think of as a culprit.

[mikand]

With some luck there should be some ssl related info in dp-log or the mp-log.

Try with "less dp-log" or "less mp-log" followed by a press on the tab-key to see which files are available.

Once located you can tail the file with:

tail follow yes dp-log <filename>

or

tail follow yes mp-log <filename>

(dp = dataplane, mp = managementplane)

You can also use grep to search for strings withing these logfiles.

[ericgearhart]

We just confirmed this same behavior... a colleague of mine at work was trying to get decrypt working, and I remembered this thread. Decrypt works fine and the URL filtering log populates when he browses using a regular laptop, but from an iPad SSL decrypt does NOT work. The App-ID stays 'ssl' instead of flipping over to web-browsing, and the URL filtering log doesn't populate when he browses from an iPad.