Table Of Contents
Proxy-Style Caching
Proxy Mode Operation
HTTP Proxy Caching
HTTP Transparent and Proxy Caching
FTP Proxy Caching
Examples
SSL Tunneling
HTTPS Proxy Features
Examples
Proxy-Style Caching
This chapter explains nontransparent, or proxy-style, caching and presents configuration examples relevant to proxy-style caching with the Content Engine. This chapter contains the following sections:
•
Proxy Mode Operation
•
HTTP Proxy Caching
•
HTTP Transparent and Proxy Caching
•
FTP Proxy Caching
•
SSL Tunneling
All of the features outlined in this chapter are associated with Content Engines operating in nontransparent mode. In this mode, end user web browsers need to be explicitly configured to the IP address or host name of the Cisco Content Engine, and there is no need for additional hardware such as Layer 4 switches or WCCP-enabled routers to intercept user requests, as in transparent caching. Customers are normally interested in deploying transparent network caching, but some customers may have a legacy requirement for a nontransparent cache. For more information on transparent caching configurations with the Content Engine, see "Streaming Media Overview."
Proxy Mode Operation
A proxy-style request arrives with the same destination IP address as the Content Engine; it has been specifically routed to the Content Engine by the client. The Content Engine supports up to eight incoming ports each for FTP, HTTPS, HTTP, MMS, and RTSP proxy modes. The incoming proxy ports can be the same ports that are used by transparent mode services. The incoming proxy ports can be changed without stopping any WCCP services running on the Content Engine or on other Content Engines in the farm.
In proxy mode, the Content Engine services any protocols for which it has been configured. The supported protocols are HTTP, HTTPS, FTP, MMS, and RTSP. If the Content Engine is not configured to support a received protocol, the proxy server returns an error. For example, if port 8080 is configured to run an HTTP and HTTPS proxy service, an FTP request coming to this port is rejected.
TCP ports reserved for system or network services should not be used for proxying services in transparent mode or in proxy mode (for example, DNS or FTP). If more than eight ports for a protocol are required, the administrator can configure multiple dynamic WCCP services. Intercepted FTP, HTTP, and HTTPS requests addressed to other proxy servers (received on transparent mode ports) are serviced according to the proxy-protocols transparent command parameters.
HTTP Proxy Caching
The Content Engine accepts proxy-style requests in nontransparent mode from a web browser when the incoming proxy ports are configured with the http proxy incoming ports option. Up to eight incoming proxy ports can be specified on a single command line or on multiple command lines.
To configure the Content Engine to direct all HTTP miss traffic to a parent cache (without using ICP or WCCP), use the http proxy outgoing host ip-address port primary option, where host is the system name or IP address of the outgoing proxy server, and port is the port number designated by the outgoing (upstream) server to accept proxy requests. Use the primary option to set this host as the primary proxy. See the "Configuring Primary Proxy Failover" section for more information on the http proxy outgoing command.
HTTP Transparent and Proxy Caching
Certain scenarios involve the deployment of a Content Engine in proxy mode at company headquarters and a Content Engine in transparent mode at remote locations in branch offices. In these scenarios, if a cache miss occurs at the remote Content Engine, company policy requires that the request be routed to the Content Engine at headquarters.
When an HTTP request intended for the Content Engine acting as a proxy server is intercepted by the Content Engine in transparent mode at the remote location and a cache miss occurs, the Content Engine forwards the request to the intended proxy server if the proxy-protocols transparent original-proxy command was entered. If this command was not entered, then the Content Engine forwards the request to the origin server where the initial HTTP request was made. See the "Handling Proxy-Style Requests" section for information on how to use this command.
FTP Proxy Caching
FTP proxy caching in a Content Engine refers to the ability to service FTP-over-HTTP requests. The transport between the web browser and cache is over HTTP, and the cache initiates an FTP transfer to the origin FTP server.
Note
The Content Engine caches FTP traffic only when the client uses the Content Engine as a proxy server for FTP requests. All FTP traffic that was sent directly from the web client to an FTP server, if transparently intercepted by the Content Engine, is treated as non-HTTP traffic. If a web browser is not explicitly configured for a proxy, then the browser will initiate an end-to-end FTP connection itself, and this will not be intercepted by the Content Engine.
The ftp proxy command enables the Content Engine to operate in environments where WCCP is not enabled, or where client browsers have previously been configured to use a legacy FTP proxy server.
The ftp proxy incoming port option specifies a port number used by the proxy server to receive requests. This number can range from 1 to 65535. A maximum of eight incoming proxy ports can be configured. You can share these incoming proxy ports with transparent-mode services and also with the other proxy-mode protocols supported by the Content Engine, such as HTTP and HTTPS. The ftp proxy incoming port option is disabled by default.
Note
The Content Engine accepts and services FTP requests only on the ports configured for an FTP proxy. All the FTP requests on other proxy mode ports are rejected in accordance with the error-handling settings on the Content Engine.
The Content Engine accepts FTP requests when URLs specify the FTP protocol (for example, GET ftp://ftp.cisco.com/pub/cao/READM). For these requests, the client uses HTTP as the transport protocol with the Content Engine, whereas the Content Engine uses FTP with the FTP server.
The Content Engine caches both the FTP file objects and directory listings in the cache file system (cfs). The Content Engine transforms the regular directory listings from the FTP server into HTML, with links that the client users can point to and click to download files.
When the Content Engine receives an FTP request from the web client, it first looks in its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server (if one is configured), or directly from the origin FTP server.
The FTP proxy supports anonymous as well as authenticated FTP requests. Only base64 encoding is supported for authentication. The FTP proxy accepts all FTP URL schemes defined in RFC 1738. In the case of a URL in the form ftp://user@site/dir/file, the proxy sends back an authentication failure reply and the browser supplies a popup window for the user to enter login information.
The Content Engine can apply the Rules Template to FTP requests based on server name, domain name, server IP address and port, client IP address, and URL.
The Content Engine logs FTP transactions in the transaction log, in accordance with Squid syntax.
Examples
This example configures an incoming FTP proxy on ports 8080, 8081, and 9090. Up to eight incoming proxy ports can be configured on the same command line.
ContentEngine(config)# ftp proxy incoming 8080 8081 9090
This example removes one FTP proxy port from the list entered in the previous example. Ports 8080 and 9090 remain FTP proxy ports.
ContentEngine(config)# no ftp proxy incoming 8081
This example disables all the FTP proxy ports.
ContentEngine(config)# no ftp proxy incoming
This example configures an upstream FTP proxy with the IP address 172.31.76.76 on port 8888.
ContentEngine(config)# ftp proxy outgoing host 172.31.76.76 8888
This example specifies an anonymous password string for the Content Engine to use when contacting FTP servers. The default password string is anonymous@hostname.
ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostname
This example configures the maximum size in kilobytes of an FTP object that the Content Engine will cache. By default, the maximum size of a cacheable object is not limited.
ContentEngine(config)# ftp object max-size 15000
This example forces the Content Engine to revalidate all objects for every FTP request.
ContentEngine(config)# ftp reval-each-request all
This example configures a maximum Time To Live of 3 days in cache for directory listing objects and file objects.
ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3
SSL Tunneling
The SSL tunneling protocol allows a proxy server to act as a tunnel between the end user and the origin server. The client asks for an SSL tunnel through an HTTP request. This allows the Content Engine to service CONNECT method requests in the form https://url for tunneling SSL over HTTP.
Note
Browsers only initiate HTTPS-over-HTTP requests when explicitly configured for a proxy. If a web browser is not explicitly configured for a proxy, then the browser will initiate an HTTP-over-SSL connection itself, and because this is on TCP port 443, it will not be intercepted by a Content Engine. Even if a Content Engine did intercept this request, it would not be able to do anything with it. SSL on port 443 uses end-to-end encryption and any transparent device in the middle will not see anything more than a stream of random bytes.
HTTPS Proxy Features
Cisco ACNS 4.2 software supports HTTPS in the following two scenarios:
•
The Content Engine receives an HTTPS request sent by a web client configured to use the Content Engine as an HTTPS proxy server.
•
The Content Engine in transparent mode intercepts a request sent by a web client to another HTTPS proxy server.
In both cases the Content Engine creates a connection to the origin server (directly or through another proxy server) and allows the web client and origin server to set up an SSL tunnel through the Content Engine.
Table 6-1 shows CLI commands associated with HTTPS proxy features. The order in which the CLI commands are entered is not important.
Table 6-1 HTTPS Proxy Features
HTTPS Proxy Features
|
Related CLI Commands (Abbreviated Syntax)
|
Supports up to eight incoming proxy ports.
|
https proxy incoming ports 1-65535, port, . . .
|
Configures a WCCP service and an HTTPS incoming proxy on the same port. Shares proxy port with transparent services.
|
https proxy incoming ports 1-65535 wccp custom-web-cache . . .
|
Denies unwanted access to any destination HTTPS port.
|
no https destination-port allow 443 563 https destination-port deny all
|
Configures outgoing HTTPS proxy server, using global exclude option for HTTPS proxy.
|
proxy-protocols outgoing-proxy exclude list word https proxy outgoing host {hostname | ipaddress} ports 1-65535
|
Uses default outgoing HTTPS proxy, if configured.
|
proxy-protocols transparent default-server
|
Uses outgoing HTTPS proxy server from an original request.
|
proxy-protocols transparent original-proxy
|
Returns the incoming HTTPS request to the sending client during a cache miss.
|
proxy-protocols transparent reset
|
HTTPS traffic is encrypted and cannot be interpreted by the Content Engine or any other device between the web client and the origin server. HTTPS objects are not cached.
The Content Engine as an HTTPS proxy server supports up to eight ports. It can share the ports with transparent-mode services and with HTTP. In proxy mode, the Content Engine accepts and services the HTTPS requests on the ports specified with the https proxy incoming command. All HTTPS requests on other proxy-mode ports are rejected in accordance with the error-handling settings on the
Content Engine. In transparent mode, all HTTPS proxy-style requests intended for another HTTPS proxy server are accepted. The Content Engine acts on these transparently received requests in accordance with the proxy-protocols transparent command.
When the Content Engine is configured to use an HTTPS outgoing proxy with the https proxy outgoing host command, all incoming HTTPS requests are directed to this outgoing proxy. The proxy-protocols outgoing-proxy exclude command specifies a global proxy exclude domain effective for all proxy server protocols, including HTTPS. The Content Engine applies the following logic when an outgoing proxy server is configured:
•
If the destination server is specified by the global exclude option, then go directly to the destination server.
•
If the destination server is not specified by the global exclude option and the request is HTTP, go directly to the destination server.
•
If the destination server is not specified by the global exclude option, then go to the outgoing proxy server.
When a Content Engine intercepts a proxy request intended for another proxy server and there is no outgoing proxy configured for HTTPS, and the proxy-protocols transparent default-server command is invoked, the Content Engine addresses the request to the destination server directly and not to the client's intended proxy server. However, if the proxy-protocols transparent reset command is configured on the Content Engine and a cache miss occurs, all transparently intercepted requests sent by clients are returned to the client, and requested objects are not delivered.
Content Engine Security
To prevent unwanted access to any destination HTTPS port when a request is going through the Content Engine, use the following command sequence:
no https destination-port allow 443 563
https destination-port deny all
This command sequence denies access to any port, above and below 1024. Ports 443 and 563 must be explicitly denied access using the no https destination-port allow 443 563 command.
Note
TCP and UDP packets use port numbers defined by the application in use. Typically, the port range 0-255 is used for standard public applications, and the port range 256-1023 is used by companies for nonstandard applications. For instance, FTP uses port 21, and Telnet uses port 23. Port numbers from 1024 to 65,536 are unregulated, so it is best to specifically deny access through any port number.
For example, when these commands are configured on the Content Engine and the request to port xxx at banking.wellsfargo.com is redirected to this Content Engine, the connection to port xxx at banking.wellsfargo.com is denied. This configuration is valid in either the transparent deployment scenario, where requests are redirected to the Content Engine, or in HTTPS proxy server mode, where the user makes the requests directly to the Content Engine.
Statistics Reporting
Only connection statistics are reported. Because requests and responses are sent through the secure tunnel, the Content Engine is not able to identify the number of requests sent, or the number of bytes per request. Thus, the request and transaction per second (TPS) statistics are not available for HTTPS.
Transaction Logging
The Content Engine logs HTTPS transactions in the transaction log in accordance with Squid syntax. One log entry is made for each HTTPS connection, though many transactions are performed per connection. The Content Engine is not aware of objects conveyed through the SSL tunnel, only the HTTPS server name.
Examples
In this example, the Content Engine is configured as an HTTPS proxy server, and accepts HTTPS requests on port 8081. Only a single port is supported in the HTTPS protocol.
ContentEngine(config)# https proxy incoming 8081
In this example, the Content Engine is configured to forward HTTPS requests to an outgoing proxy server (10.1.1.1) on port 8880.
ContentEngine(config)# https proxy outgoing host 10.1.1.1 8880
In this example, a domain name is excluded from being forwarded to an outgoing proxy server.
ContentEngine(config)# proxy-protocols outgoing-proxy exclude cruzio.com
ContentEngine(config)# proxy-protocols transparent default-server