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?
For HTTPS Filtering there are some things that you need to keep in mind, I suggest you to read the Article about SNI:-
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.
Please rate helpful posts.
I just copy part of the link i provided before:
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?
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:
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,
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:
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.