- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-28-2018 03:24 AM
Hello all,
I am trying to implement URL Filtering for HTTPS websites but without decryption. I found a post on how to deliver response pages to Users. (https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Serve-a-URL-Response-Page-Over-an...)
The URL Filtering is working for me but I dont understand the flow. What is the Firewall exactly doing?
1. Is forward trust certificate used to read the HTTPS header?
2. We dont have any decryption profiles. Is any kind of decryption happening?
3. The URL Filtering works if the user is using a browser to open an application. But when the user uses an application to access a URL then the connection fails. Any ideas what could be going wrong here?
Thanks and Regards,
RJ
08-28-2018 10:29 AM
@rjdahav163 wrote:1. Is forward trust certificate used to read the HTTPS header?
No, as @OtakarKlier already wrote, the headers are sent in cleartext so the firewall can simply read them without any additional steps. In these headers (->TLS handshake) the client also sends the fqdn where it wants to connect to so the firewall is able to see the URL without decrypting the traffic and apply the configured URL filtering rules.
The forward trust certificate is (in your case without TLS decryption) used to dynamically generate certificates for the domains where the client tries to connect to. This generation the firewall does only for domains that are set to block/continue or for all domains where a response page is required. And this generation is required to properly present this repsonse page to the user as the firewall cannot inject the response page into the http connection without decryption so it has to do it this way.
@rjdahav163 wrote:2. We dont have any decryption profiles. Is any kind of decryption happening?
No, there is no decryption of actual usertraffic happening.
@rjdahav163 wrote:3. The URL Filtering works if the user is using a browser to open an application. But when the user uses an application to access a URL then the connection fails. Any ideas what could be going wrong here?
Is the application connecting to an URL that is blocked?
08-28-2018 09:54 AM
Hello,
When you are not decrypting https traffic, the firewall is only reading the headers. The headers in ssl traffic are not encrypted and only contain info such as source and destination. The payload of the packet is the part that is encrypted.
Hope that helps.
08-28-2018 10:29 AM
@rjdahav163 wrote:1. Is forward trust certificate used to read the HTTPS header?
No, as @OtakarKlier already wrote, the headers are sent in cleartext so the firewall can simply read them without any additional steps. In these headers (->TLS handshake) the client also sends the fqdn where it wants to connect to so the firewall is able to see the URL without decrypting the traffic and apply the configured URL filtering rules.
The forward trust certificate is (in your case without TLS decryption) used to dynamically generate certificates for the domains where the client tries to connect to. This generation the firewall does only for domains that are set to block/continue or for all domains where a response page is required. And this generation is required to properly present this repsonse page to the user as the firewall cannot inject the response page into the http connection without decryption so it has to do it this way.
@rjdahav163 wrote:2. We dont have any decryption profiles. Is any kind of decryption happening?
No, there is no decryption of actual usertraffic happening.
@rjdahav163 wrote:3. The URL Filtering works if the user is using a browser to open an application. But when the user uses an application to access a URL then the connection fails. Any ideas what could be going wrong here?
Is the application connecting to an URL that is blocked?
08-29-2018 01:49 AM
Thanks @Remo !! Your answers are just what I was looking for.
As far as No. 3 goes, when we access the URL for example, abc.def.com then in the URL logging we see abc.def.com.
But when the user access it using his application we see *.def.com in the URL filtering logs. The application logs say that the connection is being initiated to abc.def.com. But something is fishy I guess in the application. It is trying to connect to *.def.com somehow but we are not seeing it in logs. Probably wireshark will help.
09-01-2018 06:54 AM
The firewall only sees the full FQDN if the TLS handshake uses the SNI extension. In this extension the client tells the server where it connects to the exact FQDN so the server is able to choose the apropriate certificate to use for the connection (in case there are more than one websites with different names on the same server). If this SNI extension is not predent in the TLS handshake (probably the case with your application) then the firewall will use the CN of the certificate for URL filtering - and URL logs. Sometimes the CN matches the FQDN but not when the server uses a wildcard certificate - like in your example.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!