Cisco Security Modules for Security Appliances

How does the ASA CSC Security Services Module act as a proxy for HTTP traffic?

Document ID: 115747

Updated: Jan 11, 2013

Contributed by Magnus Mortensen, Cisco TAC Engineer.



This document describes how the Cisco ASA Content Security and Control (CSC) Security Services Module can act as a proxy server for HTTP traffic.

Refer to Cisco Technical Tips Conventions for information on document conventions.

Q. How does the ASA CSC Security Services Module act as a proxy for HTTP traffic?

A. Understanding the steps involved in establishing an HTTP connection through the CSC module will help you understand other issues (such as page errors and performance problems):

  1. When a user tries to connect to a site, their browser sends a SYN packet to the IP address of that site.

  2. The CSC module, which acts as a proxy, intercepts the SYN packet and replies with a SYN-ACK on behalf of the site.

  3. The web browser, which is unaware that the CSC module acts as a proxy, replies with an ACK, and a connection is formed between the client machine and the CSC module HTTP proxy engine.

    Note: The first half of this connection is referred to as the Client Side Socket (CSS).

  4. At this point, the browser thinks the connection to the site is up and functional, and it sends the HTTP GET request.

  5. The HTTP GET request is processed by the CSC module; that is, it is checked against the URL blocking/filtering/WRS settings. If the request is allowed, the CSC module begins to establish a connection to the web server at the site.

  6. The HTTP proxy engine sends a TCP SYN packet with a source IP address and source port that matches the original TCP SYN the client thinks it sent to the web server (as received on the CSS). The web server replies with a SYN ACK, and the HTTP proxy engine responds with an ACK. At this point, the server-side socket (SSS) is up.

  7. The HTTP proxy engine sends the client's HTTP GET to the web server and the web server replies with content.

  8. This content is scanned/checked. If it is clean, the content is forwarded back to the client.

  9. These same steps are repeated for any other web request from the client to any web server.

Note that the client browser never really connects to the site; it connects to the CSC module which pretends to be the site as illustrated in this image:


Related Information

Updated: Jan 11, 2013
Document ID: 115747