topic Hello Marvin, in Network Security

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

jacenkoj33 — Tue, 12 Mar 2019 12:47:12 GMT

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

The block response page is

Marvin Rhoads — Wed, 14 Oct 2015 12:59:20 GMT

The block response page is not available for SSL pages.

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

Thanks Marvin. I suspected as

jacenkoj33 — Wed, 14 Oct 2015 13:42:14 GMT

Thanks Marvin. I suspected as such.

Hello Marvin,

SHABEEB KUNHIPOCKER — Sat, 06 Feb 2016 19:39:55 GMT

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

It seems the best you can do

smoores — Fri, 12 Feb 2016 19:14:47 GMT

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".

Hi,

saifuddin.miyaji — Sat, 01 Oct 2016 16:35:47 GMT

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

Sorry, but here's the current

Marvin Rhoads — Sat, 01 Oct 2016 18:07:48 GMT

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

Actually... the excerpt you

Gamaquifor — Tue, 04 Oct 2016 22:28:57 GMT

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

If they are decrypted by

Marvin Rhoads — Tue, 04 Oct 2016 22:40:05 GMT

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.

Well, is not that hard for

Gamaquifor — Tue, 04 Oct 2016 22:48:15 GMT

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.

In case you are still

Gamaquifor — Thu, 06 Oct 2016 03:32:12 GMT

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.

Dear Gamaquifor,

chawkideeb — Thu, 23 Feb 2017 08:34:14 GMT

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

Nothing in special. Just use

Claudiu Cismaru — Fri, 24 Feb 2017 15:38:09 GMT

Nothing in special. Just use a Decrypt with Resign policy.

As Claudiu mentioned, the key

Gamaquifor — Fri, 24 Feb 2017 15:52:15 GMT

As Claudiu mentioned, the key here is to decrypt the traffic first. For that you need to have an SSL Policy, this can found under Polcies>Access Contro> SSL. Key things to have in mind when deciding to decrypt SSL traffic:

- There some web apps who DO NOT LIKE you decrypting the traffic. (i.e. Office 365). It is key that you add the respective SSL polices to Not Decrypt this traffic. You can use certificates CNs to white-list the traffic. O365 is just an example, you will need to observe your network so you know which applications will need to be white-listed

- I would recommend to only decrypt traffic of interest and not all traffic. The more decryption/resigning you have going on, the bigger the hit on performance. I wouldn't go too crazy if you are just running a 5506.

- Be sure you have distributed the firewall's Certificate to your clients (computers, servers) before you put an SSL policy in play.

Once you create SSL policy, you need to assign it to your Access Control Policy. When you open your Policy you will see on the top an option that says "SSL Policy:" here you can assign the policy you just created.

Lastly, a lot can go wrong with SSL decryption if not done right. Although I have done on a few appliances, I always run tests on each environment before production.

We have created an SSL Policy

msamadpour — Thu, 22 Jun 2017 11:41:25 GMT

We have created an SSL Policy that matches interesting traffic utilizing the decrypt-resign action. A corresponding Access Control Policy blocking the interesting traffic with an HTTP responder has also created.

When browsing to an SSL/HTTPS site using Internet Explorer, the site is properly blocked and we receive the HTTP response page.

However, when using Chrome/Firefox browsers, the page does not properly inject. Each browser complains about HTTP Strict Transport Security (HSTS)

Anyone else running into this issue? Any fixes?

If the webpage uses HSTS I do

Dennis Perto — Tue, 27 Jun 2017 17:56:28 GMT

If the webpage uses HSTS I do not think that you will be able to "fix" this.

It is working as intended.

Re: Hi,

bcoverstone — Mon, 06 Sep 2021 15:31:46 GMT

As long as SSL Decryption is running, then yes, you can display a block response for HTTPS websites.

However, for HSTS websites, SSL Decryption can't work, because it's basically viewed as a "Man In The Middle" attack.

Re: If they are decrypted by

bcoverstone — Mon, 06 Sep 2021 15:36:57 GMT

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.

Re: The block response page is

Daniel Weber — Sun, 20 Feb 2022 18:01:29 GMT

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)"...

Re: The block response page is

Daniel Weber — Wed, 23 Feb 2022 04:16:16 GMT

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.