Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
08-06-2018 12:46 AM
Hi,
We are having a unexpected behaviour with PA identifying a web:
"rose.pharmaintelligence.informa.com"
This web is categorize like "news". We have in our URL profile "continue". But we are seeing that this web is being denied with reason "policy deny". Why PA is not allowing this web?
08-06-2018 03:02 AM
The URL I posted describes a way to serve the resonse page to users without TLS decryption.
The firewall is able to see the URL - at least the FQDN - in the TLS handshake even without decryption. But by default the firewall is not able to inject the response page into this connection as this is only possible when the firewall sees the actual http traffic. So try the solution in the url and hopefully this will solve the issue for you/your customer.
08-06-2018 01:03 AM
It would be helpful to see the full traffic log, fields such as the session end reason etc.
Do you have HTTPS inspection activated?
Do you see the continue page?
Does continue work for other HTTPS sites?
Does the site use certificate pinning?
08-06-2018 01:30 AM - edited 08-06-2018 02:00 AM
With almost 100% certainty, this is because of TLS decryption. What pan-os version are you using?
The issue here could be related to the fact that this site already supports TLS1.3 and the firewall somehow does not understand the TLS handshake correctly even if a connection with TLS1.2 is still possible.
Try to configure a decryption exception to check if it then works. But anyway, in this case I would recommend to open a TAC case.
08-06-2018 01:36 AM - edited 08-06-2018 01:45 AM
When end-customer access to this web by https received a security event about security stuff. So customer delete https, and put http so the continue web is showed.
No decrypt ssl policy in the FW
PanOs is 8.0.3
08-06-2018 02:35 AM
In this case it is at least related to TLS decryption. Without TLS decryption configured the firewall is not able to inject the continue page and because of that you probably have this traffic log entry when users go directly to the encrypted version of the website.
When the users manually enter http:// then as you wrote the users are able to see the continue page and continue also to the website right?
08-06-2018 02:43 AM
Yes, but how can we change the TLS? any workaround?
08-06-2018 02:50 AM
Are the customers computers managed computers (where you could deploy a root CA cert)?
The best "workaround" probably is to configure TLS decryption to get a behaviour as it should be ...
PS: I would definately recommend to update to the latest recommended 8.0 release which is 8.0.10
08-06-2018 02:51 AM
But customer is not doing decrypt ssl.
08-06-2018 02:54 AM
Yes, I understood.
Then your only chance is this one here: https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Serve-a-URL-Response-Page-Over-an...
08-06-2018 02:57 AM
OK, Perfect. So you have a response page "continue" and you access to https web, its mandatory to have decrypt ssl for this web? there no any way to identify this web without https decrypt?
it was weird because the web it was identify in the correct category "news"
08-06-2018 03:02 AM
The URL I posted describes a way to serve the resonse page to users without TLS decryption.
The firewall is able to see the URL - at least the FQDN - in the TLS handshake even without decryption. But by default the firewall is not able to inject the response page into this connection as this is only possible when the firewall sees the actual http traffic. So try the solution in the url and hopefully this will solve the issue for you/your customer.
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!
