No anti-virus response page for SSL

[tcjnole64]

I have SSL decryption setup and working.  When I go to eicar.org, the http test returns my response page.  The https test doesn't return any response page; although I can see in the threat log that it was properly denied.  The browser just spins waiting for something to return.

I've attached a snippet from the log.

Thanks,

Todd

[gafrol]

Hi Todd,  actually https traffic should show up as Application ssl and not web-browsing. In your security policy did you allow application ssl for this test ?  rgds Roland

[tcjnole64]

Interestingly, with decryption off it shows port 443, appl ssl.  With it on, it shows port 443, appl web-browsing.  It's doing the right thing as far as blocking the test virus.  I'm just not getting the anti-virus response page.  The browser is waiting...

[bpappas]

what version of PANOS are you running on the firewall?

and what version of the app/threat content?

[sboelter]

Hi, we have the same problem, the browser just shows "can not display page". Our PA-500 is running on 3.1.8 with  Version 241-941 for apps and threats.

[bpappas]

@tcjnole64:

when SSL decryption is ON the firewall will see the decrypted application (in this case web-browsing). So if you are using SSL decryption then your policy needs to allow SSL and web-browsing

question: are you using a self-signed certificate for the response pages? we have observed, in some cases, that the browser times out while attempting to look up the certificate when using self-signed certificates. we have had some luck placing self-signed certificates in the browser's "trusted root certificate" store instead of the default "trusted personal certificate" store.

[S.Cantwell]

Has there been any update on this, that someone from PANW could respond back with.

I have decryption enabled, with a self-signed cert in my trusted cert authority stores.

The response page is properly seen with web-browsing, port 80, threat log show reset-server as action.

The response pages is NOT seen with (decryption enabled) with web-browsing, port 443. Threat log shows reset-both as action.

I changed the AV profile to perform reset-server, and tested with decryption, and still same issue (Chrome, FireFox, IE)

There is a very brief article at

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

CAN I ISSUE BLOCK PAGES OVER SSL?
 Created On 02/07/19 23:52 PM - Last Updated 02/07/19 23:52 PM

Resolution

Yes.  For URL filtering, file blocking, and antivirus profiles, you can automatically issue a block page by setting the policy action to "block". 
In order to issue a block page over SSL, you must also enable SSL decrypt.

This above article talks about a policy action of block. Policy...not security profile (which there is no block in AV...)

I have a rule in 9.0.2 software.

Trusted --> Untrusted-->Any--> Application-default (allowed) with an AV security profile that shows http (action default or reset-both)

When I browse to Eicar (on port 80) download the Eicar test file.  I am blocked.

When I do this with Decryption enabled, now we have web-browsing on 443 (in 9.0.2, app-default include secured/unsecured ports in the app signature, with a "Page Cannot be Displayed"

What steps am I missing.  What explanation do I give to my students/customers who ask why this is not working?

Thanks

Steve 

[S.Cantwell]

Well, rather than remove my post... I found this one which I think explains a little better.

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

Resolution

Symptom

When using SSL decryption policy to block malware, the block page does not always display.

Cause

When requesting a web page, browsers tend to allow any response with a header similar to this:

Accept: text/html, image/png, */*;q=0.1\r\n

The */* indicates any response will be accepted.

When requesting a specific object (.zip, .txt, etc.) the client browser may only allow that type of response, limiting what the browser will display. If requesting a .txt file, you may only see:

Accept: text/text\r\n

When the firewall displays a response page indicating that the request is blocked due to a virus, it displays it as an html page. The mime-type is text/html. This can mean that if the browser is only allowing text/text, the page will not be displayed.

During an SSL communication, the client browser may close the request rather than display an error that the mime-type did not match what was requested. This results in the browser just "spinning", not displaying any page until an error is presented after a timeout.

owner: gwesson

[S.Cantwell]

However, as I continue to understand this.

What is different between a port 80 browser page in terms of 

When requesting a web page, browsers tend to allow any response with a header similar to this:

Accept: text/html, image/png, */*;q=0.1\r\n

And when the Response Page DOES work on port 80.

Does the same port 80 browset see

Accept: text/text\r\n

Why does it not provide same Page Cannot Be Displayed Error?

PANW, please advise. 

[S.Cantwell]

AHA.   I found the best response, and it does make sense.

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

Antivirus block page presents inconsistent behavior

Created On 02/07/19 23:36 PM - Last Updated 02/07/19 23:36 PM

Symptom

Testing a virus download from different websites using SSL Decryption yields different results.

Sometimes you receive a response page indicating Virus/Spyware Download block, and on other sites you don't see a response page.

(Examples shown are 2 websites with the Eicar test file.

One is broken, 2nd one works as expected)

The reason for the behavior presented with the first website, https://secure.eicar.org/eicarcom2.zip, is, we don't detect the threat in the first packet of the response. In this case, the HTTP headers were already transmitted to the client. In this situation we can't send the response page, and therefore the only action taken is sending a reset to both client and server as configured in the profile.

In the case of the second website, https://www.ikarussecurity.com/fileadmin/user_upload/testviren/eicarcom2.zip, we detect the threat early, in the first packet of the response, so we are able to send a response page to the client.

This answer my question and links together 2 very similar knowledge articles, so hopefully someone will "like" my responses.