cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2788
Views
5
Helpful
13
Replies

ASA 5525 and CX module

We are setting up a cisco ASA CX module and when we go to block HTTPS traffic for like facebook it will not block it. How do we turn this on with out turnning on the need for a CA.

1 Accepted Solution

Accepted Solutions

Hmmm yes.

I just tried this in my lab and see the same results - no decryption policy on the CX plus a policy saying block a site (e.g.www.cisco.com). If I go to http://www.cisco.com it's blocked with proper CX banner notification. If I go to https://www.cisco.com it is not blocked.

The event viewer shows traffic allowed to the address for cisco.com (but the URL was not parsed) via tcp/443.

It looks like a bug. URL objects are only being parsed for http, not https (at least not without a decryption policy).

View solution in original post

13 Replies 13

Marvin Rhoads
Hall of Fame
Hall of Fame

You don't have to decrypt the ssl (and thus need an intermediate certificate from a client-trusted CA) to block an https URL. Simple URL filtering (described here) will suffice.

That dose not really discribe how to do it. for an example we have a rule to block facebook. The rule works as long as the users goes to http. But when they type https and facebook they get through and the cx module shows no log of the traffic.

HK Loh
Level 1
Level 1

i had the same problem to block https facebook and youtube...

Any Expert can help/guides to solve the problem...

You need to make sure you redirect the https traffic into the CX first with a policy-map and service-policy.

If that's not working, please share the relevant ASA configuration bits and screen shot of the PRSM policy elements that aren't working.

I manage to solve my problem with redirectting HTTPS traffic to CX and Generating self-sign certificate to intercept https traffic at CX. Then configure decrypt policy to all https traffic.

Thanks Marvin.....

Glad it helped. Please rate useful replies. Thanks

I am trying to do this without the Certificate. I do not have control over the some of the end points. So i can not stand up a CA for them to use. And i dont want the users to have to accept a certificate every time they go to a secure web page.

Chris,

Have you tried redirecting https and using URL filtering without decryption?

Decryption (and a trusted certificate) should only be necessary if you want to inspect the http payload encrypted with SSL. The URL for https sessions should be in cleartext.

Yes we have tried redirecting. But it shows no logs of HTTPS going through the CX at all. So we see no traffic at all going through the ASA as 443. But port 80 works all day. But if we turn on the Decrypt it show port 443. But we dont want to use that peice, becouse of the guest wireless.

Hmmm yes.

I just tried this in my lab and see the same results - no decryption policy on the CX plus a policy saying block a site (e.g.www.cisco.com). If I go to http://www.cisco.com it's blocked with proper CX banner notification. If I go to https://www.cisco.com it is not blocked.

The event viewer shows traffic allowed to the address for cisco.com (but the URL was not parsed) via tcp/443.

It looks like a bug. URL objects are only being parsed for http, not https (at least not without a decryption policy).

Do you know when there might be a bug fix for this? I am actually planning on using the CX to replace my current Websense. If its fairly quick i can hold off renewing my Websense contract.

Thanks for confirming my suspissions.

Hard to say - the latest release as of right now was 23 July (9.1(2) Build 42) and I know there are documented significant bugs in that release.

I'm not sure the issue we are discussing is even documented as a bug. If you have support on your CX, I'd suggest opening a TAC case to confirm the behavior is a bug (as we believe).

(My lab unit is a loaner and doesn't have Smartnet support to allow me to do so myself.)

Chris,

Note this nugget from the CX 9.1(3) Release notes (October 29 2013):

URL category and web reputation are now available for TLS/SSL traffic even if you do not enable decryption. Access policies that use URL filtering or web reputation filtering will now apply correctly to undecrypted TLS/SSL connections. Note that this change is not reflected in the user documentation for this release. The feature is also not available in 9.2(1.1).

I think that addresses the issue we we both seeing. I've already moved my lab unit onto 9.2(1.1) so I can't verify it with testing.

Getting Started

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: