Block response page not displaying for blocked SSL (https://) URL

[jacenkoj33]

We have a pair of  ASA 5525 with sourcefire enabled. I'm tasked with blocking access to some websites capable of file uploads like facebook or linked in. The issue I'm having is sites using http:// get the block response page. SSL sites using the https:// time out eventually then display page cannot be displayed.

So the sourcefire is doing it's job blocking access to restricted sites but the concern is that users will get page cannot be displayed and cause in influx of unnecessary calls to our helpdesk thinking the internet access is down... 

I've scoured the user guide but there doesn't seem to be an obvious answer how to get the SSL sites to display the block response page. If anyone knows the fix for this please do share I'd be greatly appreciative. Thanks

[Marvin Rhoads · Accepted solution]

The block response page is not available for SSL pages.

I had a customer with the same question and the TAC confirmed it.

[jacenkoj33]

Thanks Marvin. I suspected as such. 

[SHABEEB KUNHIPOCKER]

Hello Marvin,

I have the same issue. I am using firesight management VM 6.0. Is there any work around for this issue?.

Thanks 

shabeeb

[smoores]

It seems the best you can do for now is to Block + Reset so the user doesn't have to wait for it to time-out and gets a more immediate "page cannot be displayed".

[Daniel Weber]

Is this still true 7 years later (02/20/2022) using Cisco Firepower? Documentation makes it sound like it should work... Yet, I do notice that within the Access Control Policy the tab for this feature only states "HTTP" and NOT "HTTP(S)"... 

[Daniel Weber]

To answer my own question, yes it does work with HTTPS websites... The insertion page is VERY finicky though. my particular issue was that I had originally created the root CA for my microsoft trusted certificate authority with SHA1... Everything started working after migrating the certificate to SHA2.

[saifuddin.miyaji]

Hi,

It has been almost a year since this response was posted. Is there any enhancement on the subject? Could we display a block response webpage for https now?

-Saif

[Marvin Rhoads]

Sorry, but here's the current specifications of the block response pages (from the 6.1 Configuration Guide = current release as of October 2016)

The system displays a response page only for unencrypted or decrypted connections blocked (or interactively blocked) either by access control rules or by the access control policy default action. The system does not display a response page for:
• Tunnels and other connections blocked by a prefilter policy
• Connections blacklisted by Security Intelligence
• Encrypted connections blocked by an SSL policy

[Gamaquifor]

Actually... the excerpt you posted says the contrary of your point. This pushed me to look into the release notes for 6.1 and I confirmed that in fact, from 6.1 on you can display response pages for SSL traffic decrypted by an SSL rule and blocked by an Access Rule. I also spent about 1 hour with Cisco fighting with two techs who were from the backbone team and kept telling me this wasn't a feature!!! Yet I pulled up this information and was able to prove it. I am now updating so I can test. Good luck

[Marvin Rhoads]

If they are decrypted by policy - yes. If not (like 98% of the implementations out there) then - no.

I've only ever seen one customer who had an SSL policy that was decrypting and resigning everything SSL outbound. It's very unusual as it requires having an internal PKI and trust of your certificates pushed to all client computers.

[Gamaquifor]

Well, is not that hard for other appliances which is why I was very surprised when I originally revised this with Cisco about a year ago. Watchguard can do it. Not guessing, or reading I have actually configured a few myself. The appliance generates a self signed cert and it has the ability to inspect traffic, reencrypt and serve to client. There are some web apps which will not like this (banks for instance) but if you really want to secure your network... well.. the bad guys know how to use the https system as well. Not sure of the need for a PKI, but yes, all we had to do is deploy the cert with GP. This is an issue for third party browsers, actually Firefox only as Chrome uses the IE cert store.

I can see environments where you wouldn't want to do that. It works for me on the support customers side of things. If I just let the browser show its default error the helpdesk guys will get killed with calls (>200 users env). 

If I can instead show that this is actually blocked by company policy, it will discourage a lot of calls from users. 

[bcoverstone]

We're the second! I'm doing it for every single website, except financial and healthcare.

We've had our own trusted root certificate in our domain for years and now we finally have a firewall that utilizes it.

What I find odd is HSTS websites seem to magically bypass the SSL Decryption even though I have EVERYTHING set to decrypt, such as https://www.google.com.

I did see it resign https://www.google.com once and throw an HSTS error, but that was a couple of weeks ago. I can't seem to make that happen now, so I don't know what I did differently.

Also, the SSL Decryption feature is VERY finicky. If you put too many rules in (i.e. select everything and choose to not decrypt trusted URLs) it just won't decrypt anything.

Like you said, I'm the second person to actually use this, and the bugginess in the SSL Decryption setup reflects that.

[Gamaquifor]

In case you are still interested, this worked for me with firepower/firesight 6.1. The appliance can now effectively decrypt and resign HTTPS traffic (aka "decrypt resign). If it matches an access rule, the respective "response page" is returned. To keep performace in check, you can use categories and other parameters to decide which traffic to decrypt so that is a big plus in my env. 

[chawkideeb]

Dear Gamaquifor,

Can you tell me the step-by-step on how you get the response page for https blocked pages?

thank you.

best regards,

chawki dib