File Blocking Continue Page in a TLS connection

[karimanizer]

Hello everyone, 

I have a PA-VM in version 9.0 .1 , 

I have setup a File-blocking profile and attached it to my allow-all security policy. The File-Blocking profile has the action of "Continue" for ".exe" file type. 

In the other hand, I configured a decryption policy. 

My problem is that when I try to download an .exe file via HTTP I get the "Continue" response page . However when I try to download the same file via HTTPS the download is blocked and no response page is display. 

I would like to know why the response page is not displayed when the file is downloaded via a TLS connection. 

many thanks, 

karim

[S.Cantwell]

This is always one issue that strikes a chord with users. 

The issue is really how the webpage is created and not much about how the FW is configured.

Read this below article.

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

[karimanizer]

Hi SteveCantwell, 

Thanks for your reply , 

I tried to dig deeper in this and wanted to see if the firewall was actually sending the continue page on the wire. I took a pcap on the client side and decrypted the traffic and I do not see the continue page sent on the wire.  I see only the reset sent by the firewall. 

I then performed  the test via HTTP (without changing the paloalto configuration) and here I see the correct 503 response from the firewall. 

 

Does anyone know why the response page is not sent by the firewall when using TLS connection  ?

Many thanks,

Karim

[BPry · Accepted solution]

@karimanizer,

Expected behavior. As @S.Cantwell already mentioned by linking the article Gwesson made, the firewall can't send a text/html mime-type if the browser is only going to accept a specified response. With 9.0 a change was made so that it simply resets the connection instead of presenting something that isn't going to be accepted by the browser anyways so you don't have to wait for the timeout. 

Due to user experience, it's better if the firewall simply resets this connection instead of attempting to send an invalid response type. 

[karimanizer]

Hi @BPry , 

    | With 9.0 a change was made so that it simply resets the connection instead ... 

Thanks for the clarification !

The article you are referencing seems to say that the firewall always sends the "Continue" page and it was the browser that sometimes, due to mime-type mismatch,  does not display the page.  Which is not exactly true.  So I thought I had something wrong in my config. 

Many thanks for both of you,

Karim

[karimanizer]

Hi @BPry  @S.Cantwell , 

I recently discover that CheckPoint firewalls solve this problem by redirecting the client to another page instead of responding to the initial GET request with a blocking page. 

Hope that Palo will introduce this feature in later release 🙂 

many thanks, 

karim