Trouble decrypting Google traffic

[cryptochrome]

Hi,

we have some trouble with a lot of Google sites when we enable SSL decryption and also enable CRL and OCSP checks. We either get no response at all, or error messages like the one in the attached screenshot. If we disable the CRL/OCSP checks (which is undesirable I guess), then we have no problems at all. Google is the only destination we have these problems with and regarding to the system logs, the CRL list retreival is working fine.

Any ideas?

Thanks

Sascha

[kprakash]

If you look at the certificate that you get when you go to any google website like https://youtube.com (click on the icon to the left of the address to view certificate info) you will see that the common name is *.google.com.  Google uses this wildcard certificate for most of its sites.

Before decrypting the traffic the firewall only has the common name on the certificate to use for looking up URL category.  *.google.com is in the Search Engines category, so that's what the firewall identifies it as when you go to google sites like

https://youtube.com , or basically any other Google service.  Once you have decrypted the traffic the firewall can do the URL lookup based on the HTTP GET request for the website.

Best regards,

Karthik RP

[cryptochrome]

Thanks, but it's not a problem of being blocked by firewall policy. It's a problem with the PAN checking Google's certificates.

See this:

As I wrote above, it must have something to do with checking CRL/OCSP in Device -> Service -> Session -> Decryption Certificate Revocation Settings.

If we disable the checks, it works fine.

[zarina]

Looks like the CRL/OSCP check is timing out - look at Status: timed-out and hence the error message. Can you verify if there is any network latency in retrieving the crl list or reaching the server itself?

[cryptochrome]

As I said earlier, regarding to my system logs, there are no issues with retrieving the CRL lists. There is no timeout, and Google is the only destination that's affected. The "timeout" in the error message is indeed strange, but sometimes we get no error message at all.

Thanks!

[UhMayYeah]

1>Can you  try to increase the timeout value for the settings under Decryption Certificate Revocation Settings : to max=60sec .

2>What is the Software Version installed on the firewall?

3>Can you attach the following log

>less mp-log sslmgr.log

Also following discussion may interest you:

https://live.paloaltonetworks.com/message/28884#28884

[cryptochrome]

Hello Nadir,

we are running 5.0.4. And I am seeing the same error messages in sslmgr.log that are described in the other discussion you linked to. So it's safe to assume we are hitting this bug as well. I will try to turn off OCSP checks. If I understand the bug correctly, it's only happening after turning on OCSP. What do you think?

Thanks

Sascha

[UhMayYeah]

Hello Sacha,

If you are seeing the same error ,its likely that we are  encountering the Bug referenced in the discussion that would be fixed with OS_5.0.7.

-Nadir

[cryptochrome]

Thanks. Just for clarification: Isn't certificate revocation checking decoupled from decryption? Meaning, even if I bypass Google from decryption, wouldn't the certificate checks still jump in? Or are these settings only used in tandem with decryption?

[mikand]

Where can I find a statement in the manual that proofs this?

As far as I know the PA will only check the cert for revocation when its being part of the decryption.

If the session is not being intercepted then there will be no checks for revocation (how would the PA otherwise be able to display an error message for the client (that the cert is revoked) if the ssl session isnt decrypted?).

[UhMayYeah]

I have generally seen OSCP settings come into play for   CP ,GP

But based on the Bug that was referenced in the  https://live.paloaltonetworks.com/message/28884#28884.

OCSP did affect ssl-decrypted traffic.The CLI setting to enable OCSP is as follows:

# set deviceconfig setting ssl-decrypt ocsp yes

which I found is same as enabling OCSP from the WebUI.