06-17-2015 03:17 PM - edited 03-10-2019 06:24 AM
It appears that if I block a URL that is reached only via HTTPS (Facebook in this case) I cannot display an HTTP response that informs the user as to what happened, they just get a connection reset error.
Is that a limitation of the URL filter or do I not have something configured properly?
07-15-2015 07:53 PM
I'm seeing the same issue with SFR modules for ASA.
I'd think this is due to the nature of HTTPS filtering that happens on a lower layer than HTTP\Application layer.
With HTTPS the connection is getting terminated during HTTPS ( session layer) session set up, thus before HTTP (application layer) has a chance to kick in.
Thus without HTTPS decryption the sfr doesn't get a chance to show custom page.
Checking thins on a Palo Alto firewall at the moment, they can decrypt HTTPS unlike virtual SFR. The PAs do show custom block page, but only after you accept firewall's spoofed certificate. Obviously when you go to an HTTPS web site the firewall will interept the connection and present a self-sighed cert instead of the real one when decryption is enabled.
If firewall's cert used to sign spoofed cert was trusted this would be seamless for the users.
07-17-2015 08:41 AM
I did not have this behavior on the CX platform and I did not do HTTPS decryption on it. I also did not have this behavior on the McAfee Secure Gateway appliance that I used previously and we also did not do any SSL decryption there.
I get that this is a device that is primarily for IPS and it just happens to do some filtering but for the price hike I would expect a bit more feature parity.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: