This document describes how the Cisco ASA Content Security and Control
(CSC) Security Services Module can act as a proxy server for HTTP
Technical Tips Conventions for information on document
How does the ASA CSC Security Services Module act as a proxy for HTTP
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):
When a user tries to connect to a site, their browser sends a SYN
packet to the IP address of that site.
The CSC module, which acts as a proxy, intercepts the SYN packet and
replies with a SYN-ACK on behalf of the site.
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
At this point, the browser thinks the connection to the site is up
and functional, and it sends the HTTP GET request.
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 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.
The HTTP proxy engine sends the client's HTTP GET to the web server
and the web server replies with content.
This content is scanned/checked. If it is clean, the content is
forwarded back to the client.
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