cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1245
Views
0
Helpful
4
Replies

5520 CSC very bad HTTPS traffic

tahequivoice
Level 2
Level 2

I have a TAC on this, but thought I would throw it out here too.  We recently upgraded a 5520 to 8.4 code so HTTPS traffic can filter through the CSC. Well, it caused a major headache now in that it takes several attempts to pull up any https pages. Cisco thought it may be hardware, so I swapped out the CSC, but before I go through the hassle of moving licnese, I brought a second ASA with CSC, which prior to this was their main ASA running 8.2 code and did not have issues, of course HTTPS did not filter through it either.

The exact same thing happened on this ASA.  So apparently it is not hardware related.

One other thing I found, if I bypass https, it still happens, and the only solution is to shut down the CSC module.  Now I think it may be the ASA policy that while not the cause, but is being difficult.  I found that if you pull SIP inspections out, and reapply them in testing voice issues, you must reboot the ASA for them to work again. I am wondering if this is the case with the HTTPS traffic not releasing from the CSC even with the ACL having it removed. I need to try that next.

Now has anyone else run across this issue with HTTPS traffic through the CSC being really slow, timing out, or just not displaying right away, and after several refreshes finally bring the page up? 

4 Replies 4

julomban
Level 3
Level 3

Hello,

For HTTPS Filtering there are some things that you need to keep in mind, I suggest you to read the Article about SNI:-

https://techzone.cisco.com/t5/ASA-CSC-Module/Q-amp-A-How-does-HTTPS-URL-Filtering-and-Blocking-work-...

So just in case if you are having majority of your Operating Systems as XP, then i think you know the answer.

I don’t think the issue is related to the ASA ACL but make sure the management IP of the CSC module is except from been inspected.

Regards,

Juan Lombana

Please rate helpful posts.

I dont have access to your link.   

Hello,

I just copy part of the link i provided before:

Question

Since  HTTPS is encrypted, How does the CSC Module determine what site is  being requested in the encrypted stream? What issues could users/admins  face?

Answer

Since HTTPS is encrypted, seeing the encrypted HTTP GET within the  stream would involve decrypting the SSL session and re-encrypting it.  Unfortunately the CSC Module does not have enough horsepower to do this  on any scale. As a result the CSC module has to rely on certain  functions within SSL to learn what hostname you are trying to reach on  that SSL session.

The CSC module, since it cannot do man-in-the-middle SSL Decryption, relies on an extension of the TLS header called Server Name Indication (SNI). The specifics of Server Name Indication (SNI) are detailed in RFC 6066:

3.  Server Name Indication

   TLS does not provide a mechanism for a client to tell a server the
   name of the server it is contacting.  It may be desirable for clients
   to provide this information to facilitate secure connections to
   servers that host multiple 'virtual' servers at a single underlying
   network address.

   In order to provide any of the server names, clients MAY include an
   extension of type "server_name" in the (extended) client hello...

Source: RFC 6066 http://www.rfc-editor.org/rfc/rfc6066.txt

As noted above, the Client Hello sent by the browser is where we will find this SNI information. For example, here is the detail from a Client Hello contacting https://www.facebook.com/. You can see that the SNI field is highlighted and the text string indicating www.facebook.com is present in the bytes of the packet. This is what the CSC Module looks at the determine what HTTPS site you are requesting:

clienthello.png

Once the CSC Modules sees the Client Cello and extracts the SNI information (if present)  it makes a filtering decision based on that string and the URL  Filtering/Blocking policies configured. If the page is allowed, the  content is passed to/from the client/server without interruption. If the  page is blocked, the CSC Module will return its own certificate and a  block page. This usually results in a certificate error being displayed  the browser since the CSC Module will use its own self-signed  certificate for this task. Administrators can optionally import a  certificate into the CSC Module (via the GUI) to use for this instead of  a self-signed certificate,

Caveats

Since this process relies solely on the presence of the SNI details, some browsers may not be filtered properly. In testing in the  lab and as documented online, the following major issue has been seen:

Internet Explorer (any version) on Windows XP will NOT send the SNI and cannot be HTTPS Filtered/Blocked

The following browsers are confirmed to work because they send the SNI in the TLS Client Hello:

Internet Explorer - Version 7.0 or later and the OS must be Windows Vista or Later

Firefox - Version 2.0 or later on any OS

Chrome -  Version 6 or later. On OSX 10.5.7 or higher you need Chrome 5.0.342.1 or later.

If you are running a supported browser and still seeing issues, you can test the SNI functionality of the browser by going to https://sni.velox.ch/ . If you are presented with a certificate error, then your browser likely does not support SNI. The page will inform you, on the first line, of your browser's SNI capability. Make sure TLS is enabled in the browser!

More details on this can be found here:

http://www.cisco.com/en/US/docs/security/csc/csc66/administration/guide/csc4.html#wp1098125

Thanks. I had the end user go over this document, and it doesnt apply.   They are all on new machines, IE no older than version 8, no firefox or chrome is used, and occurs even on brand new Windows 8 machines.  Temp workaround is to bypass HTTPS filtering for now.

One thing I discovered, if you remove 443 from the class-map ACL while the traffic is going through the CSC, it will continue to pass https through the CSC until you either reboot the ASA or shutdown and reset the CSC.  Doesn't surprise me though, if you mess with SIP inspection, you have to reboot it too.

The symptoms are very similar to MTU issues.  If you run over a GRE tunnel without using IP tcp adjust-mss 1436(or similar), https pages act the same way, they either time out, or come up after a few refreshes.  We also tried setting mss through a class map, which helped some, but didn't totally correct the problem.

After our tests, its clearly an issue with the CSC software, we RMA'd the CSC and the probem followed, so not hardware.

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: