BCCPP Student v341 Us WMK PDF

1[dT2^Pc2TacXUXTS
?a^ghB6?a^UTbbX^]P[2^dabT
ETabX^]"#
BcdST]cCTgcQ^^Z
Property of Blue Touch Training Services.

NOT for Distribution. For Internal Reference Purposes Only.
BlueTouch Training Services BCCPP Course v3.4.1
Contact Information
Blue Coat Systems Inc.
410 North Mary Avenue
Sunnyvale, California 94085
North America (USA) Toll Free: +1.866.302.2628 (866.30.BCOAT)
North America Direct (USA): +1.408.220.2200
Asia Pacific Rim (Hong Kong): +852.2166.8121
Europe, Middle East, and Africa (United Kingdom): +44 (0) 1276 854 100
training@bluecoat.com
training.books@bluecoat.com
www.bluecoat.com
Copyright 1999-2010 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be
reproduced by any means nor modified, decompiled, disassembled, published or distributed, in whole or in part, or
translated to any electronic medium or other means without the written consent of Blue Coat Systems, Inc. All right, title
and interest in and to the Software and documentation are and shall remain the exclusive property of Blue Coat Systems,
Inc. and its licensors. BluePlanet, CacheFlow, CachePulse, DRTR, ProxyAV, ProxyClient, ProxyRA
Connector, ProxyRA Manager, SGOS, and WebPulse are trademarks of Blue Coat Systems, Inc. Blue Coat,
BlueSource, BlueTouch, Control Is Yours, K9, IntelligenceCenter, PacketShaper, ProxySG, Permeo, the
Permeo logo, and the Blue Coat logo are registered trademarks of Blue Coat Systems, Inc. All other trademarks contained
in this document and in the Software are the property of their respective owners.
BLUE COAT SYSTEMS, INC. DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR
IMPLIED, STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER
INCLUDING WITHOUT LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL BLUE COAT SYSTEMS, INC., ITS
SUPPLIERS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR
ANY OTHER LEGAL THEORY EVEN IF BLUE COAT SYSTEMS, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
April 2010
ii
Property
of Blue Touch Training Services.
Table of Contents
Course Introduction .....................................................................................1

Chapter 1: System Architecture................................................................... 3
Chapter 2: Caching Architecture ...............................................................15
Chapter 3: Services Advanced Topics ..................................................33
Chapter 4: Content Policy Language .........................................................49
Chapter 5: Regular Expressions................................................................ 77
Chapter 6: Managing Downloads and Apparent Data Types .................... 91
Chapter 7: HTTP Details ........................................................................... 99
Chapter 8: Authentication In Transparent Proxy Mode............................ 111
Chapter 9: Using Kerberos Authentication ..............................................125
Chapter 10: Advanced Authentication .....................................................135
Chapter 11: Guest Authentication ...........................................................149
Chapter 12: SSL Proxy ............................................................................ 161
Chapter 13: Policy Tracing ......................................................................173
Chapter 14: Forwarding ........................................................................... 183
Chapter 15: Reverse Proxy Implementation............................................ 191
Chapter 16: Two-way URL Rewrite .........................................................199
Chapter 17: Failover ................................................................................ 209
iii
Chapter 18: Health Checks ..................................................................... 217

Chapter 19: Web Cache Communication Protocol .................................. 229
Chapter 20: VLAN Support ...................................................................... 239
Chapter 21: Managing Streaming Media ................................................. 249
Chapter 22: ProxyClient Concepts .......................................................... 259
Chapter 23: ProxyClient Filtering ............................................................ 269
Chapter 24: Introduction to ProxyAV ....................................................... 281
Chapter 25: ICAP Concepts .................................................................... 289
Chapter 26: Introduction to Director ........................................................ 309
Appendix A: Understanding Digital Certificates ....................................... 317
Appendix B: Understanding Kerberos Authentication ............................. 325
iv
Property
Course Introduction
The Blue Coat Certified ProxySG Professional course is intended for students who wish to master
the advanced features of the Blue Coat ProxySG. It is designed for students who have taken the
Blue Coat Certified ProxySG Administrator (BCCPA) course or passed the entrance exam.
Students should have practical experience with the ProxySG in the field. Additionally, students
should have advanced knowledge of networking, security, and authentication.
After studying this course, you will understand:
The architecture of the ProxySG.
How to use Content Policy Language and trace policy execution.
Authentication realms and how to configure them on the ProxySG.
How to use the ProxySG for forwarding and failover.
Streaming media and bandwidth management.
How the ProxySG works with the ProxyAV to perform anti-virus scanning.
How Blue Coat Director can be used to manage multiple ProxySG appliances.
By completing this course and passing an online exam, you can become a Blue Coat Certified
Proxy Professional.
Applicable Software Versions

This course is based on version 5.5.1 of the SGOS operating system that is used on the ProxySG.
If your enterprise uses an earlier version of SGOS, some features described in this course might
not work as described here, and the appearance and functionality of screens, menus, commands,
and displays might be different from what you see here.
Typographic Conventions
In this book, text appearing in this font generally is text that is part of a graphical user
interface. This includes text in labels, names of buttons and menus, and Web page addresses
that you type into a Web browser.
Text appearing in this font generally is text that is part of a command-line interface. This
includes prompts, user input, and responses. This font also is used to show the content of
some communication protocols, such as headers, commands, and data between a client and a
server.
In both cases, text that appears in italics like this or like this represents text that you should
replace with text specific to your deployment. For example, the URL https://proxyIPaddr:8082
appears often in this book. In this example, the text proxyIPaddr should be replaced with the
actual four-octet numeric IP address of your ProxySG.
1
2
Property
Chapter 1: System Architecture
The architecture of the Blue Coat ProxySG is complex and evolves continually to support new
and better features. This chapter discusses, at a high level, the details of how the ProxySG:
Handles transactions.
Analyzes and processes policy.
Caches content.
Some details are not discussed in this course because they are proprietary and confidential to Blue
Coat Systems.
The SGOS operating system contains no general-purpose code, and it does not reuse code from
other systems. The operating system has been built from the ground up specifically to improve
proxy caching and Web applications. As a result, Blue Coat products have emerged as the
preferred foundation for enterprise proxy caching applications. This chapter provides a high-level
overview of core SGOS technologies, specifically those designed to improve the Internet user
experience.
After studying this chapter, you will understand:
The basic software architecture of the ProxySG.
How the ProxySG evaluates policy. This is an important prerequisite to understanding policy
tracing, an essential troubleshooting tool that is described in detail later in this course.
The fundamentals of the ProxySG storage subsystem, and how it differs from that of
traditional operating systems.
How ProxySG hardware sizing can affect performance.
3
System Architecture
Software workers
Manage connection to external resources
Policy checkpoints
Control access to those resources
Storage subsystem
Designed for high-performance caching
Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.
6OLGH(OHPHQWVRIV\VWHPDUFKLWHFWXUH
When the ProxySG receives a connection request, it manages this connection by creating a client
worker and then, if necessary, a server worker. These are processes within the operating system
that manage the incoming and outgoing transactions.
At each stage of the transaction, the ProxySG has some amount of information that can be
matched against the running policy. These points in the transaction process are known as policy
checkpoints.
The ProxySG needs to decide whether the transaction request must be fulfilled from cache or from
the Internet, or whether the request should be denied. The ProxySG uses a series of advanced
algorithms to make this determination. Finally, to maximize performance, the ProxySG can
retrieve a large number of objects concurrently from the Internet by pipelining a large (and
definable) number of TCP connections. (Caching and pipelining are discussed in detail in the
Caching Architecture chapter of this course.)
The combination and integration of these elements gives you a solid understanding of the internal
system architecture for ProxySG.
4
Property
Software Workers
Client Worker (CW)
Maintains HTTP sessions between ProxySG, clients
Server Worker (SW )
Maintains HTTP sessions between ProxySG, OCS
Retrieval Worker (RW)
Keeps contents of cache fresh
Specialized Worker
Handles specific protocol, such as IM or streaming
6OLGH0DLQVRIWZDUHZRUNHUV
The three main workers that are discussed in this book are the client worker, server worker, and
retrieval worker. There are several other workers that the ProxySG uses to manage the complex
tasks it is capable of. You can imagine that there are client and server workers dedicated for each
of the protocols that the ProxySG can understand.
At every major new release, Blue Coat plans to add new and more specialized workers to the list
available to SGOS. The functionalities covered by each worker and their interconnections may also
change.
Full discussion of all of the workers is beyond the scope of this course.
5
Software Workers
6OLGH6RIWZDUHZRUNHUVPRGHO
This diagram shows the main workers that SGOS implements to manage HTTP transactions. Read
the diagram from the left to the right.
When a client makes an HTTP connection to the ProxySG, SGOS assigns a worker to manage that
transaction. That worker is called a client worker (CW). The client worker is responsible for all
aspects of communication at the HTTP level with the client. Note that one client may open a
number of simultaneous connections and, therefore, may cause the operating system to initiate a
corresponding number of CWs. The CW is the entry point into the ProxySG.
The CW determines the destination of the HTTP request and whether it is a cacheable protocol
request. For instance, if the request is an HTTP request, the CW communicates with the cache
administrator (CA) to determine whether the content for that transaction is available in the local
cache. As far as the CW is concerned, all of the content comes from cache. It is the CA that
determines if the object is available in cache; if not, the worker must decide whether to obtain it
from the OCS. HTTP protocol client workers use a server worker to obtain the content regardless
of whether that content should be cached.
When the content is not available in cache, the CW causes SGOS to initiate a server worker (SW).
The purpose of the SW is to create and maintain the session with the OCS. The SW retrieves the
requested content and makes it available to the CA.
The protocol-specific administrator can initiate a worker autonomously to keep the content of the
cache fresh. This worker is called a retrieval worker (RW). The effect of the RW is visible when you
have the ProxySG establishing connections to the Internet, even when clients are not making
requests.
6
Property
Policy Checkpoints
Checkpoints are present in multiple parts of the
transaction processing
Policy rules are evaluated at checkpoints
Triggers must be evaluated at a checkpoint before their
associated actions can be taken
Error messages flag late conditions and prevent
compilation
6OLGH3ROLF\FKHFNSRLQWV
The evaluation of the running policy is performed at various points in the ProxySG. At each point
in the evaluation process, some elements of the overall policy can be evaluated and a decision can
be made.
At each checkpoint, the running policy is evaluated, and properties for the transaction are set
based on the information available to the ProxySG at that moment in the processing flow. As the
transaction progresses toward another checkpoint, more information becomes available, and the
property of the transaction or the decision on how to handle the transaction may change.
The triggers and properties are designed so that the policy writer is shielded from the variations
among protocols wherever possible. This is done by making the systems timing requirements
accommodate all of the protocols. Where this is not possible (because using the most restrictive
timing causes significant loss of functionality for the other protocols), protocol-specific triggers
have been introduced. When evaluated against other protocols, these triggers return the not
applicable value or N/A.
This results in the rule being skipped (the expression evaluates to false, no matter what it is). It is
possible to explicitly guard such rules so that they are only evaluated against appropriate
transactions. The variation in trigger and property timings implies that within a policy rule, a
conflict is possible between a condition that can only be tested relatively late in the evaluation
sequence and a property that must be set relatively early in the evaluation sequence. Such a rule
results in a compile-time error.
For example, this rule would be incorrect for evaluating any transaction: If the user is in group
xyz, require authentication. The rule is incorrect because group membership can be determined
only after authentication. It is incorrect also because the rule tests group membership and specifies
the authentication realm, a property that must be set before the authentication challenge can be
issued. The following code illustrates this incorrect rule:
group=xyz authenticate(MyRealm)
The resulting message at compile time is:
7
Error: Late condition guards early action: authenticate(MyRealm)
However, it is correct for the authentication requirement to be conditional on the client address
(client.address=) or proxy port (proxy.port=) because they can be determined at the time
the client connection is established and therefore are available from the beginning of a proxy
transaction. For the HTTP protocol, authenticate() can be conditional on the URL (url=);
however, for MMS streaming, only the Host portion of the URL can be tested (url.host=).
A proxy transaction evaluates policy in Proxy, Cache, Forward, and Exception layers. The
Forward layers are evaluated only if the transaction reaches the stage of contacting an origin
server to satisfy the request. (This is not the case if the request is satisfied by data served from
cache, or if the transaction is terminated by an exception.) The Exception layers are evaluated only
if the transaction is terminated by an exception.
Each of the protocol-specific proxy transactions has specific information that can be tested
information that may not be available from or relevant to other protocols. HTTP headers and
instant messaging buddy names are two examples of protocol-specific information. Other key
differentiators among the proxy transaction subtypes are the order in which information becomes
available and when specific actions must be taken, as dictated by the individual protocols.
Variation inherent in the individual protocols determines timing, or the sequence of evaluations
that occurs as the transaction is processed.
Note:
The Proxy Layer is the CPL equivalent of the Web Authentication and Web Access
layers, the Cache Layer is the equivalent of the Web Content Layer; there is no
equivalent in VPM to the CPL Exception Layer.
8
Property
Policy Checkpoints
Blu e Co at Sy ste ms, Inc. 2 010. All Rig ht s Reserved.
6OLGH3ROLF\FKHFNSRLQWV
You can follow the transaction from the checkpoints angle, in a way similar to the one you used to
consider the different workers.
When the ProxySG receives a connection request, the client in (CI) checkpoint is reached. The
checkpoint occurs after the ProxySG identifies the request but before it attempts to fulfill any
portion of the request. During this checkpoint, if it is enabled, authentication takes place. A
decision on how to handle the transaction may be reached at this point and the transaction may
not need to reach any other checkpoint. (For instance, the authentication fails.)
If the transaction is able to progress past the CI checkpoint, the next evaluation occurs when the
request is about to be sent to the origin server. The checkpoint is evaluated for pipeline requests,
refresh requests, and cache misses. This checkpoint is the server out (SO) checkpoint.
After the response from the OCS is received, the transaction reaches the server in (SI) checkpoint.
At this point, the response is available for analysis by the policy-enforcement engine. For instance,
the SI checkpoint can determine if the Content-Encoding is acceptable by the policy.
The last checkpoint is client out (CO). This checkpoint is used in request/response-type
transactions. This checkpoint occurs after the response has been determined and is about to be
sent back to the client. For example, the result of response virus scanning is available here.
9
Storage Subsystem
6OLGH6WRUDJHVXEV\VWHP
The method of storing objects on disk is critical for achieving both high performance and high
scalability. It determines:
How quickly a cached object can be accessed when a client requests it.
How rapidly new objects can be acquired and stored on disk.
The rate at which client requests can be serviced per disk drive.
The SGOS object storage system is not a file system. It is an object cache. There is no directory in
the operating system. Object access is through a hash table in RAM, ensuring that any objects first
chunk of data the piece that is so critical to the experience of request latency can be obtained
in a single disk read. File systems run poorly when they are full; however, a cache achieves its
highest performance when it is full.
The disk stores objects from a portion of the URL namespace. Accesses are automatically balanced
among the available disks. The ProxySG normally runs with its disk full of objects. Old,
seldom-used objects are continually removed to make room for new incoming objects. The disk
layout and replacement algorithms in the operating system facilitate this process to optimize the
speed of writing new objects to disk.
In the unlikely event that a disk fails, the objects in its portion of the URL namespace are
automatically remapped to the remaining disks. New disks can be to an existing ProxySG while it
is running.
Also consider the following differences between a file system and an object store:
File systems typically organize files into a hierarchical structure. Related files are kept together
in directories, and these directories are arranged in a tree structure. Once you walk down the
tree to a specific place, it is reasonably efficient to access all of the related files. However, if you
are always accessing things using the full path name of the file, file systems can be very slow
because you have to keep traversing through all of the intermediate directories every time.
10
Property
Object stores store things differently, indexing all objects by their full path name. With an
object store, there is no way to efficiently list just the contents of a particular directory.
However, when accessing files using their full path name, an object store can very quickly get
to any file. When doing something like HTTP object caching, each request always refers to a
full path name, so it is much more efficient to use the object store approach for accessing the
cached data.
File systems typically keep files until they are explicitly deleted. This is generally what you
want when you manage the files yourself, but it can be a problem on a cache because
eventually the cache fills all available disk space. Instead of requiring the administrator to
manually clean old files, the ProxySG object store is self-managing. It keeps track of the last
access time, popularity, and cost to reacquire the content currently stored in the cache and
automatically chooses to delete the content that is least useful in order to make room for new
content. This allows the ProxySG to always hold as much data as possible in the cache, always
keeping the content that is most useful based on past access patterns.
11
ProxySG Performance
SG210-5
SG510-5
SG810-5
SG9000-5
SG9000-20
M emory
512 MB
2 GB
2 GB
4 GB
16 GB
Disk size
80 GB
2x80 GB
2x73 GB
4x500 GB
10x500 GB
Cache
object
lim it
(approx.)
2.3 million
4.6 million
4.6 m illion
9.2 m illion
22.9 m illion
200
2,500
7,500
16,000
M ax
active
desktops
(recomm ended) 30
6OLGH3UR[\6*SHUIRUPDQFH
This table is a reference guide to sizing ProxySG hardware and understanding under what
conditions a ProxySG can enter overload conditions.
The maximum amount of RAM available in a ProxySG controls the maximum number of objects
that can be stored in the object store (cache).
The maximum amount of disk space available also determines the maximum number of objects
that can be stored in the object store. Object limits control how many items can be stored; however,
the space occupied by the objects cannot exceed the maximum allocated space for the object store.
Protocols such as HTTP, which manage large number of small objects, are more likely to run into
the maximum object limit rather than the disk space limit. Protocols such as streaming media are
more likely to run in to the maximum amount of available disk space as a limit.
Important: The object limit is the maximum number of objects that can be stored in the object
store across all cacheable protocols. It is not a per-protocol limit.
The ProxySG uses a RAM hash table to reference all objects on each disk. The number of objects is
proportional to the amount of RAM available and not necessarily the amount of disk space. The
maximum number of cacheable objects is a combination of the physical space available between
memory and disks and the number of addressable objects.
The size of the hash table limits the total number of objects that can be stored. You can compare the
hash table to a large index. A cacheable object is placed in the object store, and its location is
recorded in the hash table stored in RAM. When the system needs to access (retrieve or refresh)
the object, it looks up the objects location in the RAM hash table. A RAM hash table is somewhat
similar in theory to the FAT table on Windows-based systems; however, the ProxySG has an object
store, not have a FAT or NTFS file system.
12
Property
Not all RAM is allocated to the hash table. A small part is used by SGOS, and the rest is primarily
used to manage TCP connections and cache objects. Using the threshold monitor, the ProxySG
monitors several operational parameters; one of these parameters is called memory pressure. The
memory pressure condition is defined when the committed (allocated) RAM exceeds 95%. The
memory pressure state is abandoned after committed RAM drops below 90%.
During memory pressure situations:
New client connections are delayed.
TCP/IP sockets for all proxies stop accepting new requests.
The HTTP proxy begins to shut down idle persistent connections.
Management services (SSH, Telnet, HTTP-Console, and HTTPS-GUI) do not change behavior.
The HTTP proxy also adheres to a maximum active client connections count that is set per
platform. When the maximum number of active clients is reached, the idle persistent connections
also begin to be shut down. The maximum active HTTP client count supersedes the threshold
monitor.
The recommended maximum number of active desktops is the total number of desktops using the
ProxySG for Internet connectivity in a forward-proxy deployment. The number is based on the
common assumption that 100% of desktops have open Web connections at any moment, though
up to 80% are used for background tasks.
Note:
This description should be used only as a high-level guide to understanding sizing.

You should always discuss specifics of your deployment with a qualified Blue Coat
systems engineer.
13
14
Property
Chapter 2: Caching Architecture
As more users browse the Web, network connections tend to get congested and slow the process of
Web page retrieval. Web caching is a solution that can help accelerate the process of data delivery
to clients while effectively reducing response time and bandwidth usage for further requests.
In simple words, a Web cache is a dedicated appliance that is present between a Web server and a
client and monitors requests made by the client for Web pages, files, and images, collectively
called objects. When the objects are sent to the client for the first time, the cache saves a copy in its
memory. Web caches are almost always proxy servers that intercept client requests and also, based
on their configuration, monitor a clients Web browsing activities.
Caching serves three important purposes:
Reduces latency: By saving previously requested content locally on the proxy, the cache
reduces the response time for subsequent requests because the request does not have to be
sent to the origin content server (OCS). This offers the clients a better experience and speeds
up the loading of regularly accessed Web pages.
Provides effective bandwidth management: Because the cache serves client requests without
having to contact the OCS, it results in effective utilization of available bandwidth, preventing
jammed networks.
Prevents a high load on the server: By offering requested objects immediately to the client,
caching avoids too many requests being sent to the server, thus keeping the server free of
unnecessary load.
Caches serve hundreds of users on a large scale and are suitable for enterprises that want to make
the maximum use of their Internet bandwidth. They work better in large organizations because
there tends to be a higher number of users requesting the same content over a period of time.
Caches have to maintain a fresh stock of requested content to offer to users. Because Web content is
dynamic and changes frequently, caches have to determine the freshness of their version of an
object before sending it to clients. If the content is stale, the cache checks the freshness of the object
with the OCS. The availability of fresh content to users determines the hit and miss rate of a cache.
This chapter discusses the concepts behind caching and how it is implemented on the Blue Coat
ProxySG.
15
Understanding Caching
HTTP protocol
Request and response headers with cache directives
Object types
Browser behavior
Caching devices
Caching techniques
Pipelining and pre-fetching requests
6OLGH8QGHUVWDQGLQJFDFKLQJ
Caching is useful on the Web because it improves performance considerably by speeding up

information transfer to clients. The HTTP protocol contains many elements that are designed to
make caching work in the best possible way. The main objective of caching in HTTP is to do away
with the need to send repeated requests to servers for content; this reduces the number of
round-trips that might be required. Another important goal of caching is to eliminate the need to
send full responses; in many cases, this economizes the use of network bandwidth.
Cache directives in HTTP headers are used to specify directives that are followed by all caching
mechanisms. They contain information that limits caches from interrupting requests and
responses. These cache directives also override default caching algorithms. There are separate
directives for request and response headers, and it cannot be implied that the same directive is to
be used for both requests and responses.
All cache directives pass through a proxy or a secure gateway to be valid. Unless there is a
restraining cache directive, a caching system can store a successful response for itself.
Caching devices can be positioned at different points on a network to carry out different tasks. A
proxy cache can be useful on intranet networks where browsers are configured to send client
requests to the cache instead of to the origin content server. Transparent caches are positioned near
the WAN to examine packets that are sent on the Internet. If the requested object has a match in
the cache, it is retrieved from the cache and sent to the user. A reverse proxy cache offloads client
requests from the Web server, which can allow surge protection when many requests are sent to a
server.
The ProxySG uses different caching techniques to maintain the freshness of its cache. Adaptive
refresh, cost-based deletion, and popularity contest are some of the methods that the ProxySG uses
to check cache data. The adaptive refresh method checks whether objects are still valid by verifying
their timestamp. The cost-based deletion technique checks and discards data that can be obtained
quickly and uses low bandwidth to download. It analyzes the bandwidth usage and the speed of
the link download as well as the popularity of the data to maintain the cache. The popularity contest
method checks and maintains data that is popular and requested frequently. These methods are
discussed in detail in this chapter.
16
Property
A cache also pipelines and pre-fetches requests. This means that when a client requests an object
that references other objects, the cache retrieves the referenced objects even before they are
specifically requested. This speeds the data transfer process. Pipelining enables the browser to
load pages and also retrieve objects simultaneously so that objects are ready before the client asks
for them. Essentially, this means that transfer of the second object begins before the transfer of the
first object is complete so that the second object is available to the user as soon as it is requested.
17
HTTP Headers for Caching
6OLGH+773KHDGHUVUHOHYDQWIRUFDFKLQJ
HTTP headers help determine information about the freshness of objects and about various cache
directives that are written for the requested objects.
The If-Modified-Since header in the HTTP protocol is sent by a browser to the Web
server to determine whether the requested page has been modified since its last visit. If the
requested object has not been modified since its last retrieval, the server responds with a 304
Not Modified status code without any message body. If modified, the 200 OK code is sent
back to the browser. If the object has not been changed, the cache can keep its saved copy for
the client. If the object has been changed, the cache can then update its copy of the object with
new one and send the updated version to the client on future requests.
The Pragma field in HTTP headers is used to include implementation-specific directives that
might apply to any recipient along the request/response chain. This information points out
optional behavior from the HTTP protocol view, but some systems might require that
behavior be consistent with the directives. When the Pragma: no-cache directive is present
in the header, the cache sends the object request to the OCS even if the object is present in the
cache. The Pragma: no-cache directive has the same semantics as the Cache-Control:
no-cache directive in a response and is used for backward compatibility with HTTP/1.0.
The Cache-Control header is used both in requests and responses. It indicates directives
that have to be followed by all caching devices in the HTTP transaction in order to prevent the
cache from causing conflict in the transaction. The Cache-Control header has different
directives for requests and responses.
Cache-Control directives used in HTTP requests include:
no-cache: This directive instructs the cache to request an object from the OCS even if the
object is present in the cache. This has the same semantics as the Pragma: no-cache
field. Usually, both fields are sent to a server not known to be HTTP/1.1 compliant.
max-stale: This directive tells the cache that the client is accepting stale content expired
by not more than the specified number of seconds assigned in the value. If there is no
attached value, it means that the client will accept a stale response from any time.
18
Property
max-age: This directive indicates to the cache that the client is accepting only those
responses whose age is not more than the specified number of seconds. If there is no
attached value, it means that the client will not accept any stale responses.
min-fresh: This directive indicates that the client is willing to accept a response whose
freshness lifetime is no less than its current age plus the specified time in seconds. That is,
the client wants a response that will still be fresh for at least the specified number of
seconds.
Note:
Some directives, such as no-cache and max-age, are also used in HTTP response
headers but with a different purpose, which is not described here.
Cache-Control directives used in HTTP responses include:
must-revalidate: A cache might not validate a requested object if it is set up to

overlook a servers designated expiration time or if the client request contains the
max-stale directive. To prevent this, the request should contain a Cache-Control:
must-revalidate field in the header so that the cache is forced to validate its copy of
the object every time.
proxy-revalidate: This directive is similar to must-revalidate except that it is not

applicable to non-shared user agent caches. You can use this directive to allow the cache to
retrieve data without revalidating it for a single user. In cases where there are proxies that
assist more than one user, the cache can be configured to revalidate the data every time it
is requested.
The Last-Modified response header indicates the date and time at which the OCS believes
the object was last modified. The exact meaning of this field depends on the implementation
of the OCS and the nature of the original resource. For files, it might be just the file system
last-modified time; for entities with dynamically included parts, it might be the most recent of
the set of last-modify times for its component parts; for database gateways, it might be the
last-update time stamp of the record, and so on.
19
HTTP Object Types
6OLGH7\SHVRI+773REMHFWV
The ProxySG groups objects into three categories based on the level of freshness information they
provide.
Type T: The origin content server provides this type of objects explicit expiration time or time
to live (TTL).
Type M: This is the most common object type. Though the OCS does not provide the
expiration time, it specifies the date and time the object was last modified.
Type N: The OCS indicates that there is no timestamp or information about modification and
expiration available for this object type.
The ProxySG uses the Asynchronous Adaptive Refresh algorithm to determine when to refresh
the object to store in the cache. The popularity of the object and its expiration time are taken into
account to determine when to refresh the object.
For Type T objects, the ProxySG can rely on the TTL information received from the OCS. For Type
M objects, it uses the conditional Get-If-Modified-Since request to determine when to fetch
content. If the OCS returns a 304 status code, the cache does not modify the content. If a 200 code is
sent, then the cache updates its copy of the object with the latest one.
For Type N objects with no modification or expiration information available, the ProxySG uses a
proprietary algorithm to determine when to fetch such objects so that they are available when
requested by clients.
20
Property
Browser Behaviors
6OLGH%URZVHUEHKDYLRUV
A Web browser has its own cache where it stores pages that are accessed frequently. When a client
requests information, the browser might send stale objects from its own cache. The ProxySG plays
no role during this transaction.
But when the request is sent through the ProxySG, the appliance checks objects for their validity. If
the object is present and does not have conditions that restrict it from being sent to the user, the
appliance forwards it from the ProxySG cache to the client.
The Accept */* field in the header of the GET request means that the client is accepting all
kinds of objects. If there is a specific type listed in the field, then only objects of that type are
accepted. Some versions of Microsoft Internet Explorer issue the Accept: */* header instead
of the Pragma: no-cache header when the user refreshes the page. The ProxySG can be
configured so that when an Accept header has only the */* value, the proxy treats it as a
Pragma: no-cache header if it is a Type N object (one that has no timestamp or expiration
information available).
You can use different profiles in the ProxySG to adjust the frequency of cache checking against the
origin content server. You also can substitute the headers that are sent in a request so that the cache
does not have to revalidate its copy.
You also can adjust settings in the ProxySG to ignore the Pragma: no-cache field in the header
and save a copy for itself. This field does not actually prevent caching; rather, it requires the proxy
to validate the object before sending it to the client.
21
Caching Strategies
Passive caching
Deterministic algorithm to decide when to refresh content in
cache
Prone to deliver stale content or refresh too frequently
Active caching
Statistical analysis on refresh interval
Popularity contest
6OLGH&DFKLQJVWUDWHJLHV
The main purpose of passive caching is bandwidth savings. All objects in the passive cache are
refreshed at intervals set by the cache administrator. An administrator can set a rule such as All
objects stored in the cache will expire and cannot be served after eight hours.
Passive caching is the most basic mode of caching. Objects in a passive cache are stored with a
time-to-live value. When a client makes a request for an object, the cache is checked first to
determine whether a copy of the object is present.
If the object is present and is not expired, it is sent to the client from the cache.
If the object is not cached, the object has to be retrieved from the origin content server and is
sent to the client. The cache also saves a copy for itself if it is allowed to.
If the object has expired (in other words, if it has exceeded its TTL value), the object might
need to be retrieved again from the OCS.
If the cache is full, less popular objects are removed and space is created for fresher data.
Active caches refresh the objects they contain in anticipation to users requests. This enables them
to serve fresher content compared to passive caches. The ProxySG uses the active caching method
to keep its content up to date. Intelligent algorithms in the ProxySG cache continuously evaluate
and analyze requests and compare it with the cache content. This helps in determining objects that
are likely to be requested frequently so that they are up to date in the cache.
Active caching can be done using the popularity contest method: Objects that are popular and
requested often are updated by the cache more frequently than the objects that are not requested
as often. This process usually is carried out when the cache is not busy. Active caching helps
distribute the server load evenly, accelerating delivery of content to clients and ensuring presence
of fresh content.
22
Property
Caching Steps
6OLGH&DFKLQJVWHSV
A cache has to constantly keep a lookout for the requests that are made by users. The above
diagram shows the steps that occur during an HTTP transaction when caching is enabled.
1.
The client sends a GET request to the ProxySG. In this example, the client has requested a
JPEG image from the Blue Coat Web site.
2.
The request is received by the ProxySG, the cache engine hashes it, and the location is
determined. This allows faster processing of the request.
3.
The ProxySG then checks for the requested object in its cache. If the object is present in the
cache and is unexpired, then the object is sent to the client immediately. This is known as a
cache hit. If the object is not present in the cache, then the request is sent to the origin content
server. This is known as a cache miss.
4.
After retrieving the object from the OCS, it is sent back to the client. On the way, depending on
the allowance of cacheability, the cache might save a copy for itself.
5.
The object is then sent to the client through the ProxySG.
If the object is present in the cache, then it has to be validated to ensure that it is fresh before
sending it to the client.
23
Cache Validation
6OLGH&DFKHYDOLGDWLRQ
Nearly every object that is present in the cache tends to have an expiration date that indicates
when it has to be discarded and a new copy obtained. Cache validation is very important if you do
not want your cache to serve stale content to users. This diagram explains the different steps in
cache validation.
1.
The client sends a request for an object. In this case, a request for a JPEG image is made from
the Blue Coat Web site.
2.
The ProxySG cache engine hashes the request and determines its location to make the
processing faster.
3.
Since we are assuming that the object is present in the cache and has to be validated, the
transaction is shown as a cache hit.
4.
The cache then sends information including a Get-If-Modified-Since request along with the
timestamp to inform the origin content server of the date and time of its copy.
5.
If the copy is not modified compared to the timestamp of the cache copy, the OCS sends a 304
Not Modified response to the cache. If the object is modified, the server sends a 200 OK
response along with the new version of the object. The cache also saves a copy of the new
version of the object, if allowed.
6.
The object is then sent to the user to complete the transaction.
24
Property
Asynchronous Adaptive Refresh
6OLGH$V\QFKURQRXV$GDSWLYH5HIUHVK
Information on the Internet is dynamic and keeps updating constantly. It is important for a cache
to keep its content fresh and up to date so that fresh data can be delivered to clients without delay.
If content is checked for updates only when the user requests it, the process causes slower delivery
of information and clogged networks.
The ProxySG prevents this from happening by using a proprietary algorithm called Asynchronous
Adaptive Refresh. This algorithm refreshes objects in the cache selectively based on their need to
be refreshed. The activity occurs in the background asynchronously, usually when there is not
much traffic on the network, so that response time during heavy traffic is unaffected.
Selecting what objects to refresh and when requires an understanding of object behaviors. Web
objects change at different rates. Some change frequently, some change rarely, and many have
change rates in between.
The Asynchronous Adaptive Refresh algorithm that the ProxySG uses is unique in the industry. It
develops a model of change and a model of use for every object that is stored in the cache based upon
the frequency of usage and number of requests made for the object. These two values are then
combined to determine a refresh pattern for every object so that it is fresh and available to the user
immediately when requested.
For example, in the above diagram, if the objects on www.cnn.com are frequently requested, then
the pattern determined for those objects is such that the ProxySG checks for fresh content and
updates for the objects more frequently than for objects on other Web sites that are not as popular.
Asynchronous Adaptive Refresh significantly speeds up subsequent requests by removing the
latency involved in refreshing the objects only when requested. Object pipelining uses a similar
concept but is suitable for first-time requests made for objects on the Internet.
25
Cost-based Deletion
6OLGH&RVWEDVHGGHOHWLRQ
Servers for Web sites are located all over the world. Object requests are also made from different
places, regardless of the distance from the server. The ProxySG uses a powerful cost-based
deletion algorithm to determine which objects to discard when the cache gets full. A cache
memory is usually full, so some information has to be deleted to make room for newer data.
The algorithm in the ProxySG determines which object to delete based on two parameters:
Availability: If the object is readily available to be downloaded from the server, the ProxySG
can delete the object because it would be available if a user requests it later. If the object is
popular but is difficult to download because of situations where the server is at a long
distance or has too much traffic directed to it, and a large amount of bandwidth was used to
obtain it the first time, the ProxySG keeps the object because it is popular and was costly to
obtain.
File size: If an object is popular but also has a large file size, the ProxySG keeps the object
because a high amount of bandwidth would be used to obtain it the next time it is requested.
However, if the object occupies a large amount of memory but is not as popular, the ProxySG
discards it after comparing its usefulness.
Cost-based deletion chooses to delete objects based upon their cost to user response time in
combination with the objects relative popularity. The time depends on the link and is averaged
over all retrievals of an object. An object that is inexpensive to download and is not very popular
can be discarded from the cache. This way, the next time it is requested, the object can be
downloaded easily.
26
Property
Popularity Contest
6OLGH3RSXODULW\FRQWHVW
Popularity of objects in a cache is an important parameter that helps determine when objects are
deleted from the cache. The ProxySG checks for updates of popular objects to refresh and have
available for the next request. An object that has not been requested frequently during a given
period of time is more likely to be discarded than an object that is often requested. There is more
bandwidth savings and economy if the frequently requested object is served from the local cache.
The popularity contest determines which objects have to be replaced to make room for new
objects. When a new object arrives and has to be stored in the cache, the least popular object is
replaced rather than an object that has an old timestamp. Regardless of the timestamp on objects,
the ProxySG replaces the object that is not popular among users.
However, popularity of objects is not strictly based on the number of requests for a particular
object. The ProxySG uses the relative popularity concept that permits the cache to choose to refresh
a popular but costly object over an inexpensive but unpopular object.
27
RAM Object Cache
6OLGH5$0REMHFWFDFKH
Objects in RAM and the cache are treated as the same entity by the ProxySG. Objects served from
the cache are served in the same way as objects retrieved and served from an origin content server.
There is also no real marked separation from the data on the disk and the data on the RAM.
Objects are retrieved from the OCS and stored in RAM if they are cacheable. If the object is very
popular and is frequently requested, it is placed in RAM for a longer amount of time compared to
an object that is less frequently requested. Objects are stored in a two-level cache; the first level is
RAM storage for objects that are being currently accessed, and the second level is the disk cache
where popular objects are stored.
Periodically, at a scheduled time, data from the RAM is transferred to the cache when requests for
the object have slowed down but it still remains popular. This takes place asynchronously in the
background so that users are not aware of the process.
28
Property
Pipeline Retrieval
6OLGH3LSHOLQHUHWULHYDO
Typically, a Web page contains references to dozens of other objects, such as images, style sheets,
scripts, Flash files, Java applets, ActiveX components, and other embedded objects. When a
client requests a Web page, all these elements must be retrieved to display the page. For every
object that has to be retrieved, the browser has to set up a separate TCP connection, send a GET
request, and treat every such retrieval as an independent transaction. This can slow object retrieval
considerably and cause delays in the delivery of content to the user.
Object pipelining is a powerful algorithm that is used in the ProxySG to eliminate the delay that is
caused by opening several connections to retrieve objects. Instead of retrieving objects serially, this
algorithm opens as many parallel connections as the OCS allows to retrieve objects from the
server. These objects are delivered to the user as quickly as the browser can get them from the
OCS.
As illustrated in the diagram above, the ProxySG takes steps to request subsequent objects from
the server even before the client requests them:
1.
The client sends a GET request to the ProxySG or the server, based on proxy deployment.
2.
Assuming that the object is not available in the cache, the ProxySG sends a GET request to the
OCS for objects. It sends the object to the client when received from the server.
3.
To retrieve objects that could potentially be requested by the user, the ProxySG sends as many
requests as possible to the OCS or even to other servers, depending on what objects are
referenced from the requested Web page. The retrieved objects are saved in the cache for
immediate delivery to the user when requested.
4.
When the client makes a request for subsequent objects, the ProxySG delivers them to the
client immediately, thus speeding up the delivery of content to the user.
Note:
While object pipelining enhances the user experience by minimizing latency and
improving response times for first-time Web page requests, it can increase bandwidth
utilization.
29
The ProxySG Management Console has settings to control the pipelining of embedded objects.
These settings are available at Configuration > Proxy Settings > HTTP Proxy > Acceleration Profile:
Pipeline embedded objects in client request: This applies to HTML responses. When the object
associated with an embedded object reference in HTML is not present in the cache, the
ProxySG obtains the objects content even before the client requests it. Because the object is
already present when the client requests it later, the response time is highly accelerated.
Pipeline redirects for client request: If the response to a client request involves redirection
(HTTP response codes 301, 302, or 307), the HTTP proxy pipelines the object specified by the
Location header in the response when the redirection location is also an HTML object. When
this setting is enabled, the response time for redirected URLs improves considerably.
Pipeline embedded objects in prefetch request: This setting applies only to HTML responses
resulting from pipelined objects. When this setting is enabled, and a pipelined object's content
is also an HTML object, and that HTML object has embedded objects, then the ProxySG also
pipelines those embedded objects. This nested pipelining behavior can occur three levels deep
at most.
Pipeline redirects for prefetch request: Enable this setting to allow the HTTP proxy to pipeline
objects specified by a redirect location that is returned by a pipelined response.
30
Property
Statistics
6OLGH6WDWLVWLFV
Caching through the ProxySG uses disk space and RAM. Objects that are being requested
frequently are stored in RAM for quicker access and are transferred to the disk cache later when
requests are not as frequent. As shown in the diagram above, a high amount of memory is
allocated for caching both on the disk and the RAM.
A majority of the space is dedicated to object and byte caching. Object caching is implemented
using a proxy where requests sent by a client are intercepted by a proxy and served from the proxy
cache if the content is available and is fresh. If not, then the proxy sends the request to the origin
content server. Object caching is useful when content does not change very often such as
images, logos, and some documents that need to be accessed by multiple users. However, object
caching has a drawback because even if a single byte of an object changes, it has to be retrieved
again as though it was entirely new.
Byte caching comes into play here because it is independent of protocol, port, and IP address and
because it functions at the TCP layer by looking for common sequences of data. Byte caching
allows the amount of data being transferred across the WAN to be as little as possible with no loss
of content.
Because caching is so important to ensure speed of delivery to users and acceleration of the
network, a large portion of the space on the disk and the RAM is allotted for caching.
31
32
Property
Chapter 3: Services Advanced Topics
The services framework constitutes the foundation upon which everything else begins to take
shape within the policy architecture of the Blue Coat ProxySG.
Each time a network packet reaches an interface on the ProxySG, the device needs to make a
decision whether to process the packet or ignore it. If the packet is ignored, which means policies
do not apply to that transaction, the ProxySG needs to decide how to handle the packet. Two
options are available: Forward it to the next hop, or to drop it. You can configure the ProxySG to
perform either action, depending on deployment and configuration options that you select.
The TCP tunnel service is a generic interpreter for TCP packets, which you can use to process
traffic that is not the list of protocols known to the ProxySG. For instance, if you have a custom
application using a proprietary or non-standard Layer 7 protocol, you still can proxy that
application through the ProxySG using the TCP tunnel service.
Protocol detection and protocol handoff, and the relationship between the two.
How a TCP tunnel works with protocol detection and protocol handoff.
How bypass lists and restricted intercept lists selectively intercept traffic, and how to
configure these lists.
When to configure the ProxySG to trust a client-provided destination IP address.
33
Overview
Managing tunneled protocols
Detect protocol
Protocol handoff
Selective intercept
Bypass lists
Restricted intercept
Trust destination IP
6OLGH2YHUYLHZ
Through the services configuration, the administrator makes the fundamental decisions on which
traffic the ProxySG should process.
What may seem to be a simple decision such as I want to control all IM traffic has many
subtle implications that you may not consider at first. Additionally, in a large environment, you
want to test the scalability and robustness of the ProxySG with production load without
necessarily affecting all such traffic.
This chapter discusses the details of this important concept that relates to the services framework,
with a particular focus on tunneled protocols.
While studying this chapter, recall the differences between the two proxy deployment methods:
Explicit proxy: When the ProxySG is operating in explicit proxy mode, it cannot forward
traffic if there is not a service port associated with the destination TCP port of the incoming
traffic. For instance, if you try to connect to a ProxySG on port 8781, where by default there are
no services running, then you get an error message saying that the proxy has refused the
connection (or even that the proxy is not there).
Transparent proxy: The same is true when traffic is transparently sent to the proxy; however,
there are two notable exceptions to this. If the ProxySG is configured to operate in bridging
mode or as a router, all of the packets that have a destination TCP port that does not match
any of the services running on the proxy are forwarded to the next hop as specified in the
packet or frame. (Routing mode requires that you have IP address forwarding enabled.)
Another point to note is that if you have set the default service to Intercept, then all of the
traffic is optimized and sent to the next hop in the network or to its final destination.
34
Property
Protocol Detection
6OLGH3URWRFROGHWHFWLRQ
Protocol detection identifies HTTP, SSL, Endpoint Mapper, and various peer-to-peer protocols
carried within HTTP connect requests, SOCKS connect requests, and TCP tunnels. On the
ProxySG, protocol detection can be enabled or disabled for each proxy service manually, or it can
be implemented using policy. If you set policy for protocol detection, you can enhance granularity
by matching on a richer set of conditions than just the specific service; policy always overrides
manual settings.
If protocol detection is enabled, the ProxySG inspects the first bytes sent from the client and
determines whether a corresponding application proxy is available to hand off the connection. For
example, an HTTP request identified on a TCP tunnel has full HTTP policy applied to it, rather
than just simple TCP tunnel policy. In particular, this means that:
The request shows up as client protocol HTTP rather than TCP tunnel.
The URL used while evaluating policy is an http:// URL of the tunneled HTTP request, not a
tcp:// URL of where the tunnel was connecting to.
Forwarding policy is applied based on the new HTTP request, so the forwarding host selected
must support HTTP. A forwarding host of type TCP cannot handle the request and causes the
request to be blocked.
Enabling protocol detection helps accelerate the flow of traffic. However, the TCP session must be
fully established with the client before either the application proxy or the TCP tunnel proxy
contacts the origin content server. In some cases, such as in active-mode FTP data connections,
enabling protocol detection can cause a delay in setting up the connection. You can avoid this
connection delay either by using a protocol-specific proxy (such as the FTP proxy) or by disabling
protocol detection.
If protocol detection is disabled either in the Management Console or through policy, traffic is
handled by a TCP tunnel without being interpreted by a protocol-specific proxy.
35
In the example shown above, a client is making an HTTPS request to the ProxySG using HTTP
over port 8080. Because the request arrives on port 8080 and that port is assigned to process traffic
using the HTTP proxy, an HTTP client worker is launched.
The HTTPS content is encrypted, so if protocol detection is not enabled, the client worker only can
perform simple processing of the initial connect request before switching from proxy mode to
tunneling mode, and the data passes through the policy engine only as HTTP traffic. This means
that evaluation of the policy shown above, which checks the validity of the security certificate and
verifies that it has not been revoked, does not match.
On the other hand, if protocol detection is enabled, the HTTP worker passes data to an SSL
worker, which understands the HTTPS protocol and can recognize the embedded security
certificate, which allows the policy to be evaluated.
36
Property
Protocol Handoff
6OLGH3URWRFROKDQGRII
Protocol handoff is a term used for a number of different cases where one protocol worker hands off
a request or a connection to another protocol worker. Some of these are triggered by protocol
detection, but many of them are not. All of the following involve handoffs without involving
protocol detection:
SOCKS acceleration by port number of HTTP or instant messaging.
SSL forward proxy interception as HTTPS.
Streaming over HTTP.
Instant messaging over HTTP.
In this chapter, the focus is only on IM protocol and streaming media detection.
For Instant Messaging

IM handoff allows the HTTP proxy to handle requests from supported IM protocols. If IM HTTP
handoff is disabled, requests are passed through, and IM-specific policies are not applied. Handoff
should be enabled (the default) if you write IM policy.
If you want to allow a specific IM client to connect through HTTP through the ProxySG and that
IM protocol has not been licensed, disable IM HTTP handoff to allow the traffic to be treated as
plain HTTP traffic and to avoid an error in the licensing check done by the IM module. This also
might be necessary to temporarily pass through traffic from new versions of IM clients that are not
yet supported by the ProxySG.
In the example shown in the above diagram, the user has configured an IM client to use an HTTP
proxy on port 8080, sending IM traffic formatted inside an HTTP wrapper. And on this ProxySG,
there is a policy that says any IM containing the text string project paris is blocked from
reaching its recipient.
37
If the HTTP worker receives this IM traffic and does not have protocol handoff enabled, the
ProxySG treats the traffic only as HTTP, with no knowledge of the IM protocol. The information
necessary to evaluate the content of the IM is not available, so the policy shown does not match.
When protocol handoff is enabled, however, the HTTP worker reads the wrapper around the
client request, detects that it is IM, and passes the request to the more specialized IM worker. The
IM worker processes that data portion of the HTTP request and can recognize IM-specific
information such as sender, recipient, and content. At this point, the policy is evaluated, and if the
IM contains the text string project paris, the message is blocked.
For Streaming Media

When a Windows Media, Real Media, or QuickTime client requests a stream from the
ProxySG over port 80, which in common deployments is the only port allowing traffic through a
firewall, the HTTP module passes control to the streaming module so HTTP streaming can be
supported through the HTTP proxy port. The ProxySG supports HTTP streaming, and the HTTP
streaming request triggers a protocol handoff the downloading of media files from an HTTP
server do not trigger the handoff and are instead processed by the regular HTTP proxy on the
ProxySG. An HTTP connection established through port 80 allows you to send streaming data
from the origin content server to the clients through the ProxySG.
Note:
The default setting for HTTP handoff is enabled. If you do not want HTTP streams to
be cached or split, change this setting to disabled.
38
Property
Protocol Detection and Handoff
6OLGH3URWRFROKDQGRIIDQGGHWHFWLRQ
This example shows a case where protocol detection and protocol handoff both need to be enabled
to achieve desired results.
A client is sending instant messages with HTTP over an explicit-proxy connection on port 3128.
(This port normally is used by Squid clients.) As in the previous example, the administrator
wishes to block IMs that contain the text string project paris and has created a policy to
match on that string.
Without protocol detection, the TCP tunnel worker cannot interpret the incoming traffic, so the
policy does not match.
With protocol detection, the TCP tunnel worker looks at the incoming traffic on port 3128,
determines that it is HTTP, and directs it to an HTTP worker. But without protocol handoff, the
HTTP worker itself cannot interpret the IM traffic encapsulated in the HTTP traffic, so again the
policy does not match.
With protocol detection and protocol handoff, however, the HTTP worker is able to pass the IM
traffic to the specialized IM worker, which can interpret the IM protocol and properly evaluate the
policy.
39
Early Intercept
6OLGH(DUO\LQWHUFHSW
The early intercept feature controls whether the ProxySG responds to client TCP connection
requests before connecting to the upstream server. When this option is enabled, the ProxySG
concludes the three-way TCP handshake with the client before establishing any connection with
the remote server. From the client perspective, the TCP connection has been established, even
when the remote server might actually be not available.
The advantage of early intercept is that the ProxySG can reduce the overall time it takes to handle
the clients request. By answering the clients connection request immediately, the ProxySG gets
the actual request from the client more quickly and can reduce the total time needed to serve the
response. This is especially true in the case of cache hits, where the ProxySG can return the
response to the client without ever contacting the origin content server. This is only possible with
early intercept enabled; otherwise, the ProxySG would have to contact the server before it can
determine which URL the client was requesting (the ProxySG reads the information in the HTTP
GET request, which is sent by the client after the TCP connection has been established).
Additionally, with protocols such as HTTP, the ProxySG has the option of not just dropping the
connection when the remote server is not responding; the ProxySG can return a properly
formatted HTTP error response notifying the client why the connection cannot be established.
When early intercept is disabled, the proxy delays responding to the client until after it has
attempted to contact the server. After the client sends the TCP SYN packet, the ProxySG sends its
own TCP SYN packet to the remote server. Only after a server reply, the ProxySG responds to the
client. If the server is not responding, the client is not able to complete the three-way TCP
handshake. The advantage of not enabling early intercept is that the ProxySG can properly reflect
back a connection refused or connection timed out error from a server back to the client, since the
ProxySG has not yet actually responded to the clients connection request (TCP SYN).
Note:
When you enable protocol detection, the ProxySG automatically enables early
intercept.
40
Property
TCP Tunnel Details
6OLGH7&3WXQQHOGHWDLOV
TCP tunneling can be compared to a photocopy machine. When you are making a copy of a
document, the machine does not care if it is written in Chinese, English, or Arabic; it just copies it
as is. The TCP tunnel service works in the exact same way; while the information at lower layers
(in particular, data link, network, and transport) can be changed, the application-level information
remains untouched.
The ProxySG supports both explicit and transparent TCP tunneling. You can choose either method
depending on your needs.
Explicit TCP tunneling allows connections to one of the IP addresses belonging to the ProxySG.
Transparent TCP tunneling allows connections to any IP address other than those belonging to the
ProxySG. TCP tunneling in transparent mode supports categorization as well as blocking of
destination IP addresses, ports, hosts, and domains.
A TCP tunnel can be created from either the command-line interface or the Management Console.
When a TCP tunnel service is created, it is by default created as an explicit service and is also
enabled automatically.
Note:
The TCP-Tunnel service does not support content filtering with Websense off-box or
ICAP.
The above example shows a ProxySG that is listening for incoming connections using the Gopher
protocol on ports 70, 10070, and 11070. Gopher is a legacy protocol that the ProxySG does not
understand, so a TCP tunnel service is used to process the traffic.
For the transparent connection on port 70, the destination IP address of the request is the address
of the Gopher server. The ProxySG can connect to the Gopher server as desired.
41
For the explicit connection on port 10070, the request terminates at the ProxySG because there is
no other destination IP address in the client request. In this case, the ProxySG needs a forwarding
rule as shown above. When there is an explicit connection over a TCP tunnel with a protocol that
the ProxySG does not understand, the only thing the ProxySG can do is forward traffic arriving on
a specific port to a specific destination.
For the explicit connection on port 11070, the request also terminates at the ProxySG. But because
the forwarding rule applies only to traffic on port 10070, this request times out, and no connection
to the Gopher server is established.
42
Property
Static and Dynamic Bypass
6OLGH6WDWLFDQGG\QDPLFE\SDVV
The bypass list contains IP addresses and subnet masks of client and server workstations. Used
only in a transparent proxy environment, the bypass list allows the ProxySG to skip processing
requests sent from specific clients to specific servers. The list allows traffic between protocol
incompliant clients and servers to pass through the ProxySG without a disruption in service
Using Policy to Configure Dynamic Bypass

Dynamic bypass, available through policy (VPM or CPL), can automatically compile a list of
response URLs that return various kinds of errors.
Dynamic bypass keeps its own (dynamic) list of which connections to bypass, where connections
are identified by both source and destination. Dynamic bypass can be based on any combination
of policy triggers. In addition, some global settings can be used to selectively enable dynamic
bypass based on specific HTTP response codes. After an entry exists in the dynamic bypass table
for a specific source/destination IP pair, all connections from that source IP to that destination IP
are bypassed in the same way as connections that match against the static bypass list.
For a configured period of time, further requests for the error-causing URLs are sent immediately
to the origin content server, bypassing the ProxySG. The amount of time a dynamic bypass entry
stays in the list and the types of errors that cause the ProxySG to add a site to the list, as well as
several other settings, are configurable from the CLI.
Once the dynamic bypass timeout for a client and server IP address entry has ended, the ProxySG
removes the entry from the bypass list. On the next client request for the client and server IP
address, the ProxySG attempts to contact the OCS. If the OCS still returns an error, the entry is
once again added to the local bypass list for the configured dynamic bypass timeout. If the entry
does not return an error, the request is handled in the normal manner.
Note that:
Dynamic bypass entries are lost when the ProxySG is restarted.
43
No policy enforcement occurs on client requests that match entries in the dynamic or static
bypass list.
If a site that requires forwarding policy to reach its destination is entered into the bypass list,
the site is inaccessible.
Adding Dynamic Bypass Parameters to the Local Bypass List

The first step in configuring dynamic bypass is to set the server-threshold,
max-entries, or timeout values.
Note:
This step is optional because the ProxySG uses default configurations if you do not
specify them. Use the default values unless you have specific reasons for changing
them. Contact Blue Coat Technical Support for detailed advice on customizing these
settings.
The server-threshold value defines the maximum number of client entries before the
ProxySG consolidates clientserver pair entries into a single server entry that then applies to
all clients connecting to that server. The range is 1 to 256. The default is 16. When a
consolidation occurs, the lifetime of the consolidated entry is set to the value of timeout.
The max-entries defines the maximum number of total dynamic bypass entries. The range
is 100 to 50,000. The default value is 10,000. When the number of entries exceeds the
max-entries value, the oldest entry is replaced by the newest entry.
The timeout value defines the number of minutes a dynamic bypass entry can remain
unreferenced before it is deleted from the bypass list. The range is 1 to 86,400. The default
value is 60.
Enabling Dynamic Bypass and Specifying Triggers

Enabling dynamic bypass and specifying the types of errors that causes a URL to be added to the
local bypass list are done with the CLI. You cannot use the Management Console.
Using policy to enable dynamic bypass and specify trigger events is better than using the CLI
because the CLI has only a limited set of responses.
Bypassing Connection and Receiving Errors

In addition to setting HTTP code triggers, you can enable connection and receive errors for
dynamic bypass.
If connect-error is enabled, any connection failure to the origin content server, including
timeouts, inserts the OCS destination IP address into the dynamic bypass list.
If receive-error is enabled, when the cache does not receive an HTTP response on a successful
TCP connection to the OCS, the OCS destination IP address is inserted into the dynamic bypass
list. Server timeouts can also trigger receive-error. The default timeout value is 180 seconds,
which can be changed.
44
Property
Restricted Intercept
6OLGH5HVWULFWHGLQWHUFHSW
By default, all clients and servers evaluate the entries in Proxy Services (Configuration > Services >
Proxy Services) where the decision is made whether to intercept or bypass a connection. To restrict
or reduce the clients and servers that can be intercepted by proxy services, use the Restricted
Intercept List. The Restricted Intercept List is useful in a rollout, prior to full production, where
you only want to intercept a subset of the clients. After you are in full production mode, you can
disable the Restricted Intercept List.
The Restricted Intercept List is also useful when troubleshooting an issue, because you can reduce
the set of systems that are intercepted. If the restrict interception radio button (Configuration >
Services > Proxy Services > Restricted Intercept List) is selected, any systems not on the list are
bypassed.
If restricted intercept is disabled, the traffic behavior reverts to the previous behavior (before the
Restricted Intercept List was enabled). If restricted intercept is enabled, traffic not in the list of
systems is bypassed.
Note:
An entry can exist in both the Static Bypass List and the Restricted Intercept List.
However, the Static Bypass List overrides the entries in the Restricted Intercept List.
45
Trust Destination IP
6OLGH7UXVWGHVWLQDWLRQ,3
You can configure the ProxySG to trust a client-provided destination IP address in transparent
proxy deployments where:
The DNS configuration on the client is correct but is not correct on the ProxySG.
The client obtains the destination IP address using Windows Internet Name Service, or DNS
imputing on the ProxySG is not configured correctly. In these cases, the ProxySG cannot
obtain the destination IP address to serve the client request.
To set the property in the Management Console, go to Configuration > Proxy Settings > General and
select Trust Destination IP. In the MACH5 Edition, this property is enabled by default; in the Proxy
Edition, it is disabled by default. You also can change this setting through the command-line
interface or through policy.
In the above example, the client has sent a request to host abc.xyz.com, which is defined in the
client computers hosts file as IP address 1.2.3.4. However, the DNS server used by the ProxySG
returns an IP address of 5.6.7.8 for a lookup on abc.xyz.com. In this example:
1.
If Trust Destination IP is set, then the ProxySG uses 1.2.3.4, the IP address provided by the
client.
2.
If Trust Destination IP is not set, then the ProxySG uses 5.6.7.8, the IP address returned by the
DNS lookup.
You can use the client-provided destination IP address with transparent proxy environments that
use HTTP, native FTP, WebFTP, HTTPS, or streaming. The ProxySG cannot trust the
client-provided destination IP address in the following situations:
The ProxySG receives the client requests in an explicit proxy deployment.
The ProxySG has a forwarding rule configured for the request.
The ProxySG has a SOCKS gateway rule configured for the request.
The ProxySG has ICP enabled for the request.
46
Property
The ProxySG has policy that rewrites the server URL.
If a client gives the destination address of a blocked site but the hostname of a non-blocked site,
the ProxySG connects to the destination address. This might allow clients to bypass the configured
ProxySG security policy.
Using the trust_destination_ip() Property

This property allows the ProxySG to honor the clients destination IP address when it intercepts
client requests transparently.
The ProxySG trusts the client-provided destination IP address and does not perform the DNS
lookup for the HOST value in appropriate cases. This feature does not apply and existing
behavior is preserved if:
The ProxySG receives the client request in explicit proxy deployment cases.
The ProxySG has forwarding rules configured for the given HOST value.
The ProxySG will connect upstream on SOCKS.
The ProxySG will connect upstream using ICP.
By default, it is configured as enabled. To disable trusting the destination IP address, use a policy
like this example:
<forward>
proxy.address=1.2.3.4/24 trust_destination_ip(no)
47
48
Property
Chapter 4: Content Policy Language
Policy on the Blue Coat ProxySG refers to configuration values and rules applied to render
decisions on authentication requirements, access rights, quality of service, or content
transformations (including rewrites and off-box services that should be used to process the
request or response).
Policy often references system configuration for the default values for some settings and then
evaluates rules to see if those settings should be overridden.
You can create policy rules using either the Visual Policy Manager, which is accessible through the
Management Console, or by composing Content Policy Language. CPL is a proprietary
programming language specific to the ProxySG. It allows you to express the policy rules that are
enforced by the ProxySG.
Almost all policy operations can be expressed through the VPM; however, there are a few
advanced operations that are possible only in CPL.
How to compose policy rules in CPL.
How policy is evaluated during request processing.
The components of CPL statements.
How to define CPL conditions and actions.
How to use substitution in CPL statements.
How to write CPL code in the VPM.
This chapter assumes that you are familiar with the VPM and the fundamentals of policy
management on the ProxySG.
49
Basic Concepts
Transactions
Any request for service and its associated response
Usually one transaction per request for service
Policy model
Default decisions are modified by policy
Allow or deny
6OLGH%DVLFFRQFHSWV
Before reading sample CPL or trying to express your own policies in CPL, Blue Coat recommends
that you understand the fundamental concepts underlying policy enforcement on ProxySG
appliances.
Transactions
In the CPL context, a transaction is the encapsulation of a request for service and any associated
response for the purposes of policy evaluation and enforcement. In most cases, a transaction is
created for each unique request for service, and the transaction exists for the time taken to process
the request and deliver the response.
The transaction serves the following purposes:
Exposes request and response state for testing during policy evaluation.
Ensures policy integrity during processing.
Maintains policy decisions relevant to request and response processing.
Various types of transactions are used to support the different policy evaluation requirements
of the individual protocols: administrator, cache, and proxy transactions.
In a few special cases, two or more transactions can be created for a single request.
Policy Model
Each transaction begins with a default set of decisions, many of which are taken from
configuration of the system. These defaults include such things as forwarding hosts or SOCKS
gateways. The most important default decision affects whether requests should be allowed or
denied. The defaults for the various transaction types are:
Administrator transaction: The default is to deny requests.
Cache transactions: The default is to allow requests.
50
Property
Proxy transactions: The default is taken from system configuration.
The proper approach to writing proxy-layer policy depends on whether the default is to allow or
deny requests. The default proxy policy is configurable and represents the starting point for
writing policy to control proxy transactions. The default proxy policy is reported at the top of
every policy listing generated by the ProxySG, such as:
; Default proxy policy is DENY

That line in a policy listing is a CPL comment, defining the starting point for proxy policy.
51
CPL Policy Files
6OLGH&3/SROLF\ILOHV
The ProxySG allows you to create policies in several files. Each file is simply a container for CPL
code. The policy rules from all sources are combined at any time into one large set of rules called
the current policy. The total combined current policy (VPM and CPL) in effect at any time can be
viewed through the Management Console.
Each file can contain rules and definitions, but an empty file is also allowed. An empty file
specifies no policy and has no effect on the ProxySG.
The final installed policy is assembled from the policy stored in the five files by concatenating
their contents. The Threat Protection policy file always is processed first; you can change the order
in which the other four files are processed. The default evaluation order is VPM, Local, Central,
and Forward. The last file in the list overwrites decisions in files evaluated earlier.
Threat Protection Policy File

When malware scanning is enabled, the Threat Protection policy file is enabled. Unlike other
policy files, the Threat Protection policy file is not displayed in the policy evaluation order list in
the Management Console; the Threat Protection policy file cannot be edited or modified.
However, you can create rules in other policy files to supplement or override the configured
defaults. The threat protection policy is evaluated first to provide you with the flexibility to adapt
this policy to meet the requirements of your enterprise. Updates to the threat protection policy are
periodically created by Blue Coat and can be installed on your ProxySG; this is discussed in detail
in the chapters about ICAP and the ProxyAV.
VPM Policy File

The VPM generates the code in this file, and you cannot edit it. If you try to do so, policies might
work incorrectly or might not work at all.
52
Property
Local Policy File

This file typically contains most of the CPL code that you write. If you have developed most of
your policy rules in the VPM, this file generally is empty. (However, some advanced policies only
can be created using CPL.)
Central Policy File

The Central policy file typically contains settings that apply across all ProxySG appliances in a
particular enterprise. You can specify the location of the Central policy file and how frequently the
ProxySG checks for a new version of the file. By default, the appliance checks for an updated
Central policy file once every 24 hours (1,440 minutes).
You must use the CLI to configure the update interval; you cannot configure the update interval
through the Management Console. To configure the update interval through the CLI, enter the
following command at the (config) command prompt:
#(config) policy poll-interval minutes

You can manually check whether the Central policy file has changed. You must use the CLI; you
cannot check for updates through the Management Console. To check for an updated Central
policy file through the CLI, enter the following command:
#(config) policy poll-now

The ProxySG displays a message indicating whether the Central file has changed.
Forward Policy File

This file is normally used for all forwarding policy, although you can use it to supplement any
policy created in the other policy files.
53
CPL and VPM Layers

VPM
CPL
Description
Admin Authentication
<admin>
User authentication when accessing the proxys

administrative console
Admin Access
<admin>
Access control and read/write privilege control for the

proxys administrative console
DNS Access
<dns-proxy>
Handles requests and responses when client connects

to DNS proxy service port
SOCKS Authentication
<proxy>
Determines authentication method
SSL Intercept
<ssl-intercept>
Determines whether to tunnel or intercept HTTPS traffic
SSL Access
<ssl>
Determines the actions for intercepted HTTPS traffic
Web Authentication
<proxy>
User authentication and allowed triggers
Web Access
<proxy>
Access control and general transaction testing
Web Content
<cache>
Object store behavior modification and virus scanning
Forward
<forward>
Request destination control
N/A
<exception>
Control of exception responses including header

set/rewrite/delete
6OLGH&3/DQG930OD\HUV
There are eight layer types in CPL. This is fewer than what is available in the VPM; however, there
is no loss of functionality. For instance, all of the triggers and actions available in the Web
Authentication and Web Access layers in the VPM are covered under the <proxy> layer in CPL.
Everything that you learned about layers in the VPM applies to CPL layers, including the order in
which they are processed.
The above chart is a useful reference that allows you to transition easily from VPM-based rules to
CPL-based rules. In most cases, you will use <proxy> layers. Here is a summary description of
each of the CPL layers:
<proxy>: Used to list policy rules that control access to proxy services configured on the
ProxySG, which include user authentication and authorization requirements, time-of-day
restrictions, and content filtering.
<cache>: Used to list policy rules that are evaluated during a cache or proxy transaction.
<forward>: These layers are evaluated only when the current transaction requires an
upstream connection.
<admin>: Used to define policy rules that control access to the Management Console and
command-line interface.
<SSL-Intercept>: This layer lists the triggers and properties that define the interception
conditions for SSL connections. In essence, in this layer you define which HTTPS transactions
are going to be monitored. Unless you have at least one policy in this layer, no HTTPS
transactions are intercepted. If the transaction is not being intercepted, the policies in the SSL
layer do not apply.
<SSL>: This layer lists the triggers and properties that apply to the connections that are
intercepted in the SSL-Intercept layer.
54
Property
<exception>: Exception layers are evaluated when an exception property is set, forcing
transaction termination. Policy in an exception layer gives administrators a final chance to
modify the properties (such as headers) of the response (exception) object, just as they get a
chance to modify the properties of an object returned from the origin server or from cache.
<DNS-proxy>: When a client connects to one of the DNS-Proxy service ports configured on
the ProxySG, a DNS-Proxy transaction is created to cover both the request and its associated
response. A DNS-Proxy transaction evaluates policy in DNS-Proxy layers only. Policy in
other layers does not affect DNS-Proxy transactions. These layers define policy controlling
DNS-Proxy transactions. Only DNS-Proxy transactions are evaluated against DNS-Proxy
layers.
SOCKS authentication (VPM only): Determines the method of authentication for accessing the
proxy through SOCKS. The actions and triggers available in this VPM-only layer are available
under the <proxy> layer in CPL.
55
Layers
A policy layer is a CPL construct to separate decisions
Helps control policy complexity
Each layer has the form:
<layer_type [label]>
[layer_condition][layer_properties] ...
layer_content
Layer guards
layer_condition and layer_properties
Also supported in VPM
6OLGH&3/OD\HUV
A layer is a CPL construct for expressing rules for a single policy decision. Within a layer, rules are
evaluated, and the first rule matched ends the processing for that layer. Multiple layers can be
used to make multiple decisions. Layers are evaluated in top-to-bottom order, like the left-to-right
layer processing in the VPM. Decisions made by later layers can override decisions made by
earlier layers.
A CPL layer contains some or all of the following elements:
Layer_type, such as <proxy> or <admin>, defines the transactions evaluated against this
policy, and restricts the triggers and properties allowed in the rules used in the layer. You must
always have at least a layer type in a CPL layer.
Layer_condition, such as user=kelly, is a list of triggers, all of which must evaluate to

true before the layer content is evaluated.
Layer_properties is a list of properties that become the default settings for those
properties for any rule matched in the layer. These can be overridden by explicitly setting a
different value for that property in a specific rule within the layer.
The layer_content is a list of rules, possibly organized in sections.
If a rule has the logical form if (condition is true), then set properties, a layer has the form:
if (layer_condition is true) then {

if (rule1_condition is true) then
set layer_properties, then set rule1_properties
else if (rule2_condition is true) then
else if (rule3_condition is true) then
...
}
56
Property
Collectively, layer_condition and layer_properties often are referred to as layer guard

expressions. Often, the same set of conditions or properties appears in every rule in a layer. The
following is an example of a specific user group for which a number of individual cases exist
where some things are denied:
<Proxy>
group=general_staff
group=general_staff
group=general_staff
; etc.
group=general_staff
url.domain=competitor.com/jobs deny
url.host=bad_host deny
condition=whatever deny
allow
You can factor out the common elements into guard expressions. Notice that the common
elements are group=general_staff and deny. The following is the same policy, expressed as a
layer employing a guard expression:
<Proxy>1 group=general_staff2 deny3

url.domain=competitor.com/jobs
url.host=bad_host
condition=whatever
; etc.
allow
Note that the explicit allow overrides the deny specified in the layer guard. This is an instance of a
rule-specific property setting overriding the default property settings specified in a guard.
The VPM supports creation of layer guard rules. When added, the layer guard is a single rule table
that appears above the selected layer. The layer guard rule contains all of the columns available in
the layer except for the Action and Track columns. These columns are not required because the rule
itself does not invoke an action other than allowing or not allowing policy evaluation for the entire
layer. You cannot add a layer guard rule until you have created other policy layer rules.
1. This is the layer_type.

2. This is the layer_condition.
3. This is the layer_property.
57
Sections
Rules in layers can have one or more sections
A section consists of a section header followed by a list
of rules
A section has the form:
[section_type [label]]
[section_condition][section_properties]
section_content
6OLGH6HFWLRQV
A section is a way of grouping rules that have similar syntax. Sections consist of a section header
that defines the section type, followed by policy rules. The section type determines the allowed
syntax of the rules and an evaluation strategy.
Four section types are supported in a standard CPL file:
[url]: This section type is used to group a number of rules that test the URL. The [url]
section restricts the syntax of rules in the section. The first token on the rule line is expected to
be a pattern appropriate to a url= trigger. The trigger name is not included. Rules in [url]
sections are evaluated through hash table techniques, with the result that the time taken is not
dependent on the number of rules in the section. [url] sections are not allowed in <Admin>
or <Forward> layers.
[url.domain]: This section is used to group a number of rules that test the URL domain.
The [url.domain] section restricts the syntax of rules in the section. The first token on the
rule line is expected to be a pattern appropriate to a url.domain= trigger. The trigger name
is not included. Rules in [url.domain] sections are evaluated through hash table
techniques, with the result that the time taken is not dependent on the number of rules in the
section. [url.domain] sections are not allowed in <Admin> or <Forward> layers.
[url.regex]: This section is used to test the URL. The [url.regex] section restricts the
syntax of rules in the section. The first token on the rule line is expected to be a pattern
appropriate to a url.regex= trigger. The trigger name is not included. The [url.regex]
section replaces the [Regex] section used in previous versions of CPL. Rules in
[url.regex] sections are evaluated sequentially, top to bottom. The time taken is
proportional to the number of rules in the section. [url.regex] sections are not allowed in
<Admin> or <Forward> layers.
58
Property
[server_url.domain]: This section is used to test the domain of the URL used to fetch
content from the origin server. The [server_url.domain] section restricts the syntax and
rules in the section. The first token on the rule line is expected to be a pattern appropriate to a
server_url.domain= trigger. The trigger name is not included. [server_url.domain]
sections contain policy rules very similar to [url.domain] sections except that these policy
rules test the server_url, which reflects any rewrites to the request URL. Rules in
[server_url.domain] sections are evaluated through hash table techniques, with the
result that the time taken is not dependent on the number of rules in the section.
[server_url.domain] sections are allowed only in <Exception> or <Forward> layers.
To better understand who to use sections, imagine that you have a policy constructed in a way
similar to the example below:
<Proxy>
url.domain=abc.com/sports deny
url.domain=nbc.com/athletics deny
; etc., suppose its a substantial list
;
url.regex="sports|athletics" access_server(no)
url.regex="\.mail\." deny
; etc.
;
url=www.bluecoat.com/internal group=!bluecoat_employees deny
url=www.bluecoat.com/proteus group=!bluecoat_development deny
; etc.
This can be recast into three sections:
<Proxy>
[url.domain]
abc.com/sports deny
nbc.com/athletics deny
; etc.
;
[Rule]
url.regex="sports|athletics" access_server(no)
url.regex="\.mail\." deny
;
[url]
www.bluecoat.com/internal group=!bluecoat_employees deny
www.bluecoat.com/proteus group=!bluecoat_development deny
Note:
The performance advantage of using the [url], [url.domain], or

[server_url.domain] sections is measurable when the number of URLs being
tested reaches roughly 100. For lists of several hundred or thousands of URLs, the
performance advantage is significant.
59
Rules
A policy rule consists of a condition and some number of
property settings
A rule can match or miss
Condition is a Boolean combination of trigger
expressions
6OLGH3ROLF\UXOHV
Rules are crucial to enforcing policy on the ProxySG. Remember that rules are contained within
layers. Remember also that the first rule in the layer that matches stops further rule processing in
that layer. Processing then proceeds to the next layer, if any.
In VPM, rules have sources, destination, times, actions, and so on. The same is true of rules
expressed in CPL.
On the following pages, you will learn about conditions, triggers, and properties. Be aware that
conditions containing triggers can become very complex, so care is needed in constructing them.
A sample rule:
<proxy>
category = Adult/Mature Content DENY
60
Property
Triggers
Building blocks of a condition
All triggers must be satisfied for the condition to evaluate
true
Evaluated at different checkpoints
Request (url=)
Response (response.header.Content-Type=)
User (user=, group=)
System state (time=)
6OLGH&3/WULJJHUV
Triggers are the building blocks of a condition. A condition is a Boolean combination of triggers.
Triggers are individual tests that can be made against components of the request (url=), response
(response.header.Content-Type=), related user (user=, group=), or system state (time=).
With a few notable exceptions, triggers test one aspect of request, response, or associated state
against a Boolean expression of values. The condition is true only if each of the trigger expressions
is true.
CPL triggers have the form trigger_name=pattern_expression.
Triggers are evaluated at different checkpoints and are primarily request and response triggers.
Such triggers are evaluated when the client makes its initial request to the ProxySG or when an
origin content server responds to the ProxySG.
Other triggers, such as user and group triggers, are evaluated closer to the client-in checkpoint of
the ProxySG. A system state trigger can be evaluated as soon as a transaction begins in the
ProxySG.
61
Triggers URL
6OLGH&3/WULJJHUV+773
Carefully note all of the components of an HTTP request address that can be used in a trigger test.
You can write trigger expressions to construct very specific conditions in CPL code.
Note the numerous regex components that use the power of regular expressions in determining
whether a trigger test matches. Regular expressions are discussed in detail later in this course.
Regular expressions allow us to match many different combinations within a URL.
CPL triggers have the form trigger_name=pattern_expression. For example, you can
create a trigger like this:
url.domain=example.com
Table 4-1: Comparing CPL statements
URL Accessed
CPL Statement
Policy
http://www.bluecoat.com
url=www.bluecoat.com
Match
url=bluecoat.com
Miss
url.regex=bluecoat\.com
Match
url.substring=bluecoat.com
Match
url.domain=bluecoat.com
Match
62
Property
Properties
6OLGH&3/SURSHUWLHV
A transaction is a unit of work that cannot be interrupted and must succeed or fail as a unit. A
transactions is a set of operations that are performed as though they were a single operation, with
one overall result assigned to the transaction. Properties are settings that control transaction
processing or the handling of an object.
Every transaction intercepted by the ProxySG is either allowed or denied.
At the beginning of a transaction, all properties are set to their default values. As the policy is
evaluated in sequence, rules that match might set a property to a particular value. A property
keeps its final value when evaluation ends, and the transaction is processed accordingly.
Properties that are not set within the policy keep their default values.
When a transaction is intercepted by a ProxySG, the default policy of that ProxySG either Allow
or Deny, as configured by the administrator is associated with the transaction.
During policy processing, three things can happen to the status of the transaction:
The status is not changed, meaning that no rules are matched. The default policy stays in
effect for this transaction.
A rule can match to change a property, such as logging or authentication.
Other actions can be specified, such as redirection or URL rewrite.
Once policy processing is complete, not all actions directed by the policy are necessarily taken; this
depends on the final status of the transaction and whether it is allowed or denied.
63
Layer Processing Example
6OLGH/D\HUSURFHVVLQJH[DPSOH
The above example shows how policy processing can result in a transaction being allowed or
denied. It is assumed that policy processing continues through all three layers in this example, so
there are three possible exit points, numbered 1, 2, and 3. The arrows show the many paths that
policy processing can take here. Also, only actions not triggers are shown in this example.
As discussed on the previous page, the transaction enters the ProxySG and receives the default
policy for that ProxySG, either Allow or Deny. Think of the default policy as an invisible Layer 0, a
Web Access Layer that always appears in every policy.
In Layer 1, the rule always is processed. The effect of the authenticate action depends on whether
it is an authenticate or force-authenticate and whether the transaction is ultimately allowed or
denied. Authentication prompts a user to authenticate only if the transaction has been allowed. If
the transaction is denied, then the user is not prompted for credentials unless a force-authenticate
is used.
In Layer 2, if the Modify Logs rule matches, then log notification occurs regardless of whether the
transaction is allowed or denied. If the rule misses, then processing continues to the Rewrite URL
rule. If it matches, the rewrite is performed only if the final result of policy processing is Allow.
In Layer 3, if the top rule matches, then processing exits with a status of Allow, and the actions
from Layer 1 and Layer 2 are performed if they matched. If the Return Exception rule matches, the
default policy determines the final status and whether the actions from Layer 1 and Layer 2 are
performed. Finally, if the bottom rule matches, then processing exits with a status of Deny, the
URL rewrite from Layer 2 does not take place, the user receives an exception, and authentication
happens if a force-authenticate was specified.
64
Property
Definitions
Trigger definition
Subnet definitions
Condition definitions
Category definition
Transformers
Transformer definitions specify a transformation to an
HTTP response
6OLGH&3/QDPHGGHILQLWLRQV
There are various types of named definitions. Each definition is given a user-defined name that is
then used in rules to refer to the definition.
Subnet definitions are used to define a list of IP addresses or IP subnet masks that can be used to test
any of the IP addresses associated with the transaction.
Here is an example of a subnet definition:
define subnet corporate_subnet

10.10.12.0/24
end
Condition definitions can include any triggers that are legal in the layer referencing the condition.
The condition= trigger is the exception to the rule that triggers can test only one aspect of a
transaction. Because conditions definitions can include other triggers, the condition= trigger
can test multiple parts of the transaction state. Also, condition definitions allow for arbitrary
Boolean combinations of trigger expressions.
Here is an example of a condition definition:
; Deny access to client 1.2.3.4 for http requests on proxy port 8080
define condition QA
client.address=1.2.3.4 proxy.port=8080
end
Category definitions are used to extend categories from content filters (such as Blue Coat WebFilter)
or to create your own. These categories are tested (along with any vendor-defined categories)
using the category= trigger.
Here is an example of a category definition:
65
define category Grand_Canyon

kaibab.org
www2.nature.nps.gov/ard/parks/grca/
end
A transformer definition is a kind of named definition that specifies a transformation to be applied
to an HTTP response, modifying an HTTP response before returning it to the client. There are
three types: url_rewrite definitions, active_content definitions, and javascript
definitions.
Here is an example of a transformer definition:
define url_rewrite ijk_portal
rewrite_url_substring "http://www.ijk.com/" "http://www.server1.ijk.com/"
end
66
Property
Actions
Two types of actions in CPL
Properties: change proxy configuration
Defined actions: change transaction
Actions
Simple syntax
define action action_name
actions
end
Actions can be turned on or off
action.action_name({yes|no})
6OLGH&3/DFWLRQV
An action takes arguments and is wrapped in a user-named action definition block.

There are two types of actions: properties, which direct the behavior of the ProxySG; and defined
actions, which modify the transactions performed by the ProxySG. Defined actions can perform
tasks such as adding and removing request and response headers, rewriting URLs, and so on.
An action definition has the following structure:

actions...
end
The parameter action_name can be any alphanumeric string without spaces; you should use a
name that closely describes what the action is going to do.
Once you have declared the action, you can invoke it from anywhere in the CPL code, although
you cannot invoke it from a layer where the action is not valid. You can control when the action is
actually performed, using any of the triggers available for that layer. The construct to invoke the
execution of a define action is:
action.action_name(yes)
Actions appear only within action definitions, and they cannot appear in <admin> layers.
The allowed syntax for an action arguments depends on the action. There are four types of
arguments: string, enumeration, regular expression, and variable substitution. Each defined action
takes a special set of arguments. Here are some examples:
append(): Appends a new component to the specified header.
delete(): Deletes all components of the specified header.
delete_matching(): Deletes all components of the specified header that contain a

substring matching a regular-expression pattern.
67
redirect(): Ends the current HTTP transaction and returns an HTTP redirect response to
the client by setting the policy_redirect exception. Use this action to specify an HTTP 3xx
response code, optionally set substitution variables based on the request URL, and generate
the new Location response-header URL after performing variable substitution.
rewrite(): Rewrites the request URL, URL host, or components of the specified header if it
matches the regular-expression pattern. This action is often used in conjunction with the URL
rewrite form of the transform action in a server portal application.
set(): Sets the specified header to the specified string after deleting all components of the
header.
68
Property
Define Actions Example
Is this policy correct?

What is the net effect of this policy?
6OLGH'HILQHDFWLRQVH[DPSOH
The above example shows a simple defined action. In this example:

1.
The define action statement begins the definition.
2.
The name of the action is an alphanumeric name that contains no spaces.
3.
When invoked, this action deletes the user-agent header from the HTTP request.
4.
In the first layer, the user is prompted to authenticate in the realm my_iwa_realm.
5.
In the second layer, because there is no trigger, this condition matches every transaction
intercepted by the ProxySG, and the ProxySG removes the user-agent header if it exists.
6.
In the third layer, if the username is bob.kent, then the action from the previous step is
undone, and the user-agent header is not removed.
How could this policy be rewritten to be more efficient and use only two layers?
69
Definition and Action Examples
6OLGH'HILQLWLRQDQGDFWLRQH[DPSOHV
The above example shows category and action definitions. There are three definitions:
1.
The condition BobKent is defined by a client IP address and an NT domain name.
2.
The category definition contains a domain name and a specific URL.
3.
The action scrub_private_info() contains two actions. The first set() clears any value
that is present in the From field of the request header; the second set() clears any value that
is present in the Referer field of the request header.
There are two layers:

A. In the Web Content Layer, designated by <cache>, if the request is not to
my_internal_site.com, then the scrub_private_info() action is invoked. In other words,
the From and Referer headers are scrubbed from all HTTP requests for all sites except
my_internal_site.com.
B. In the Web Access Layer, designated by <proxy>, if the request is to either the domain name
or the specific URL defined in the category Grand_Canyon, and if the condition BobKent is
true, then the transaction is denied.
70
Property
Policy Review 1

What would you change and why?
6OLGH3ROLF\UHYLHZ
This example shows three layers, with one rule per layer:
1.
If the requested object is in a category named HR (defined elsewhere), then authenticate the
user in the realm HR_Realm.
2.
If the user is a member of group IT, then authenticate the user in realm HQ_IWA_Realm.
3.
If the requested object is not categorized by the content filter, then deny the request.
One of these policy statements is not valid. Your instructor will discuss this with you. (The answer
is on the next page.) How can you correct it?
71
Policy Review 2

What would you change and why?
6OLGH3ROLF\UHYLHZ
On the previous page, the second statement is incorrect. You cannot authenticate based on group
membership because such membership is determined only after authentication. If you try to use
this statement, you will receive the error message Late condition guards early action. In the above
example, the goal is to allow text from sites categorized as Pornography but to block images from
such sites. Rule 1 and Rule 2 block GIF and JPEG images, and Rule 3 allows all other content to
pass through.
In Rule 1, the decision can be done at the client-in checkpoint. But Rule 2 can be evaluated only at
server-in or later, which means that the ProxySG has to connect, retrieve data, and process data
before it can make a decision. Because of this, Rule 1 should appear first so that Rule 2 does not get
evaluated unless necessary.
Will this policy work? Your instructor will discuss this with you. (The answer is on the next page.)
72
Property
Substitutions
Functions
Rewrite URL request
Modify HTTP request headers
Modify HTTP response
Common substitutions
$(url)
$(url.host)
$(client.address)
$(user)
$(proxy.name)
=> Client requested URL

=> URL hostname
=> Requesting clients IP
=> Authenticated username
=> Proxys hostname
6OLGH6XEVWLWXWLRQV
On the previous page, the policy has correct syntax but does not effectively block all pornographic
images. Only files of type jpg and gif are blocked, and the policy does nothing to block video. A
better solution is to rewrite the policy to allow only text from such sites; your instructor will
discuss this with you.
Substitutions are variables that are replaced by text strings appropriate to the current policy
transaction at execution time.
The actions used to rewrite the URL request or to modify HTTP request headers or HTTP response
headers often need to reference the values of various elements of the transaction state when
constructing the new URL or header value.
CPL provides support for various substitutions that expand at run time to the indicated
transaction value.
Substitutions have the form $(name). For example, the substitution $(user) expands to the
authenticated username associated with the transaction. If policy did not require that user to
authenticate, the substitution expands to an empty string.
Substitutions can also be used directly in the values specified to some CPL properties, such as
when setting text in a message that is displayed to users.
In each case, the substitution on the left is defined by the text on the right. For example, $(url) is
the substitution for a client-requested URL.
Substitution cannot be used in all actions or CPL gestures. You can use most of the substitutions to
create custom notification pages.
73
Sample Policy Using Substitutions
6OLGH6DPSOHSROLF\XVLQJVXEVWLWXWLRQV
The above CPL code fragment shows what can be done with substitutions in CPL.
1.
The action addcookie() creates a cookie with the name of the username that is associated
with that transaction in the ProxySG.
2.
The first <proxy> layer performs the addcookie() action for all intercepted transactions.
3.
In the second <proxy> layer, if the user is a member of the group NoAccess (defined outside
this code fragment), the user receives a policy_denied exception with a customized
message and a specific hostname. If the user is an NT user, then the $(user) substitution is in
the format domain\username. If the user is authenticated in an LDAP realm, then the
$(user) substitution is in the form cn=username,cn=users ... a form that can be
lengthy.
This CPL code is not suitable for use in a production environment; it is presented here for
instructional purposes only.
74
Property
CPL in the VPM
21
6OLGH&3/LQWKH930
CPL code can be entered directly into the VPM. This can be useful when using CPL capabilities
that are not directly supported in the VPM, or when copying and pasting CPL code obtained from
other sources.
Multiple CPL layers are allowed. Unlike other VPM layers, the CPL layer uses no VPM objects and
rules. Also, layer guard functionality is not available.
Policy entered in a CPL layer is inserted into the VPM-generated policy at the position specified
by the position of the CPL layer. As shown in the example above, a CPL layer can be reordered:
1.
Create a CPL layer. It appears in the rightmost position in layer ordering, but the
administrator wishes to change this.
2.
The Move Up and Move Down buttons can be used to change the position of any layer,
including CPL layers.
3.
When the layers have been reordered as desired, click OK.
4.
The CPL layer now appears in the new position.
The VPM does not perform any validation on the CPL that you enter until you click Install policy.
If you have written invalid CPL, the errors are flagged and the policy is not installed.
75
76
Property
Chapter 5: Regular Expressions
The origin of regular expressions lies in automata theory and formal language theory (both part of
theoretical computer science). These fields study computation models (automata) and ways to
describe and classify formal languages. In the 1940s, Warren McCulloch and Walter Pitts described
the nervous system by modeling neurons as small simple automata. In the 1950s and 1960s,
mathematician Stephen Kleene described these models using his mathematical notation called
regular sets.
In the 1970s, Ken Thompson built regular expression notation into the editor QED, into the
UNIX editor ed and into grep. Since then, regular expressions have been extensively used in
UNIX and UNIX-like utilities such as expr, awk, Emacs, vi, lex, and Perl. Many students of
computer science learned to use regular expressions from these tools.
Henry Spencer wrote regex, from which Perl regular expressions were derived. Philip Hazel then
developed pcre (Perl Compatible Regular Expressions), which attempts to closely mimic Perls
regular expression functionality, and is used by many modern tools such as PHP and Apache.1
A regular expression (or regex or RE) is a pattern that is matched against a subject string from left to
right. Most characters stand for themselves in a pattern and match the corresponding characters in
the subject. The power of regular expressions comes from the ability to include alternatives and
repetitions in the pattern. These are encoded in the pattern by the use of metacharacters, which do
not stand for themselves but instead are interpreted in some special way.
Regular expressions can contain both special and ordinary characters. Most ordinary characters,
such as A, a, or 3, are the simplest regular expressions; they simply match themselves. You can
concatenate ordinary characters, so last matches the characters last.
Note:
In this chapter, regular expressions are printed in this font, usually without
quotes, and strings to be matched are in single quotes.
Some characters, such as | (vertical bar or pipe) or ( and ) (parentheses), are special. Special
characters, called metacharacters, either stand for classes of ordinary characters or affect how the
regular expressions around them are interpreted.
On the Blue Coat ProxySG, regular expressions differ from those found in Perl. The main
differences are:
Normally, space matches space, formfeed, newline, carriage return, horizontal tab, and
vertical tab. Perl version 5 no longer includes vertical tab in its set of white-space characters.
The \v escape that was in the Perl documentation for a long time was never in fact
recognized. However, the character itself was treated as white space at least up to 5.002. In
5.004 and 5.005, it does not match \s.
The ProxySG does not allow repeat quantifiers on lookahead assertions. Perl permits them,
but they do not mean what you might think. For example, (?!a){3} does not assert that the
next three characters are not a. It just asserts that the next character is not a three times.
Capturing subpatterns that occur inside negative lookahead assertions are counted, but their
entries in the offsets vector are never set. Perl sets its numerical variables from any such
patterns that are matched before the assertion fails to match something (thereby succeeding),
but only if the negative lookahead assertion contains just one branch.
1. This historical information about regular expressions is adapted from an article on Wikipedia.
77
Though binary zero characters are supported in the subject string, they are not allowed in a
pattern string because it is passed as a normal C string, terminated by zero. The escape
sequence \0 can be used in the pattern to represent a binary zero.
The following Perl escape sequences are not supported: \l, \u, \L, \U, \E, \Q. In fact, these
are implemented by Perls general string handling and are not part of its pattern-matching
engine.
The Perl \G assertion is not supported as it is not relevant to single pattern matches.
The ProxySG does not support the (?{code}) construction.
There are some oddities in Perl 5.005_02 concerned with the settings of captured strings when
part of a pattern is repeated. For example, matching aba against the pattern /^(a(b)?)+$/
sets $2 to the value b, but matching aabbaa against /^(aa(bb)?)+$/ leaves $2 unset.
However, if the pattern is changed to /^(aa(b(b))?)+$/ then $2 (and $3) get set. In Perl
5.004, $2 is set in both cases, and that is also true on the ProxySG.
In Perl 5.005_02, the pattern /^(a)?(?(1)a|b)+$/ matches the string a, but on the
ProxySG, it does not. However, in both Perl and on the ProxySG, /^(a)?a/ matched against
a leaves $1 unset.
The ProxySG provides some extensions to the Perl regular expression facilities: Although
lookbehind assertions must match fixed-length strings, each alternative branch of a
lookbehind assertion can match a different length of string. Perl 5.005 requires them all to have
the same length.
Note:
When regular expressions are used to match a URL, a space character matches a %20 in
the request URL. However, a %20 in the regular-expression pattern will not match
anything in any request URL, because %20 is normalized to in the subject string before
the regex match is performed.
78
Property
Regular Expressions
Regular expressions compare a substring to a target string
NET
OATH
OTH
6OLGH5HJXODUH[SUHVVLRQV
The slide shows a reference string and three different patterns. The reference string is
onetwothreefour and the patterns are net, oath, and oth.
Only two of the patterns exist in the reference string. When a pattern exists in the reference string,
you have a match and the regular expression assume the boolean value of TRUE.
Assume that you are going to the URL http://www.bluecoat.com/resources/training and then you
are going to the URL http://training.bluecoat.com. You have the following policy on the ProxySG:
<proxy>
url.regex = training DENY
Both URL requests will mach the policy and will be denied. The URL is the reference string, and
the word training is the pattern. The pattern matches both reference strings.
The following pages cover additional regular expression syntax, which allows you to better define
how to match patterns in reference strings.
79
Character Classes
. (period)
Matches any character
\w
Matches any word character. A word is anything made of
letters, numbers, and the _ (underscore)
\s
Matches a white space
6OLGH*HQHULFFKDUDFWHUFODVVHVRUW\SHV
The most important and most frequently used character class is the dot. A dot in the pattern
matches any one character in the subject, including a non-printing character, but not (by default) a
newline. (Newlines should not be detected when using regular expressions in CPL.) The handling
of dot is entirely independent of the handling of circumflex and dollar, the only relationship being
that they both involve newline characters. Dot has no special meaning in a character class.
There are several generic character classes (or types) used in regular expressions:
. matches any character except a newline (which is not matched in CPL).
\d matches any decimal digit.
\D matches any character that is not a decimal digit.
\s matches any white-space character.
\S matches any character that is not a white-space character.
\w matches any word character, which is any letter or digit or the underscore character.
\W matches any non-word character.
\xnn matches the two-digit hexadecimal value nn, such as \xD7 or \x02.
Consider the two URLs http://www.bluecoat.com and http://wwwwbluecoat.com and this policy:
<proxy>
url.regex=www.bluecoat.com
The policy matches both URL because the dot in the regex matches any character.
80
Property
Using \
\.com
Need to use the \ because . is a special character
\.com
Matches anything with .com in it
Matches www.bluecoat.com
Matches www.bluecoat.com.sg
6OLGH8VLQJEDFNVODVK?DVDQHVFDSHFKDUDFWHU
Regular expressions assign special meaning to several characters. These characters are called
metacharacters to indicate that they are interpreted in some special way when used in regular
expressions.
When you need to use one of these metacharacters literally in a regular expression, place a
backslash (\) in front of it. This allows you to use it without its special meaning. In the example in
the above diagram, you want to use the dot or period as is, without its metacharacter value of
matching any single character.
The backslash is called the escape character because it allows the character that follows it to escape
from the world of metacharacters.
For example, analyze the two layers below and note how the dot has a different role:
<proxy>
url.regex=www\.bluecoat\.com ALLOW
<proxy>
url.regex=blueco.t ALLOW
The first policy matches a URL that contains the string www.bluecoat.com; the second policy
matches any URL that contains blueco followed by any one character and a t.
81
Using ^ and $
^www
Matches anything starting with www
Does NOT match bluecoat.www.com.sg
\.com$
Matches anything ending with .com
Does NOT match www.bluecoat.com.sg
6OLGH8VLQJADQG
In a regular expression, you can use the circumflex (^) to match the start of a line and the dollar
sign ($) to match the end of a line.
The circumflex does not need not be the first character of the pattern if a number of alternatives
are involved; however, it should be the first thing in each alternative in which it appears if the
pattern is ever to match that branch. If all possible alternatives start with a circumflex that is, if
the pattern is constrained to match only at the start of the subject it is said to be an anchored
pattern. (There are also other constructs that can cause a pattern to be anchored.)
A dollar-sign character is an assertion that is true only if the current matching point is at the end of
the subject string, or immediately before a newline character that is the last character in the string
(by default). The dollar sign need not be the last character of the pattern if a number of alternatives
are involved; however, it should be the last item in any branch in which it appears. The dollar sign
has no special meaning in a character class. Regular expressions use two metacharacters to
represent the beginning and end of the string pattern.
This policy, for example, looks for a URL ending with anything but .html and denying it:
<proxy>
url.regex=!\.html$ DENY
The policy is of very limited applicability but shows how you can create more powerful CPL code.
Regular expressions in the CPL actions redirect(), rewrite(), and rewrite() are
anchored.
82
Property
Using *, +, and ?
a*
Matches if the target contains zero or more a
bluecoat* matches www.bluecoatttc.com
a+
Matches if the target contains one or more a
x+ matches www.xxx.com
a?
Matches if the target contains zero or one a
blue-?coat matches bluecoat or blue-coat
6OLGH8VLQJ DQG"
The ProxySG allows you to match patterns when they repeat from zero to any number of times.
You can use the metacharacters described below to create complex policies. Note that the
metacharacter affects only the character immediately to the left of itself. If you want the
metacharacter to affect more elements in the pattern, you need to use grouping, which is described
later in this chapter.
Asterisk (*)
The asterisk (*) causes its resulting regular expression to match zero or more repetitions of the
preceding regular expression.
Example: bluecoat* matches www.bluecoat.com. The asterisk operates only on the letter t
because it is the smallest previous regular expression. No grouping was indicated within the
string bluecoat.
Plus Sign (+)

The plus (+) causes its resulting regular expression to match one or more repetitions of the
Example: x+ matches www.xxx.com. It does not match www.bluecoat.com. The purpose of the
plus sign in this example is to match as many consecutive x characters as possible anywhere in the
string.
Note:
The asterisk and the plus sign are called greedy metacharacters because they try to
match as many repetitions as possible.
Question Mark (?)

The question mark (?) causes its resulting regular expression to match zero or one repetitions of the
83
Example: blue-?coat matches www.bluecoat.com or www.blue-coat.com. It does not

match rex.com. The purpose of the question mark in this example is to match exactly zero or one
dash characters (-) in the target string.
Examples
You can create the following policies using the newly introduced metacharacters:
<proxy>
url.regex=!\.html?$ DENY
url.regex=^http://.*/training/ DENY
The two rules above can be translated in English like this:
The first policy denies access to any URL that does not end with htm or html. For instance you
can access http://www.bluecoat.com/resources/techbriefs/index.html but not http://www.bluecoat.
com/downloads/support/tb_skype.pdf. Note that this policy is very limiting; most Web sites use
style sheets and other advanced objects, which are in essence pages not ending with .html or
.htm; as a result, most pages will not display properly.
The second policy denies access any URL that starts with http://, followed by any number of
characters, and then /training/. You can access http://training.bluecoat.com but not
http://www.bluecoat.com/resources/training/index.html.
84
Property
Character Sets [a-z]

[123]
Matches www1.bluecoat.com
Does NOT match www.bluecoat.com
[a-z]+
Does NOT match 123
0x[0-9a-f]+
Matches 0x20 (Hex value for space)
6OLGH&KDUDFWHUVHWV
Character sets can be very useful in regular expressions. Enclosed in square brackets, characters
can be listed individually, or a range of characters can be indicated by giving two characters and
separating them by a -. Ranges operate in ASCII collating sequence. Ranges can also be used for
characters specified numerically, such as [\000-\037].
Special characters are not active inside sets. Some examples follow:
[akm$] will match any of the characters a, k, m, or $ as a literal character.
[a-z] will match any lowercase letter.
[a-zA-Z0-9] matches any letter or digit.
Character classes such as \w or \S are also acceptable inside a range. If you want to include a ] or
a - inside a set, precede it with a backslash.
Characters not within a range can be matched by including a ^ as the first character of the set; ^
elsewhere will simply match the ^ as a literal character.
85
Range Quantifiers {min,max}

\.[a-z]{2}$
Match www.bluecoat.com.sg
Does NOT match www.bluecoat.com
\.[a-z]{2,3}$
Match www.bluecoat.com.sg
Match www.bluecoat.com
Does NOT match www.bluecoat.business
6OLGH0LQLPXPDQGPD[LPXPUDQJHTXDOLILHUV
Curly braces are used in regular expressions to represent range qualifiers or repetition specifiers.
The expression {m,n} causes the resulting regular expression to match from m to n repetitions of
the preceding regular expression, attempting to match as many repetitions as possible.
The expression {m,n}? causes the resulting regular expression to match from m to n repetitions of
the preceding regular expression, attempting to match as few repetitions as possible.
Consider the following policy as an example:
<proxy>
url.host.regex=^www\.google\.[a-z\.]{2,6} DENY
The policy denies access to any URL that begins with www.google. and followed by anywhere
from two to six alphabetical characters. This allows you to cover all of the possible variations of
the Google regional domains (www.google.com, www.google.co.uk, www.google.it,
www.google.com.au, and so on).
86
Property
Grouping
[a-z][a-z][0-9]
Matches any two letters followed by a number
Only look for one occurrence of the pattern
^([a-z][a-z][0-9])+$
Matches the pattern two-letters-number one or more
times
6OLGH*URXSLQJSDWWHUQV
In order to construct complex regular expressions, you must group items to be matched together.
This may be as simple as concatenating parts to match or grouping items together in parentheses.
In this manner, very complex regular expressions can be constructed.
Patterns grouped in parentheses are often called subpatterns. Subpatterns can be nested as well as
captured using a back reference. (This is discussed later in this chapter.)
You can use the grouping to create a policy to control the maximum size of an object that you are
trying to download. This policy does not work for all objects and might not stop transactions
where the object is checked. It is nonetheless a good example of how to use grouping. The origin
content server declares the size of an object in the HTTP header Content-length. You can use
this example to limit the size of each object to 10,000 bytes (this is a very low limit):
<proxy>
response.header.content-length = 10000 ALLOW
response.header.content-length =! ^([0-9]){1,3}$ DENY
The first rule in the layer allows anything that is exactly 10,000 bytes, while the second rule blocks
anything which has more than four digits in the size. The second rule covers all sizes from 0 to
9,999.
87
Logical OR |
(proxy|cache)
Matches www.proxy.com
Matches www.cache.com
Bluecoat\.(com|net|org)
Matches www.bluecoat.org
Does NOT match www.bluecoat.it
6OLGH/RJLFDO25
The ProxySG allows you to create policies using the OR Boolean operator. The vertical bar (or
pipe) | is how the OR is expressed in a regular expression. As soon as the first match is made, the
other choices are not examined further in a given pattern. To match a literal |, use the escape
character, as in \|.
In the second bullet point in this slide, the dot is part of the pattern to be matched; there is, in fact,
the escape character immediately before the dot itself.
Using the OR operator, you can rewrite two of the policies that appear earlier in this chapter. For
example the policy limiting the maximum size of an object to 10,000 bytes becomes:
<proxy>
response.header.content-length =! (^([0-9]){1,3}$| 10000) DENY
The policy used to allow only files with the extension .html or .htm becomes:
<proxy>
url.regex =!(html|htm)$ DENY
88
Property
References
Use $(1) $(2) $(3) to reference the first, second, third,
etc expressions
Match any sentence containing the same two words
([a-z]+)\s+$(1)
The expression [a-z]+ is contained within parentheses
remembered in the back reference $(1)
6OLGH%DFNUHIHUHQFHV
In Perl regular expressions, a back reference is a combination of a backslash followed by a integer

equal to or greater than 1. A back reference captures the value of some previous regular expression
match. The combination \1 captures the closest match moving from your current position to the
left. Combinations with higher numbers refer to matches farther to the left. In the ProxySG CPL
implementation, back references have the format $( ); the first match is $(1), the second is
$(2), and so on.
A back reference matches whatever actually matched the capturing subpattern in the current
subject string, rather than anything matching the subpattern itself. So the following pattern
matches sense and sensibility and response and responsibility, but not sense
and responsibility:
(sens|respons)e and $(1)ibility

In the example above, the subpattern captured is contained within the parentheses at the
beginning of the pattern. It does not include the string e and between the closing parenthesis
and the back reference.
You can use back references for several policies. For example, you can get all requests for a certain
site and transform them to request a different site. Every time a user asks for any page at the site
http://www.bluecoat.com/techlabs, you redirect the request to the corresponding page at
http://techlabs.bluecoat.com. As used below, the backslash character (\) at the end of a line allows
single-line statements to be continued on subsequent lines.
<proxy>
url.regex=^http://www.bluecoat.com/techlabs/.* \
action.newlocation(yes)
define action newlocation
redirect (307,http://www.bluecoat.com/techlabs/(.*), \
http://techlabs.bluecoat.com/$(1))
end
89
Examples
https://www.google.com/(.*)
Matches everything after www.google.com/
Groups it and makes it available as reference
http://www.google.com/$(1)
Appends to www.google.com everything that was grouped
and referenced in the string above
6OLGH)LQDOH[DPSOHV
By placing part of a regular expression inside parentheses, you can group that part of the regular
expression. This allows you to apply a repetition operator to the entire group.
Only parentheses can be used for grouping. Square brackets ([]) define a character class, and
curly braces ({}) are used to represent range qualifiers or repetition specifiers.
Besides grouping part of a regular expression together, parentheses also create a back reference.
In the first example above, the goal is to match any character (.) zero or more times. The result is
held in parentheses as a group for later use as a back reference; in this case, $(1).
In the second example, everything found in the first example is appended to the end of the string.
90
Property
Chapter 6: Managing Downloads and Apparent Data Types
Sometimes the greatest business and security risks come from within an organization. Left
unchecked, the Internet can hurt productivity and expose companies to potential lawsuits,
especially when objectionable Web content is being accessed. And while most organizations have
taken steps to address the security threat posed by e-mail viruses, the problems arising from
employee Web browsing and downloading have not received as much attention.
As users download seemingly safe content such as music files, they can also unknowingly
download hidden viruses, Trojans, or malware. When you add the time and resources lost while
employees browse and download content, you can see that corporations simply cannot afford to
overlook the problems posed by user downloads.
In this chapter, you will learn how HTTP is used to send data over the Web. HTTP content types are
based on Multipurpose Internet Mail Extension (MIME) types, but MIME types are not unique to
HTTP. They originally were developed to deliver non-text e-mail attachments but now are used in
many other applications as well.
Content types are important because they can be used to identify the content and block a
download if necessary.
The process of transferring data over HTTP is relatively simple:
1.
The user agent requests the specific file using one of the allowed methods (most likely GET).
2.
If everything is correct in the request, the origin content server responds and specifies:
In the Content-Type header: The type of file being delivered (text, image,
application) and the subtype (such as jpeg or gif for images). For example, a
Content-Type of image/jpeg denotes a graphics file in JPEG format.
In the Content-Encoding header: The encoding of the data (such as identity, gzip, or
deflate).
Based on the URL, the Blue Coat ProxySG knows the file that is being requested, and it reads
the information in the response header as well as in the response data portion. As result, the
ProxySG can determine the type of file being downloaded using any of the following parameters:
file extension, declared content type, or file header.
91
HTTP Threats
Malicious software
Spyware, malware
Bandwidth
Large downloads can clog the network
Productivity
Most downloads are not business-relevant
6OLGH+773GRZQORDGWKUHDWV
The majority of viruses travel the Internet through e-mail; however, spyware, malware, and other
threats are often delivered via HTTP. Improvements in the protocol, and particularly
enhancements in user agents, make it possible to write harmful code that users can download,
completely unaware that they are doing so.
In addition, freeware and shareware software often contain hidden code that tracks information
about a user and can result in reduced machine and network performance. Downloading large
files can cause incremental network degradation.
A complete security policy should include tight control of the file types that uses can download
and the sources from which they can download. The best approach is to block executable files and
ActiveX controls. You also should create a whitelist of approved sites; this list usually includes
download sites for your anti-virus vendors, operating system vendors, and other suppliers of
critical software updates.
The rest of this chapter helps you understand how downloads over HTTP operate and how you
can use the ProxySG to control them.
92
Property
File Type Detection

File extensions
avi, bmp, jpg, etc.
HTTP content types
text/html, image/gif, etc.
Apparent data type
Initial bytes in a file
6OLGH)LOHW\SHGHWHFWLRQPHWKRGV
The ProxySG provides a high-performance and flexible way to create and enforce user download
policies. You can block by:
File extension types: For example, you can configure the ProxySG to block users from
downloading MP3 audio files.
HTTP content types: For example, you can configure the ProxySG to block all (or only some)
audio or image files.
Apparent data type: The apparent data type refers to special data located at the beginning of a
file that is used to indicate its type. The ProxySG scans these data files to determine whether
the special data is present.
You also can create policies that specify when and where downloads are blocked. For example,
you can block users from downloading video files from any news sites during work hours.
93
File Type Detection Ambiguity
6OLGH)LOHW\SHGHWHFWLRQDPELJXLW\
It is possible but not very likely that files are hosted on a server with the incorrect extension.
For example, it is possible that malicious Web sites host executable files but with an extension that
makes them look like another file type. Because, more often than not, the OCS declares the content
type of a file solely based on the files extension, you can get a mismatch between the actual file
and its content type. Your browser might even download a certain file with a content type that
matches the file extension. However, the file being downloaded could actually be something else.
For instance, you can save a PDF file on an Apache server and change the extension from .pdf to
.txt. When you attempt to download the file, the associated content type most likely is text/
plain.
This diagram shows a GIF image that was renamed from test.gif to test.txt and hosted on an
Apache Web server. When the UA issues a GET request for the test.txt file, the OCS generates a
response in which the header declares the content type as text/plain (as it should be for a .txt
file). If you take a close look to the packet capture, you can see how the data part clearly contains a
GIF file. (GIF files usually contain the value GIF89 as file header.) You can do the same with an
executable file. If your policies deny access to GIF files based solely on file extension or content
type, this particular file would be accepted because it does not match such policies.
The apparent data type, discussed in detail later, allows you to control file downloads using the
information in the file rather than the extension or the content type.
Each blocking scheme has its own advantages, and you might need to experiment to see what
works the best for you in your environment. While the apparent data type feature is 100%
accurate, it currently blocks only the following file types: Windows DLL and executable files,
ActiveX controls (.ocx), and Windows cabinet files (.cab). (You can block virtually any file type,
but this requires you to write policies in CPL.)
94
Property
Apparent Data Type

File types recognized based on the first 255 bytes of the
actual data
Example for use: Identify drive-by-installs
Executable with inaccurate MIME-type and extension
Support for:
HTTP
HTTPS
WebFTP
6OLGH$SSDUHQWGDWDW\SH
Apparent data type is a feature of the ProxySG that matches a file with its type by analyzing the
first 255 bytes of the actual data stream. Note that the ProxySG uses the file header only to
recognize a file type. Miscategorization is possible but rare. Pre-defined apparent data type
support is available for the following file types:
Windows .exe: Many executable content and self-extracting installers are distributed as .exe
files. The Windows executable format is a Microsoft standard format called PE (portable
executable format). The ProxySG, in addition to recognizing the Windows PE executable
format, recognizes other executable formats, such as LE (linear executable) and NE (new
executable). Although these are obsolete formats, Windows computers still are capable of
running these executables.
Windows .dll: These files also are PE-format files. They are similar to .exe files but do not have
a main() function and need other executable programs to load them.
ActiveX controls (.ocx): ActiveX controls are also PE-format executables that conform to
Microsofts COM (Component Object Model) standard. Spyware vendors use these controls
for drive-by installations on users machines. With low-security settings in the IE browser,
users might not even realize that spyware has been installed on their machines.
Windows cabinet files (.cab): This is a Microsoft archive format. By itself it is not a dangerous
format (it is not executable), but .cab archives are used for distributing ActiveX controls. If an
OBJECT block in an HTML page has reference to a .cab file in the CODEBASE parameter, IE
downloads the file, extracts the ActiveX component from inside it, and installs it.
The options in the apparent data type object identify data content associated with Microsoft DOS
and Windows executable files. When used in a deny policy, the purpose of this object is to deny
executable downloads and block drive-by installation of spyware. If you intercept SSL traffic,
using the ProxySG SSL Proxy feature, then apparent data type applies to HTTPS traffic as well.
Important: Apparent data type triggers are not supported for ICAP transactions.
95
Apparent Data Type Triggers

Apparent data type (predefined)
http.response.apparent_data_type = (executable, cabinet)
Custom defined data type
http.response.data.n.regex.qualifiers=string
Allows identification of virtually any file type
Works on first 255 bytes of file
6OLGH&3/JHVWXUHV
The http.response.apparent_data_type= trigger tests the apparent type of the HTTP

response data, based on examining the first 255 bytes of the file header. The syntax is:
http.response.apparent_data_type = value
where value is executable to test for a Windows executable file (.exe) or cabinet to test for a
Windows cabinet file (.cab). This CPL gesture is available in <cache>, <proxy>, <exception>
layers, and it applies to all HTTP transactions (proxy, refresh, pipeline).
Similarly, http.response.data= tests the first few bytes of HTTP response data. This trigger
causes HTTP to wait until the specified number of bytes of response data has been received from
the origin content server (or the end of file, whichever comes first). Then, those bytes are
compared to the regular expression on the right side of the condition.
Examples
Deny the request if the first few bytes of the response data indicate the file is probably a
Windows executable file.
<proxy>
DENY http.response.apparent_data_type = executable
Deny the request if the first few bytes of the response data indicate that the file is probably a
WMF file:
define condition BC_Response_Data_Pattern_wmf

http.response.data.4.regex.case_sensitive="^\xD7\xCD\xC6\x9A"
http.response.data.5.regex.case_sensitive="^.\x00\x09\x00\x00\x03"
end
condition=BC_Response_Data_Pattern_wmf FORCE_DENY
96
Property
Combining Features CPL

File extension
url.extension=.wmf
MIME types
response.header.Content-Type= "(application|image)/(x-|xms|x-win-|)(metafile|wmf)
Apparent data type
http.response.data.4.regex.case_sensitive=
"^\xD7\xCD\xC6\x9A"
6OLGH&RPELQLQJIHDWXUHV
This slide is a combined view of the three methods that the ProxySG makes available to you to
control file downloads. You can use all of them in combination for maximum protection and
accuracy.
As mentioned before, using file extensions is the least effective, or least accurate, method. Content
type is fairly reliable. Apparent data type offers the highest level of accuracy.
97
Apparent Data Types List

This page contains some of the apparent data types for the files that are most likely to represent a
threat to your clients and to your network. They are represented in hexadecimal format with few
exceptions. You can search on the Internet for more data types. Bear in mind that the ProxySG
supports data type recognition only for the first 255 bytes of the files header.
;;;; ".MSI" Microsoft installers

http.response.data.8.regex="^\xD0\xCF\x11\xE0\xA1\xB1\x1A\xE1"
;;;; ".gz" or ".gzip" a compressed file format

http.response.data.2.regex="^\x1f\x8b"
;;;; ".bz2" a compressed file format

http.response.data.10.case_sensitive="BZh91AY&SY"
;;;; ".RAR" a compressed file format

http.response.data.4.case_sensitive="Rar!"
;;;; ".ACE" a compressed file format

http.response.data.7.case_sensitive="**ACE**"
;;;; ".hlp" Windows help files

http.response.data.4.regex.case_sensitive="^\?_\x03\x00"
;;;; ".chm" Windows compiled help files

http.response.data.4.case_sensitive="ITSF"
;;;; ".wsh" Windows scripting host

fileshttp.response.data.12.case_sensitive="[ScriptFile]"
;;;; ".hta" Hypertext Application files

http.response.data.15.case_sensitive="HTA:APPLICATION"
;;;; ".wmf" Windows MetaFiles, note two patterns modern and windows v3
styles
http.response.data.4.regex.case_sensitive="^\xD7\xCD\xC6\x9A"
http.response.data.6.regex.case_sensitive="^.\x00\x09\x00\x00\x03"
98
Property
Chapter 7: HTTP Details
HTTP is a request/response protocol. The client is limited to a specific set of request methods and
the server has a well-defined set of response codes. This chapter looks at some of the HTTP 3xx
and 4xx responses to understand how they are used for redirection and authentication. This
chapter also reviews basic HTTP concepts and shows how cookies are used to keep track of state
throughout a session.1
There are many reasons for learning the ins and outs of HTTP. One of these is to learn how you can
redirect users to a Web page of your choice, regardless of the original URL. Many organizations
need to send out notices to their employees, ensure that employees see the corporate Internet
usage policy, or direct the employees first Web request to the corporate intranet Web site. HTTP
redirection enables administrators to meet these requirements.
HTTP authentication, on the other hand, enables administrators to guard protected content and
limit access to content or systems. This chapter looks at the two layers of HTTP authentication,
Web server authentication and proxy authentication, to learn their structure and uses.
Finally, this chapter discusses how cookies are used to provide state for the HTTP protocol, which
does not have a mechanism for remembering information from one request to the next. Basically, a
cookie is server information that is stored on the client. This information can be used by the server
to remember a users preferences, choices, or authentication state, or simply to track the users
visits. Cookies are not the demon that many have made them out to be; they actually can be useful.
The Blue Coat ProxySG uses redirection, cookies, and authentication details to provide
authentication in transparent proxy deployment mode.
1. Portions of this chapter are from RFC 2616. Copyright 1999, The Internet Society. All Rights Reserved.
99
HTTP Responses
Special HTTP response codes for redirection
Indicate the requested content is at another URL
Response header Location
Specifies to the browser where to find the requested
content
Special HTTP response codes for authentication
Specify credentials needed to access a resource
6OLGH+773UHVSRQVHV
HTTP 3xx status codes indicate that the user agent needs to take further action to fulfill a request.
The 302 and 307 status codes indicate that the requested content has been temporarily moved to
the new location. Because the location of the content is subject to change, no new permanent URL
is provided a temporary URL is provided in the Location header, but user interaction usually is
not required to retrieve the redirected content.
The 301 status code indicates that the requested content has been moved permanently and that
future references to the resource should use a URL returned in the message.
Because browser redirection behavior did not meet the original RFC requirements, additional 3xx
response codes were added in HTTP version 1.1.
HTTP 4xx status codes are used to notify the client that the request cannot be immediately fulfilled
due to a client-side issue. In this chapter, codes 401 and 407 are discussed. A 401 response indicates
that the origin content server requires authentication; a 407 response indicates that the proxy
requires authentication. Either code can be a response to a request that either contains no
credentials or contains incorrect credentials.
100
Property
301 Moved Permanently
6OLGH0RYHG3HUPDQHQWO\
The 301 response code indicates that the requested content has been moved permanently. For
instance, you might receive a 301 response if you request a file that has been moved to another
server. The Location field of the 301 response should contain the new permanent URI. Clients that
have link-editing capabilities should be able to automatically relink references to the Request-URI
to one or more of the new references returned by the server.
However, if the user agent receives a 301 response in response to a request other than GET or
HEAD, it must not automatically redirect the request unless the user can confirm it. That is
because redirecting the request may change the conditions under which the request was made.
According to RFC 2616, some HTTP version 1.0 user agents, when automatically redirecting a
POST request after receiving a 301 status code, erroneously change it into a GET request. Unless
the request method was HEAD, the 301 response also should contain a message and a link to the
new URI(s). This allows the user to access the content if the browser does not redirect the request
automatically to the resources new location.
In the above diagram, when a user receives a 301 response:
1.
The user asks for http://www.somesite.com/page.htm.
2.
The OCS responds, notifying the client that the requested URL was permanently moved to
http://www.someothersite.com/newpage.htm.
3.
When the user again requests http://www.somesite.com/page.htm, the client connects directly
to the newer location http://www.someothersite.com/newpage.htm.
The client does not have to ever connect back to http://www.somesite.com; it can directly connect to
the new URL location, http://www.someothersite.com/newpage.htm.
101
302 Found
6OLGH)RXQG
The 302 Found status code indicates that the requested content is temporarily located at a different
URL. Because the location of the content may continue to change, the client should use the request
URL for future requests.
The 302 Found code was called Moved Temporarily in HTTP version 1.0. The reason for the name
change will become clear as you learn more about the 303 and 307 status codes. Basically, the
modification of some 3xx codes and the introduction of new codes in HTTP version 1.1 were
intended to clarify browser redirection behavior.
In this case, the temporary URL should be provided in the Location field in the response.
However, only GET and HEAD requests should initiate automatic browser redirection to the new
content. The response should contain a short note with a link to the new location so the user can
access the content if browser redirection is not automatic.
In the above diagram, the behavior is as follows:
1.
The client sends a request for http://www.somesite.com/page.htm.
2.
The OCS responds, notifying the client that the requested URL was found at
http://www.someothersite.com/temppage.htm.
3.
When the client again requests http://www.somesite.com/page.htm, the client must first connect
to the requested URL to determine whether the original URL still responds with a redirect to
http://www.someothersite.com/temppage.htm or whether the content is now available again at
http://www.somesite.com/page.htm.
102
Property
307 Temporary Redirect

Very similar to HTTP 302
Added in HTTP/1.1 RFC
Clarifies some issues with HTTP 302

Clients cannot change the method on redirected requests
User agents were issuing a GET request regardless of the
original request method
303 and 307 added to make reaction of the client

unambiguously clear
6OLGH7HPSRUDU\UHGLUHFW
Although RFC 1945 and RFC 2068 specify that clients are not supposed to change the request
method, most browsers read the temporary URL listed in the Location header of 3xx responses
and issue a new GET request for the content in that location, regardless of the original request
method. This is the browser redirection problem that led to the 302 name change. HTTP version
1.1 introduced the 303 and 307 codes to clarify and enforce the expected RFC behavior.
The 307 Temporary Redirect status code indicates that the requested content has been temporarily
moved. Because the redirection is temporary, the client should continue to use the original URL
for future requests. This response is only cacheable if indicated by a Cache-Control or Expires
header field. The temporary URL should be provided in the Location field in the response.
Unless the request method was HEAD, the response should contain a short note with a link to the
new location (particularly because the 307 code is new for HTTP version 1.1 and earlier browsers
might not understand the method).
The 307 status code is very similar to the 302 code. The HTTP specification includes two codes that
are essentially the same because popular Web browsers did not implement the 302 behavior as
specified in the HTTP version 1.0 RFC; instead, they behaved in a manner consistent with the 303
status code. That is, browsers automatically initiated a new GET request for the redirected content,
even if the original method was not a GET or HEAD request (which is contrary to what the RFC
states). Because browsers still respond to a 302 with the incorrect behavior, the 303 and 307 status
codes were introduced to enable administrators to enforce the RFC behavior.
103
401 Unauthorized
6OLGH8QDXWKRUL]HG
Web servers issue the 401 Unauthorized code to clients attempting to access protected content
without the proper authorization credentials. If the request already included authorization
credentials, then the 401 response indicates that authorization has been refused for those
credentials. The 401 response must include a WWW-Authenticate header. The
WWW-Authenticate response header consists of at least one challenge that indicates the
authentication scheme. Often, the 401 response triggers the browser to prompt the user for a
username and password.
The client caches user credentials separately for each requested resource. For example, the
browser cannot use the credentials cached for a 401 Authentication request from one Web site to
respond to a 401 challenge from a different Web site.
In the example above, before a 401 response is sent:
1.
2.
The user asks for a URL.

a.
The OCS requests authentication from the client.
b.
The user agent issues the same HTTP request but adds the requested credentials.
The user asks for a different URL.

a.
The OCS requests authentication from the client.
b.
The user agent issues the same HTTP request but adds the requested credentials.
Note:
The credentials used for one origin content server cannot be used for another OCS but
can be cached if connecting back to the same URL.
104
Property
HTTP 407
6OLGH+773
The 407 Proxy Authentication Required code is used to authenticate clients to a proxy. The proxy
must return a Proxy-Authenticate header field containing a challenge applicable to the proxy for
the requested resource. The client may repeat the request with a suitable Proxy-Authorization
header field.
The 407 message is usually sent by the proxy after receiving a client request that does not have the
proper authorization credentials.
In the example above:
1.
2.
The client asks for a URL; this is the first connection to the ProxySG for that browser instance.
a.
The ProxySG responds, asking for authentication.
b.
The client requests the same URL but adds the credentials requested.
The user asks for a second URL within the same browser instance. Because it knows of the
ProxySG, which requires authentication, the client issues the request using the necessary
credentials.
105
Cookie Fundamentals
Need to carry information across session
Cookies are a way to create stateful sessions with HTTP
requests and responses RFC 2109
Originally defined by Netscape
Formalized in
RFC 2109 of 1997 (obsolete)
RFC 2965 of 2000 (current)
6OLGH&RRNLHIXQGDPHQWDOV
HTTP is a stateless protocol, which means that it does not keep track of information from one
request to the next. Cookies were created to keep track of such user information that is, to
maintain state throughout HTTP sessions. As RFC 2965 states, cookies can enable stateful
sessions that might be used to create, for example, a shopping cart, in which user selections can
be aggregated before purchase, or a magazine browsing system, in which a users previous
reading affects which offerings are presented.
Cookies were first introduced by Netscape in 1994 and codified by the Internet Engineering Task
Force in RFC 2109. That RFC was superseded by RFC 2965, which describes the current cookie
standards.
Sessions in which cookies are used have the following key attributes:
1.
Each session has a beginning and an end.
2.
Each session is relatively short-lived.
3.
Either the user agent or the origin server can terminate a session.
4.
The session is implicit in the exchange of state information.
106
Property
Cookie Fundamentals
A server sends a cookie to a browser with its response, requesting that the browser include the
cookie in all subsequent requests to the server. The next time the user visits the Web site, the
browser includes the cookie information in the request header. When the Web server receives the
cookie, it is able to track the user and present that users information and/or personal settings.
The above diagram illustrates the cookie setting process:
1.
The client requests content from the server.
2.
The server responds with the requested content. The response includes a Set-cookie
header that contains some type of user-specific value.
3.
The clients next request includes a Cookie header with the value specified by the server in
Step 2.
The state information usually is not contained in the cookie; the cookie includes information that
points to a database entry containing the information.
107
Cookie Fundamentals
Set-Cookie: PREF=ID=c295f06bd13033fd:
TM=1111377507:
LM=1111377507:
S=bL0B-I8g3qIBK1Cs;
expires=Wed, 21-Jul-2010 02:10:51 GMT;
path=/;
domain=.google.com\r\n
This figure shows a typical Set-Cookie transaction. The Set-Cookie header is sent only if the
server wishes the browser to store a cookie. The Set-Cookie line instructs the browser to store
the specified cookie name and value so that it can be sent to the server in each subsequent request.
If the browser supports cookies and cookies are enabled, every successive page request to the
same server contains the cookie.
In addition to setting the cookie name and value, the server can set the cookie expiration date, a
path, a domain name, and whether the cookie is intended only for encrypted connections. The
domain command specifies the servers that are allowed to set or read cookies. The path attribute
further restricts the pages that require a cookie to be sent back to the server. The browser does not
send the cookie for any pages outside the specified path.
A path specified as / indicates that cookies must be sent for requests to the entire domain. If a
path or domain is not specified, the browser assumes the domain and path strings are the same
as those specified in the request.
The Set-Cookie header has the syntax Cookie-name=Cookie-value. Can you identify the
name of the cookie and its value in the slide above?
Note:
Any response with a Set-Cookie header is treated as non-cacheable by the ProxySG.
108
Property
Cookie Security
Protocol security
Cookie accepted only f or the source domain
Cookie sent only to the domain and resource
for which they were accepted
Browser implementation
Cookie jars are separate per user
Expiration date control
6OLGH&RRNLHVHFXULW\
A server can set cookies only for its own domain. That is, a server in www.foo.com can set a cookie
for foo.com and www.foo.com but not for www.user.foo.com (unless otherwise specified in the
domain attribute). Clients send cookies only to the domain and resource for which they were
accepted.
If a computer has multiple browser types, each browser has its own list of cookies. (This list is
called a cookie jar.) Thus, if a user visits a Web site using Firefox and then visits it again using
Internet Explorer, the Web server does not recognize the user because the IE browser does not
have a cookie for that site. In this case, the server sets a new cookie on the IE browser. By the same
token, if a browser has multiple user accounts, there is a separate set of cookies for each user.
A cookie stays on the users browser until it expires. If an expiration date is not specified, the
cookie is removed once the user quits the browser. Most browsers now allow users to delete
cookies, refuse them, or set explicit expiration times.
109
110
Property
Chapter 8: Authentication In Transparent Proxy Mode
This chapter discusses the complex details of authentication for transparent proxy deployments
on the Blue Coat ProxySG. You should already be familiar with how the ProxySG authenticates
users when it is deployed in explicit mode.
In essence, HTTP has a detailed provision for authenticating users when the requests are explicitly
sent to a proxy (HTTP 407 response code sent by the proxy to the user agent). But there is no
provision for proxy-based authentication when the proxy is deployed in transparent mode (when
the user agent is not aware that it is talking to a proxy).
HTTP offers only two authentication options:
401 Authenticate: Used by Web servers to require authentication before serving specific
content.
407 Proxy Authorization Required: Used by proxy servers to authenticate user agent requests.
Because 407 is not an option in a transparent proxy deployment, the ProxySG can only issue a
401-style authentication challenge, but the 401 authentication is resource-specific. From the user
agent point of view, a successful authentication to an HTTP 401 response is valid only for the URI
it originates from.
For example, if the user agent receives a 401 challenge from http://www.cnn.com and successfully
authenticates, that authentication token is valid and is reissued only for the www.cnn.com domain.
When the user agent makes a subsequent request to http://www.google.com, if it receives an HTTP
401 response it does not send the information it has cached for the www.cnn.com Web site; the user
agent challenges the user again for credentials.
The ProxySG needs to cache the authentication information that it can gather from the response to
an HTTP 401 challenge. Because this type of authentication is resource-specific, the ProxySG
redirects the requests to a virtual URL. If the user agent can successfully authenticate against the
virtual URL, then the ProxySG can allow the connection request to the intended URL. Because
redirection is transparent to the user, the authentication process does not appear any different to
the user from the explicit proxy authentication scenario. Only the user agent sees the process as
different.
111
Transparent Proxy Authentication

Proxy cannot challenge the user agent
HTTP 407 is ignored
Need to indirectly authenticate the user agent

Use HTTP 401 authentication
Cache authentication information

Avoid challenging the user agent multiple times
Blu e Co at Sy ste ms, In c. 2 01 0. All Rig ht s Reserved .
6OLGH&KDOOHQJHVLQWUDQVSDUHQWSUR[\DXWKHQWLFDWLRQ
When the ProxySG is deployed as a transparent proxy, it cannot use HTTP 407 to request
authentication information; the user agent does not believe that there is a proxy in the midst of the
conversation. Therefore, it rejects the request as invalid. The user experience is that the browser
immediately shows the authentication-failed exception page. The URL shown is that of the
requested origin content server:
The only alternative is to use the HTTP 401 response in order to trick the user agent into supplying
the authentication credentials.
Because HTTP 401 is a resource-specific authentication challenge, the ProxySG uses session-based
cookies or, alternatively, persistent cookies to cache the authentication information and not
challenge the user agent for authentication.
112
Property
Authentication Surrogates
Redirection
401 can authenticate only one resource at a time
Cookie surrogate
Successful authentication associated to a cookie
IP surrogate
Success authentication associated to the
IP address of the UA
6OLGH$XWKHQWLFDWLRQVXUURJDWHV
Based on the constraints of the HTTP authentication specification and the nature of the
transparent proxy approach, the ProxySG needs to use some artificial method to remember
whether a user already has been authenticated.
The ProxySG uses the concept of surrogates. The idea is to assign the authentication flag
(authenticated or not authenticated) to a surrogate; because a TCP session is not a viable option,
the only alternatives are cookies and IP addresses. Each presents advantages and challenges.
First and foremost, the ProxySG needs to redirect all requests to a common site where
authentication can be verified. Again, remember that HTTP 401 authentication is resource-specific.
By redirecting all requests to a common resource before delivery to the requested URI, the
ProxySG has a chance to authenticate or verify that authentication already has taken place.
The ProxySG identifies the common URL where requests are being redirected as the virtual URL.
By default, the virtual URL is set to http://www.cfauth.com. In general there should not be any
reason to change it; however, this parameter is fully configurable, and you can set it to any other
URL that meets the following criteria:
Every client can properly DNS-resolve the virtual URL to an IP address.
No client should ever need to access the virtual URL.
The virtual URL must resolve to an IP address because, in transparent proxy deployments, the
browser does a DNS lookup on the destination URL. If the virtual URL does not DNS-resolve to an
IP address, the browser sends the user an error message saying that the remote host (in this case,
the virtual URL) is not available. Finally, the virtual URL is not reachable by the user population.
The ProxySG traps all requests to the virtual URL and tries to use those requests to authenticate
the request. If you try to access the virtual URL from the browser directly, you end up in
something similar to an infinite loop. Because all requests are first redirected to the virtual URL
and then to the intended URL, if the final destination URL is the virtual URL itself, you can
immediately see where the issue is.
113
After the ProxySG performs the redirection to the virtual URL and the HTTP 401 authentication
takes place, the ProxySG needs to associate the successful authentication with a surrogate.
If you allow cookies in your enterprise, cookie surrogate is a viable option. Even if you allow the
use of cookies in your enterprise, you still need to be aware that if individual users set their user
agents to reject cookies, they will face authentication issues. Similarly, there are several
HTTP-based user agents that do not support cookies and do not have a provision to support
cookies. In this case, you need to find some workaround or use origin IP redirect.
Origin cookie redirect has the following advantages:
Cookies can be session-based; as soon as you close all instances of your browser, you need to
authenticate again.
It is very unlikely that one session may be attributed to a user other then the actual one.
It supports Citrix XenApp environments.
Origin cookie redirect has the following disadvantages:
Cookies are not always allowed by enterprise policies.
Individual users can disable cookies in the user agent.
Not all user agents are cookie-enabled.
Multiple redirections take place per each user request.
Origin IP redirect is the alternative to using cookies as surrogates. In this case, the ProxySG
associates the successful authentication to the IP address of the client from where the request is
coming. An IP surrogate is conceptually much easier and lightweight than a cookie surrogate.
However, the main disadvantages of IP surrogates are:
Authentication credentials are associated to the same IP address for the preset TTL time; if
multiple users log in from the same IP, they cannot be separated.
Requests coming from a NATed IP address are all associated to one user.
They do not support Citrix XenApp environments.
The main advantage of IP surrogates are:
Reduced number of redirects.
They work in all environments.
They support user agents that are not cookie-enabled.
114
Property
Cookie Surrogate First Authentication
6OLGH&RRNLHVXUURJDWHILUVWDXWKHQWLFDWLRQ
This diagram shows the sequence of actions that are necessary when a user is first challenged for
authentication in a transparent proxy deployment. The next two diagrams show the steps for
further user requests after the first authentication challenge, and what happens when a user
accesses a site that was already visited after the initial authentication.
Note:
This diagram shows the interaction for an LDAP realm. NTLM authentication
requires more steps because of its challenge/response nature.
The authentication proceeds as follows:

1.
The user agent makes a request for the URL http://www.bluecoat.com; note that the GET
request is not proxy-style.
2.
The proxy replies with a redirection request to the virtual URL. The additional query string
contains a reminder of what the original request URL was. The redirection request appears to
the user agent as coming from http://www.bluecoat.com.
3.
The user agent DNS-resolves the IP address of the virtual URL and attempts to connect.
4.
The ProxySG returns an HTTP 401 response to the user agent. As far as the user agent is
concerned, the request is coming from the virtual URL.
5.
The user agent reissues the same GET request, this time including the authentication
credentials, Base64 encoded. The credentials, if you use basic authentication, are passed in
clear text (just Base64 encoded); this is not a behavior of the ProxySG but a feature of HTTP.
6.
The authentication credentials supplied by the user agent are validated by the authentication
server.
115
7.
The ProxySG returns a new redirect request to the user agent. At this point, because the
authentication was successful, the ProxySG is trying to place a cookie for the originally
requested URL (in this case http://www.bluecoat.com). The user agent is being redirected to the
original URL; however, the ProxySG included a query string that contains information about
the successful authentication. The response also includes a Set-Cookie header. This request
appears to the user agent as coming from the virtual URL. Therefore, by placing an
authentication cookie for the virtual URL, the ProxySG creates a way to remember that the
user has already authenticated when a new site is being requested. See the diagram on the
next page for more details.
8.
The user agent opens the connection to the original URL; note the additional query string that
is included.
9.
The ProxySG returns a final redirection request with a Set-Cookie header. This request
appears to the user agent as coming from the http://www.bluecoat.com URL. Therefore, by
placing an authentication cookie for the bluecoat.com domain, the ProxySG has a way to
remember that the user has already authenticated when this domain is requested again. See
Slide 8-5 for more details.
10. The user agent performs the redirection. Because the cookie is received and accepted, the
request contains the authentication cookie. This cookie notifies the ProxySG that the request
already has been authenticated.
11. Finally, the ProxySG forwards the user agents request to the http://www.bluecoat.com URL
after it has removed the authentication cookie because it might interfere with the transaction.
116
Property
Cookie Surrogate Subsequent Requests
6OLGH&RRNLHVXUURJDWHVXEVHTXHQWUHTXHVWV
This diagram shows the interaction between the user agent and the ProxySG when the user agent
has already authenticated to the ProxySG but requests a different site from the one that was used
to authenticate. This diagram shows the requested URL as http://www.cacheflow.com; this is just a
sample transaction.
Important: A user agent is considered already authenticated if it can present a valid
authentication cookie when making a GET request to the virtual URL, as shown
in this diagram.
When a user agent is already authenticated, the ProxySG does not need to issue an HTTP 401
response. In the diagram above, Step 4 and Step 5 from the previous diagram are missing.
If this is the first time that the user agent is asking for this domain, it cannot present an
authentication cookie for that domain; for this reason, some redirections are still occurring.
117
Return to a Previous Site
6OLGH5HWXUQWRDSUHYLRXVVLWH
This diagram illustrates the simplicity of the authentication mechanism for requests to sites that
the user already has requested. If the user agent is able to present the valid authentication cookie
to the ProxySG, there is no need for the proxy to authenticate that request. Note that in this
diagram, there is no communication between the ProxySG and the authentication server.
In an environment using NTLM authentication with the Blue Coat Authentication and
Authorization Agent, you can actually see less load on BCAAA for transparent proxy deployment
than you would see in explicit mode. While at least in theory, a transparent deployment can put
the same load on BCAAA as an explicit deployment, this does not happen in practice. The
BCAAA load for NTLM is directly proportional to the frequency of new connections that need to
be authenticated.
For transparent deployments:
A surrogate credential is normally used. Authenticate.mode(origin) is rarely used in

forward proxies (it makes more sense in a reverse proxy). This reduces the frequency of new
connection authentications to one per surrogate expiration. The default expiration time is 15
minutes, which translates to one authentication request per browser every 15 minutes.
Most browsers talk to origin servers using HTTP version 1.1 by default. This enables the use of
persistent connections, which significantly reduces the number of new connections that have
to be authenticated.
For explicit proxies, authenticate.mode(proxy) is the default, so no surrogate is used. When

using explicit proxy, Microsoft Internet Explorer defaults to HTTP version 1.0, which does not
support persistent connections. As a result, many more authentication requests are sent to
BCAAA.
118
Property
IP Surrogate Authentication
6OLGH,3VXUURJDWHDXWKHQWLFDWLRQ
IP surrogates can be very useful in scenarios where cookies are not available or are impractical.
Often there are user agents that use HTTP as the protocol to communicate with a server; however,
these user agents do not support cookies. If an IT administrator needs to authenticate requests
coming from these user agents, IP surrogate is the only alternative.
The authentication credentials are associate with the IP address of the user agent; after a
custom-defined time to live (TTL) period, the authentication credentials are refreshed.
As long as the requests are made within the defined TTL, there is no further authentication. This
could lead to some requests being associated to the incorrect user. For instance, user A and user B
share the same machine but have two different login names. User A logs in and starts browsing; he
is challenged for authentication. If user B logs in to the same computer before the TTL for user A
expires, she is not challenged for authentication, and her traffic is recorded under user As login
name. This situation is infrequent, but you should be aware of it.
The above diagram shows how the transaction between the ProxySG and the user agent is
somewhat simpler, even for the first authentication request, than it was for the cookie surrogate
authentication. Delivering cookies is more complex than it might at first appear.
119
Transparent Proxy Settings

Origin cookie redirect
Session cookies
Persistent cookies
Define the time to live (TTL)
Origin IP redirect
Persistent IP
Define the TTL
6OLGH7UDQVSDUHQWSUR[\VHWWLQJV
You can define parameters in the Management Console relevant to transparent authentication
surrogate credentials.
You can select the transparent proxy method cookie-based or IP address-based. The default is
cookie-based. If you select Cookie, then cookie type choices are available. Click either Session, for
cookies that are deleted at the end of a session, or Persistent, for cookies that remain on a client
machine until the cookie TTL is reached or the credentials cache is flushed. The default is Session.
If you select Persistent, enter the Cookie TTL. If you choose IP address-based, enter the IP address
TTL. The default for each is 15 minutes.
A value of zero for the IP address TTL reprompts the user for credentials once the specified cache
duration for the particular realm has expired. For authentication modes that make use of IP
surrogate credentials, once the IP address TTL expires, the proxy rechallenges all client requests
that do not contain credentials for which an IP surrogate credential cache entry previously existed.
If at this point the client supplied a different set of credentials than previously used to authenticate
for which an entry in the user credential cache still exists the proxy fails authentication. This
is to prevent another client from potentially gaining network access by impersonating another
user by supplying the credentials of that user. However, once the user credential cache entrys TTL
has expired, you can supply a different set of credentials than the ones previously used for
authentication.
You can also control the name of the virtual URL. The default is www.cfauth.com. You should
change the virtual hostname to something meaningful to you, preferably the IP address of the
ProxySG, unless you are doing secure credentials over SSL. Using the IP address of the ProxySG
ensures that the correct ProxySG is addressed in a cluster configuration.
You can configure the same parameters using the CLI.
1.
At the (config) command prompt, enter the following command:

#(config) security transparent-proxy-auth method {cookie | ip}
120
Property
If you select cookie-based transparent proxy authentication, enter the following command
to specify persistent cookies or cookies that persist for the current session only:
#(config) security transparent-proxy-auth cookie {persistent
|session}
If you select persistent cookies, enter the following command to specify the minutes that
the cookie persists:
#(config) security transparent-proxy-auth time-to-live
persistent-cookie minutes
If you select IP-based transparent proxy authentication, enter the following command to
specify that the user be re-prompted for credentials after the number of TTL minutes
specified:
#(config) security transparent-proxy-auth time-to-live ip minutes
2.
To specify the virtual URL for cookie-based authentication, enter the following command:
#(config) security transparent-proxy-auth cookie virtual-url url
3.
(Optional, if you choose cookie-based) Add the virtual host domain to the DNS service for
your organization so that browsers, when redirected to the virtual URL, can resolve the
hostname in the URL. (If you use the virtual hostname provided by Blue Coat
www.cfauth.com you do not need to add the hostname to the DNS service.)
Important: The settings only affect the default method for authentication if you select
authentication mode to auto. You can force the use of cookie or IP surrogate
credentials in the VPM (or CPL), regardless of the settings detailed above.
121
Authentication Modes
Proxy
challenge
Origin
challenge
Form
challenge
Origin
challenge with
redirection
Form challenge
with redirection
TCP
connection
proxy
surrogate
origin
Cookie
surrogate
origincookie
formcookie
origin-cookieredirect
form-cookieredirect
origin-ip
form-ip
origin-ip-redirect
form-ip-redirect
IP
surrogate
proxy-ip
Explicit
proxy
Reverse proxy
Transparent proxy
6OLGH$XWKHQWLFDWLRQPRGHV
You can control the way the ProxySG interacts with the client for authentication by controlling the
authentication mode. The mode specifies the challenge type and the accepted surrogate credential.
Challenge type is the kind of challenge (for example, proxy or origin-ip-redirect) issued. Surrogate
credentials are credentials that are accepted in place of the users real credentials.
Auto: The default; the mode is automatically selected, based on the request. Chooses among
proxy, origin-IP, and origin-IP-redirect, depending on the kind of connection (explicit or
transparent) and the transparent authentication cookie configuration. For streaming
transactions, authenticate.mode(auto) uses origin mode.
Proxy: The ProxySG uses an explicit proxy challenge. No surrogate credentials are used. This
is the typical mode for an authenticating explicit proxy. In some situations, proxy challenges
do not work; origin challenges are then issued.
Proxy-IP: The ProxySG uses an explicit proxy challenge and the client's IP address as a
surrogate credential. Proxy-IP specifies an insecure forward proxy, possibly suitable for LANs
of single-user workstations. In some situations, proxy challenges do not work; origin
challenges are then issued.
Origin: The ProxySG acts like an origin content server and issues OCS challenges. The
authenticated connection serves as the surrogate credential.
Origin-IP: The ProxySG acts like an OCS and issues OCS challenges. The client IP address is
used as a surrogate credential. Origin-IP is used to support NTLM authentication to the
upstream device when the client cannot handle cookie credentials. This mode is primarily
used for automatic downgrading, but it can be selected for specific situations.
Origin-cookie: The ProxySG acts like an OCS and issues OCS challenges. A cookie is used as
the surrogate credential. Origin-cookie is used in forward proxies to support pass-through
authentication more securely than origin-ip if the client understands cookies. Only the HTTP
122
Property
and HTTPS protocols support cookies; other protocols are automatically downgraded to
origin-ip. This mode also can be used in reverse proxy situations if impersonation is not
possible and the OCS requires authentication.
Origin-cookie-redirect: The client is redirected to a virtual URL to be authenticated, and

cookies are used as the surrogate credential. Note that the ProxySG does not support
origin-redirects with the CONNECT method.
Note:
During cookie-based authentication, the redirect to strip the authentication cookie

from the URL is logged as a 307 (or 302) TCP_DENIED.
Origin-IP-redirect: The client is redirected to a virtual URL to be authenticated, and the client
IP address is used as a surrogate credential. The ProxySG does not support origin-redirects
with the CONNECT method.
Form-IP: A form is presented to collect the users credentials. The form is presented whenever
the user's credential cache entry expires.
Form-cookie: A form is presented to collect the users credentials. The cookies are set on the
OCS domain only, and the user is presented with the form for each new domain. This mode is
most useful in reverse proxy scenarios where there are a limited number of domains.
Form-cookie-redirect: A form is presented to collect the users credentials. The user is

redirected to the authentication virtual URL before the form is presented. The authentication
cookie is set on both the virtual URL and the OCS domain. The user is only challenged when
the credential cache entry expires.
Form-IP-redirect: This is similar to form-ip except that the user is redirected to the
authentication virtual URL before the form is presented.
Important: Modes that use an IP surrogate credential are insecure. After a user has
authenticated from an IP address, all further requests from that IP address are
treated as from that user. If the client is behind a NAT or is on a multi-user
system, this can present a serious security problem.
In the above table, the values that are underlined and in bold represent the authentication mode
that the ProxySG with factory default settings selects when auto is selected as the authentication
mode in a forward proxy deployment. In a reverse proxy deployment, however, the ProxySG
cannot easily distinguish between explicit forward proxy and reverse proxy requests. Blue Coat
recommends that you do not use the auto authentication mode in such a deployment; instead,
select the specific authentication mode that you prefer usually origin-cookie.
123
124
Property
Chapter 9: Using Kerberos Authentication
Kerberos is the default network authentication protocol used in Windows 2000 and later. On the
Blue Coat ProxySG, Kerberos authentication can be used in both transparent and explicit
deployments.
The system requirements and configuration necessary to support Kerberos authentication on

the ProxySG.
Steps required to configure the Blue Coat Authorization and Authentication Agent (BCAAA)
for either single-BCAAA or multiple-BCAAA operation.
How to configure an Integrated Windows Authentication (IWA) realm for Kerberos support
on the ProxySG.
How to verify that the user agent and the ProxySG have successfully negotiated and carried
out Kerberos authentication.
This chapter assumes that you are familiar with the basic concepts of Kerberos; a review of these
concepts is included as an appendix to this book.
Important: You cannot enable only Kerberos support in an IWA realm. An NTLM challenge
always is offered as a potential alternative to Kerberos.
125
Overview
Requirements
BCAAA processor version 100 or later
Internet Explorer 7.x or later, or Firefox version 3.x or later
SGOS 5.4.x or later for explicit proxy connections
Authentication modes
Auto
Origin-*-redirect
Origin-* (limited support)
Proxy-*
6OLGH2YHUYLHZ
Kerberos authentication is supported in SGOS versions 4.2.1.1 and later. In SGOS versions 5.4.1
and later, Kerberos authentication in explicit ProxySG deployments is supported.
When using an explicit proxy for Kerberos authentication:
The explicit proxy configuration on the browser must have a hostname that is resolvable to the
IP address of the ProxySG.
Internet Explorer versions 7.x and later and Firefox versions 3.x and later are supported.
BCAAA should be installed or reconfigured as a domain user for maximum flexibility.
An authentication mode of auto should work in most deployments and results in

origin-cookie-redirect for transparent deployment or proxy for explicit deployment. However, the
authentication mode can be specifically set if desired. Limited support is available for origin-*
modes. The ProxySG can only handle a non-redirecting origin mode if the request is to a hostname
for which BCAAA knows the secret. In a reverse proxy deployment, BCAAA can presumably
know the secret (because the ProxySG is impersonating the host with its permission). However
the, the ProxySG cannot impersonate an arbitrary host.
SGOS automatically downgrades the authentication mode to origin-* in a variety of situations,
typically because the client is not capable of handling the desired mode. For example, if the client
cannot handle redirects, origin-cookie-redirect is downgraded to origin-cookie (and might be
further downgraded to origin-ip if the client does not understand cookies). If the ProxySG has to
downgrade the mode from redirecting to non-redirecting, it assumes that BCAAA does not know
the servers secret and disables Kerberos (for that transaction at least).
Forms authentication modes cannot be used with an IWA realm that allows only NTLM/Kerberos
credentials. If a form mode is in use and the authentication realm is an IWA realm, then you
receive a configuration error.
126
Property
Installation Steps
For transparent proxy deployment:
Virtual URL (if origin-*-redirect used)
Define a suitable host name
Update DNS and WINS to resolve it to the ProxySG
Installation of BCAAA
Register the computer as SPN
Realm configuration
Create IWA realm
Supports Kerberos and NTLM
6OLGH,QVWDOODWLRQVWHSV
To use Kerberos authentication:

1.
If you are using a transparent proxy deployment, define the virtual URL for the IWA realm.
The virtual URL must be a simple hostname or a fully qualified domain name. It also must
resolve to the IP address of the ProxySG. Once you have selected a suitable name for the
virtual URL, create the necessary entries in your DNS and WINS servers.
2.
Register the SPN, and associate it with the BCAAA computer (or the account under which
BCAAA agent is running).
3.
Create and configure the IWA realm for Kerberos support. When upgrading legacy NTLM
realms from older versions of SGOS, Kerberos is disabled and must be enabled manually.
A virtual URL is not essential for Kerberos to work; one is needed only if origin-*-redirect modes of
authentication are required. For explicit proxy deployments, the SPN URL is the URL to which the
browser is configured to proxy traffic. Therefore, most of the configuration steps are the same as
for a transparent proxy deployment, but instead of using the SPN as the virtual URL, the SPN is
now configured in the browser.
To verify Kerberos settings in the Management Console, go to Configuration > Authentication > IWA
> IWA General, and choose the appropriate realm name from the list.
127
Single BCAAA
6OLGH6LQJOH%&$$$
If you plan to have only one BCAAA computer, then the SPN can be registered with the NetBIOS
name of the computer on which BCAAA is running. BCAAA runs under Local System (the default
for services) and uses the machines shared secret to communicate with the Key Distribution
Center and obtain tickets.
The primary advantage of this approach is convenience: It works with the default settings for
service installation. You just have to register the SPN for the machine. The disadvantage is that
you can have only one BCAAA server for the realm; you cannot have a backup server. This is
because the SPN is tied to the machine, and the browser chooses the SPN based on the URL that it
is fetching.
To set up the SPN, use this command:
> setspn -A HTTP/FQDN-of-virtualURL name

where FQDN-of-virtualURL is the fully qualified domain name of the virtual URL that was set
in the authentication realm and name is the name of the user account running BCAAA.
Note that the handling of the shared secret is done by Windows when the computer joins the
domain; there is no explicit knowledge of the shared secret by the ProxySG or by BCAAA.
128
Property
Multiple BCAAAs
6OLGH0XOWLSOH%&$$$V
You can have more than one computer running BCAAA. You can, in fact, have a primary and a
secondary BCAAA server.
Because an SPN can be associated only with one Microsoft Active Directory account, running
more then one BCAAA requires the agent to run as a domain user account rather then as a Local
System account. You also need to configure your DNS and WINS servers to resolve the virtual
URL to the IP address of the ProxySG.
The virtual URL that you specify for transparent Kerberos authentication cannot be an IP address.
The virtual host must appear to be part of the Kerberos realm. In other words, the virtual URL
must either have no dots, or it must be a fully qualified DNS name in the same domain as that
administered by the Active Directory server.
In this scenario, you need to create a service account for BCAAA and register the SPN on the
service account. This allows multiple servers to run BCAAA, all using the same account. Because
they are using the same account, they all know the shared secret, and any one can decrypt the
Kerberos ticket. The advantage of this scenario is the ability to have a backup BCAAA server. The
disadvantage is that additional configuration is required on the BCAAA computers. The scenario
is also slightly less secure because the BCAAA account password is shared among multiple
machines. The steps to configure this are (all steps require administrator privileges):
1.
Create a user account on the Active Directory server so that it can be used by BCAAA.
2.
Give the user account a password.
3.
Install BCAAA.
4.
Open the properties panel for BCAAA, and select the Log-on tab. Change the account name to
the one you created in Step 1, and enter the password. When you click OK, it might warn you
that the account has been given logon as service privileges.
5.
Verify in Local Security Policys User Rights Assignment folder that the above user account has
been added to the list of the Log on as a service policy.
129
6.
The user must have modify/write privileges in the BCAAA folder.
7.
If group-based authorization is being done, then verify that:
The user impersonation privilege is set for the SERVICE group.

The Active Directory computer account running BCAAA has the Trust computer for
delegation configuration property enabled.
8.
For users that are authenticating to the ProxySG using IWA realms, their user accounts in
Active Directory must have permission to log in to the computer on which BCAAA is
running. This is a setting on the users account properties. On the account tab, click Log On To
to specify the domain that computers can log in to. The default is All computers. However, if
your network is set up to restrict users to only log in to specific computers in the users list,
then each of those users also must have the hostname of the computer running BCAAA added
to this list.
9.
Run the command
> setspn -A HTTP/FQDN-of-virtualURL name

where FQDN-of-virtualURL is the fully qualified domain name of the virtual URL that
was set in the authentication realm and name is the name of the user account running
BCAAA.
All of these machines now share the same secret with the KDC and can decrypt service tickets
intended for the virtual URL as described by the SPN.
130
Property
Authentication Steps
6OLGH$XWKHQWLFDWLRQVWHSV
The above diagram shows the steps in Kerberos authentication:

1.
The client sends the ProxySG a request for a URL. The ProxySG checks for a surrogate
credential (either cookie or IP). If the surrogate credential is present and valid, then the request
is considered authenticated, and the ProxySG does not communicate with BCAAA.
2.
The ProxySG sends an authentication challenge to the client along with the Negotiate header.
Basic (if configured in the realm) and NTLM headers are also included, so that the browser has
a choice. (NTLM authentication cannot be disabled if Kerberos authentication is enabled in an
IWA realm. Basic authentication can be enabled or disabled.)
3.
The client decides to use Kerberos. It contacts the Key Distribution Center (KDC) on the
domain controller and requests a Kerberos ticket.
4.
The KDC sends the ticket to the client.
5.
The client resends its request to the ProxySG. The request now includes an Authorization
header and the Base64-encoded Kerberos ticket.
6.
The ProxySG sends an authentication request, including the Base64-encoded Kerberos ticket,
to BCAAA.
7.
BCAAA passes this request to the Windows API AcceptSecurityContext() to

authenticate the user. The Windows API decides whether the request is valid and returns the
value to BCAAA.
8.
BCAAA passes the result of the authentication to the ProxySG, which then sets a surrogate
credential as appropriate and replies to the client.
Also, independent of the above steps, BCAAA and the domain controller negotiate a shared key to
be used in authentication. If an authentication request is made without this key already existing,
the negotiation takes place. Then, once this key has been established, it can be used in subsequent
authentication requests from the ProxySG.
131
Kerberos authentication requires only one step (contrary to NTLM, where there are two
subsequent authentication responses from the server). By analyzing a packet capture, you can see
that only one response is sent back to the client by the ProxySG. If you can see two responses, then
the authentication has been downgraded to NTLM.
For any number of reasons, even if the user agent receives a response from the ProxySG that
contains the Negotiate header, the user agent can decide to downgrade to NTLM. The sole
presence of the Negotiate header does not mean that Kerberos will be used. It simply means that it
can be used.
132
Property
Authentication Summary
Authentication challenge
Origin-*-redirect style
Ticket request to KDC
Client requests a ticket for the virtual URL
Ticket decrypted by BCAAA
BCAAA machine has the virtual URL registered
as an SPN
ProxySG can only impersonate the virtual URL
6OLGH$XWKHQWLFDWLRQVXPPDU\
During a Kerberos-based authentication, these actions take place:
For a transparent proxy connection, the process starts when the ProxySG issues an
authentication request impersonating the virtual URL. The client believes that the response is
coming from the virtual URL.
The client, using the Ticket Granting Ticket obtained at login time, contacts the Ticket
Granting Service in the KDC for a ticket to gain access to the virtual URL. The virtual URL is
registered as a SPN and associated with the computer (or user account) where BCAAA is
running.
The ticket that the client receives from the KDC is encrypted with the session password shared
between the KDC and BCAAA. The client then sends the ticket to the ProxySG, which cannot
read it. The ProxySG passes the ticket to BCAAA; then, BCAAA can decrypt the ticket and
verify its authenticity and, therefore, grant access to the client.
It should be very clear at this point why the ProxySG can only impersonate one virtual URL: The
SPN associates one resource with one account.
Important: BCAAA does not need to communicate with the KDC to authenticate the users
credentials.
133
134
Property
Chapter 10: Advanced Authentication
This chapter discusses how the Blue Coat ProxySG determines which users are currently
logged in and how an administrator can manage these users.
You can run a query to find out which users are currently logged in to a ProxySG. The information
details which users are logged in from an IP address, or given a user, which IP addresses are being
used.
In general, multiple connections for the same user from the same IP address are considered a
single login. If that user then goes to a second computer and authenticates to the same realm, then
that would be considered a second login.
When it comes to the concept of logging users out, the meaning of logout can be vague. What
should happen if the user is downloading a file through FTP and streaming a video when they
click a logout link in their browser? Should the download and the stream be terminated? In other
words, should the semantics of a user-initiated logout be that all transactions for that user on that
IP address are immediately terminated, or should it be that in-progress transactions can complete
and new transactions must be authenticated? The ProxySG supports both cases through policy.
Another powerful feature of the ProxySG allows for better management of credentials and user
authentication. Administrators have control over how often a user is authenticated and to decide
when to force the user to type their username and password rather than just accept the browser's
cached credentials.
Some of the unique features and functionalities of the ProxySG are:
Better control over credentials: Administrators can require more frequent authentication if the
user is accessing critical resources. These features allows the administrator finer control over
how often the user is authenticated. The administrator has the option to ignore the cached
browser credentials and force the user to re-enter credentials.This is very important when you
need to control access to very sensitive resources, such as internal servers hosting private
documents.
User logout capability: The use of an IP surrogate can cause, in very rare and extreme
situations, one user to be mistaken for another. For example, if another person used a
computer before the credential cache entry expired for the previous user, the second user
would be treated as the original user. The logout feature solves this. Logout can be manual
(user or administrator) or automatic. If there has been no activity for a pre-determined amount
of time, then the user is automatically logged out.
Login control: Because it is possible to determine when a user is logged in, it is possible to
manage the number of logins allowed.
Authorization data refresh: The ProxySG allows authorization data to be invalidated

separately from authentication data. This allows the authorization data to be refreshed
without reauthenticating the user.
After studying this chapter, you will understand how authentication and authorization processes
work with the ProxySG.
135
Authentication and Authorization

Authentication
Determining the users identity. Includes obtaining
credentials and submitting them to authentication server as

needed.
Authorization
Determining which groups and attributes the identified user
has. Only determines those that are referred to in policy.
6OLGH$XWKHQWLFDWLRQDQGDXWKRUL]DWLRQ
When a user submits credentials (username and password) for validation, depending on the
authentication realm in use, the process of validating identity and the process of determining what
the user is authorized to do can be two separate processes.
Some realms, such as LDAP-based ones, allow an organization to build a very complex and
distributed environment for user authentication and authorization. The two processes can be
logically separate and can be performed at different times and on different systems.
On the other hand, realms such as IWA do not allow authorization and authentication to take
place separately; they have to happen at the same time.
The ProxySG supports a wide variety of realms; therefore, it is very important that at a logical
level, authorization and authentication are managed separately. This allows scalability and
increased functionality both in user management and realm support.
136
Property
Authentication and Authorization
6OLGH$XWKHQWLFDWLRQDQGSROLF\FRQWURO
The processes of authorization and authentication can be seen as two separate processes
happening at different times and even on different servers. While this is the most generic situation,
it is not the most common scenario.
Most of the realms and most implementations of authentication and authorization structures
perform the two processes at the same time and on the same server.
It is necessary for the ProxySG to manage the two processes as completely separate and
independent events. Regardless of the actual scenario, all of this happens behind the scenes and it
is completely transparent to the user.
The diagram shows the VPM and a policy where the source trigger is a user group. This is done to
point out how the ProxySG retrieves group membership information only when there is a policy
requiring such information. Unless you have the need to verify group membership for a user, the
ProxySG does not retrieve that information.
137
Authentication Model
6OLGH$XWKHQWLFDWLRQPRGHO
The ProxySG uses a complex authentication process that allows the appliance to decouple
authentication and authorization while supporting virtually any type of realm and credentials.
In order to maximize performance, limit interaction with authentication services, and enhance the
user experience, the process can be logically and functionally split into five steps:
1.
The client requests an object through the cache. The policy worker initializes a new session
and waits for the client to submit the requested credentials. The policy worker uses an HTTP
401 or HTTP 407 to ask for credentials, depending on the specific settings in the policy.
In an HTTP explicit proxy, the policy worker issues an HTTP 407 and adds specific realm
information. For example:
HTTP/1.1 407 Proxy Authentication Required

Proxy-Authenticate: NTLM
Proxy-Authenticate: BASIC realm="BC_Training"
This is also known as the authentication negotiation process.
For transparent proxy authentication as well as reverse proxy authentication, the policy
worker issues an HTTP 401 challenge with appropriate NTLM or Basic authentication
challenges. For example:
HTTP/1.1 401 Unauthorized

WWW-Authenticate: NTLM
WWW-Authenticate: BASIC realm="BC_Training"
A client (browser) window might pop up to prompt the user for credentials. (This is optional;
for example, this does not happen for IWA with NTLM or Kerberos credentials.) The
appropriate credentials are sent in an Authorization header in response to a 401 challenge,
or a Proxy-Authorization header in response to a 407 challenge.
138
Property
Note:
For Basic and transparent authentication, once credentials have been entered, the
browser can choose to automatically resend the credentials on later requests,
bypassing the need for a 401 or 407 challenge. But at least the first 401 or 407 challenge
to get the credentials is required. The ProxySG can be configured to force an
additional challenge later, even if the browser automatically provides cached
credentials.
2.
The policy worker calls the AAA worker, which first looks for the user object in one of its local
caches, such as the credential cache. The policy worker does not look for credentials in the
cache, nor does it manage the cache; the AAA worker performs both functions.
3.
On a cache miss, the AAA attempts to authenticate the user against the external
authentication service as determined by the realm information. Group membership
information is not always requested, but it can be, depending on whether it is requested in the
policy. The external authentication server sends the authentication response.
4.
Once the user is successfully authenticated, the credentials are cached (if caching for that type
of credentials is allowed). The information about successful authentication (or failure) is
passed to the policy worker.
5.
The policy worker passes the authentication information (or failure) to client or allows the
ProxySG to return the requested content (which could be an access-denied or exception page).
139
User Login Definition
6OLGH'HILQLWLRQRIXVHU
The diagram describes what can be a relatively common scenario, especially for certain users
(such as IT staff) who have access to multiple machines.
Bob is logged in to workstations with IP addresses 172.16.90.130 and 172.16.90.202. Mary is logged
in from the workstation at 172.16.90.124. Mary and Bob access a combination of HTTP and HTTPS
resources via a ProxySG.
There are two user IDs and three workstations logged in to the proxy. The ProxySG considers a
user to be a unique 2-tuple made of username and IP address. Therefore, the users in the system
are:
1.
(Mary, 172.16.90.124)
2.
(Bob, 172.16.90.130)
3.
(Bob, 172.16.90.202)
The following pages describe some other situations where surrogate credentials are used to make
a more significant difference in determining the number of users logged in to the proxy.
In case of this diagram, there are no devices between the user and the proxy that can alter or
masquerade the original source IP; in this scenario, the number of users logged in is always three,
regardless of the surrogate credentials used.
140
Property
Surrogate Credentials
6OLGH6XUURJDWHFUHGHQWLDOV
Unless you are in the very specific case of an explicit proxy deployment, there is no reference to
user credentials in an HTTP request.
After the authentication process, there is no surviving information in the further requests a client
is making. It is then necessary for a proxy, and also for an OCS requesting authentication, to
associate the successful authentication event and the corresponding user ID to some object or
property, generally called a surrogate.
There are three types of surrogates:
Connection: The authentication results are associated with the TCP connection between the
client and the proxy. When the connection terminates, authentication information is lost, and
the user needs to reauthenticate.
IP address: The authentication result is associated with the source IP address of the client
request. A time to live (TTL) must be defined for this type of surrogate. A shorter TTL means
that the user might be authenticated more often but there is less chance of incorrectly
identifying users. A longer TTL means that the user is authenticated less often but there can be
a higher chance of incorrectly identifying users.
Cookie: The authentication result is associated with a cookie. You can have session cookies or
persistent ones by setting a TTL. In either case, cookies are relatively secure because each user
profile, even on a shared computer, must have individual cookie jars. Once the user is
authenticated, the proxy sends a cookie. As long as the user agent presents a valid cookie to
the proxy, the user is not prompted for authentication.
Additionally, you can use IP address or connections surrogate credentials with virtually any user
agent, not just Web browsers. You can use cookie surrogates only with compatible user agents;
typically, this restricts the use of this type of surrogate to Web browsers.
141
User Data Refresh
6OLGH5HIUHVKXVHULQIRUPDWLRQ
While realms have the baseline settings for the different refresh times, policy and administrator
actions can override the realm settings. Using the same interface and filters as used for viewing
logins, the administrator can select logins and refresh the authorization data, the credentials, or
the surrogates using the links available on the user login information page. Refreshing user data
might be necessary if users are added to new groups or if there is concern about the actual identity
of the user on a long-lived IP surrogate.
Credential Refresh Time

You can set the credential refresh time with realms that can cache the username and password on
the ProxySG. This is limited to realms that use Basic username and password credentials,
including LDAP, RADIUS, XML, IWA (with Basic credentials), SiteMinder, and COREid.
Note:
The local realm uses Basic credentials but does not need to cache them because they
are already stored on the ProxySG.
You can use a cached username and password to verify a users credentials without having to
verify the credentials with the off-box authentication server. Essentially, this reduces the load on
the authentication server. For authentication modes that do not use surrogate credentials (proxy or
origin modes), this can greatly reduce traffic to the authentication server. The credential refresh
time value determines how long a cached username and password are trusted. After that time has
expired, the next transaction that needs credential authentication sends a request to the
authentication server. A password different than the cached password also results in a request to
the authentication server.
One-time passwords are trusted for the credential refresh time. Only when the credential refresh
time expires is the user challenged again.
142
Property
Surrogate Refresh Time

This value manages how long surrogate credentials are trusted in a particular realm. The
authentication mode determines the type of surrogate that is used:
Cookie surrogates are used with one of the cookie authentication modes.
IP address surrogates are used with one of the IP authentication modes.
Auto authentication mode attempts to select the best surrogate for the current transaction.
IP address surrogates work with all user agents but require that each workstation has a unique IP
address; they do not work with users behind a NAT. An IP surrogate authenticates all transactions
from a given IP address as belonging to the user who was last authenticated at that IP address.
When a user is logged out, all surrogates are discarded, along with the cached credentials and
authorization data.
Authorization Refresh Time

Realms that can do authorization and authentication separately (Local, LDAP, Windows SSO,
Novell SSO, Certificate, XML, and Policy Substitution) can use the authorization refresh time
value to manage the load on the authorization server. These realms determine authorization data
(group membership and attribute values) separately from authentication, allowing the time the
authorization data is trusted to be increased or decreased. For realms that must authenticate the
user to determine authorization data, the authorization data is updated only when the user
credentials are verified by the authentication server.
143
Inactivity Timer
6OLGH,QDFWLYLW\WLPHU
One of the difficult issues with the concept of logout with Web browsers is managing when users
are visibly challenged for their credentials. If form authentication is being used, there is no
confusion; every time the form is presented, the user is visibly challenged for credentials.
However, if HTTP authentication is used, the browser is allowed to cache the user credentials and
silently provide them to the server. If a user has logged out, future transactions should reject any
cached credentials and visibly challenge the user again in order to verify who is actually at the
workstation.
In order to visibly challenge the user for authentication when form-based authentication is not
being used, you need to use a cookie surrogate. You cannot use an IP address, nor you can use
session-based surrogates. Using cookies, you can visibly challenge the users if they are
authenticated using NTLM, Kerberos, or Basic credentials. The solution is only available for
transparent proxy authentication. The process works as follows:
1.
The main assumption is that if the ProxySG encounters a session cookie for a new user, this
means that the user was previously authenticated and that the browser is sending cached
credentials. In order to support this assumption, a session cookie is always set, even if
persistent cookies are configured (two cookies are set in this case).
2.
When the ProxySG rejects the cached credentials as expired, the cookie is modified and the
client receives an HTTP 401 message.
3.
The client resends the cached credentials. This time, they do not match what the ProxySG has,
so it can send back an HTTP 401 saying that the credentials are invalid. For both IWA and
Basic credentials, this forces the browser to visibly authenticate the user.
4.
The next set of credentials is accepted.
5.
The ProxySG validates the credentials with the server configured in the realm.
144
Property
Inactivity Timer: Connections
6OLGH,QDFWLYLW\WLPHUZLWKFRQQHFWLRQVXUURJDWH
This diagram shows a scenarios where the user is explicitly proxied and form-based
authentication mode is not being used.
After receiving an HTTP 407 response from the proxy, an explicitly proxied user agent always
adds the user credentials in every subsequent request. Additionally, most browsers cache the user
credentials for as long as the browser is running.
When the ProxySG expires (logs out) the user, it generates an HTTP 407 response and sends it to
the client. Without any user intervention, the user agent immediately responds to the 407
challenge with the cached users credentials. As a result, even if the user was logged out, unless
the browser session was terminated (the user killed all running processes for that user agent), the
user does not have to re-enter the authentication credentials.
In this scenario, logging the user out is mainly used to keep the license within the necessary limits.
145
Policy Conditions
6OLGH3ROLF\FRQGLWLRQV
The ProxySG has three conditions that you can use to manage logout and to create very granular
policies. These properties are:
user.login.count=: This condition matches the number of times that a specific user is
logged in to the current realm. You can use this condition to ensure that a user can be logged
in only at one workstation. If the condition is combined with the user.login.log_out_
other property, old login sessions on other workstations are automatically logged out.
client.address.login.count=: This condition matches the number of different users

who are logged into the current IP address, and you can use it to limit the number of users.
user.login.time=: This condition matches the number of seconds since the current login
started. You can use it to limit the length of a login session.
In the scenario shown in the above diagram, the administrator has made a poor selection of
surrogate credentials. Because there is a firewall with NAT between the users and the proxy, IP
address surrogate is the worst possible decision: It does not allow the ProxySG to discern between
users. All transactions are associated with the first user who was authenticated. Remember that
the ProxySG identifies a user as the 2-tuple (username, IP address).
In the above example:
1.
Bob, who is logged on at IP address 172.16.90.202, authenticates into the ProxySG. However
his IP address appears as 10.0.1.100 to the proxy because of the NAT taking place on the
firewall.
2.
The ProxySG associates the surrogate credential IP address 10.0.1.100 with Bob.
3.
Within the time frame of the TTL for the surrogate credential, Mary logs in from IP address
172.16.90.123. But her IP address appears as 10.0.1.100 to the proxy because of the NAT taking
place on the firewall.
146
Property
4.
While you might want or expect the ProxySG to be able to associate Mary as a new user,
because the IP address 10.0.1.100 is a valid surrogate credential, her traffic instead is
associated with Bob.
The user.login.count for Bob is 1, and the total client.address.login.count is 1. That

means that, according to the ProxySG, only Bob is logged in, and he appears to be logged in just
once.
147
Policy Conditions: Cookies
6OLGH3ROLF\FRQGLWLRQVZLWKFRRNLHVXUURJDWH
The ProxySG allows cookies to be used as surrogate credentials. Cookies are not impacted by the
presence of a device performing NAT and cannot be shared across user profiles, making them a
flexible and secure option for surrogates.
The scenario in the above diagram is the same as the previous example; however, in this case, the
administrator of the proxy has correctly decided to use cookie surrogates.
In this example:
1.
Bob, who is logged on at IP address 172.16.90.202, authenticates into the ProxySG. However,
his IP address appears as 10.0.1.100 to the proxy because of the NAT taking place on the
firewall.
2.
Bobs successful authentication is associated with an authentication cookie, which is sent to

his user agent as part of the authentication process
3.
Mary logs in from IP address 172.16.90.123. Her IP address also appears as 10.0.1.100 to the
proxy because of the NAT taking place on the firewall. However, this is not an issue. Mary has
not presented a valid authentication cookie, so she is prompted for authentication by the
ProxySG.
4.
Mary receives the authentication cookie after the proxy successfully validates her credentials.
The ProxySG can distinguish between the users Bob and Mary, even if they appear to come from
the same IP address. The user.login.count for Bob is 1, The user.login.count for Mary is
1, and the total client.address.login.count is 2.
148
Property
Chapter 11: Guest Authentication
For some enterprises, user authentication and authorization are desirable but not necessarily
required for users to access resources. In such cases, authentication and authorization should be
attempted, but some errors should be permitted such that a user request is allowed to proceed
even if the error occurs. There are numerous reasons why authentication and authorization could
fail, including invalid credentials and failure to connect to an external authentication server.
Administrators might want the ability to allow users transactions to continue after an external
server failure while at the same time terminating the transactions of users who offer invalid
credentials.
In addition to the ability to permit errors in authentication and authorization, administrators
would like a way to authenticate users as guest users and assign them to default groups. In some
scenarios, authenticating as a guest is only desired once authentication has been attempted and
failed. One such scenario would be users without intranet accounts logging in from public
workstations.
This chapter describes how the Blue Coat ProxySG provides administrators with a mechanism
to specify that a user transaction should be allowed to proceed instead of being terminated. The
chapter also details how administrators can specify that users be authenticated as guest users and
be assigned to default groups without having to set up guest accounts in their realms and having
users explicitly enter guest credentials.
The ability to permit authentication and authorization errors and the ability to login as a guest
user and be assigned to default groups can be used together or separately. Using policy (VPM
or CPL), you can allow a user to log in as a guest user. Guest authentication allows a username to
be assigned to a user who otherwise would have been considered unauthenticated.
In guest authentication, a user is not actually authenticated against the realm, but is:
Assigned the specified guest username.
Marked as authenticated in the specified realm.
Marked as a guest user.
Tracked in access logs.
Because the user is not actually authenticated, the username does not have to be valid in that
realm.
Before creating policy for guest authentication:
Determine the circumstances under which guest access is permitted. Guest users typically are
allowed in circumstances where no authentication is needed.
Determine authentication policy. Will an attempt to authenticate users fallback to guest

authentication, or will it authenticate users as guest users without attempting authentication?
Important: Guest authentication after an authentication challenge causes the client software
(browser) to believe that the credentials offered were valid. The browser
therefore again offers the cached credentials on a subsequent challenge even
though they might not be valid.
149
User Identification
Users without valid accounts
Access from public workstations
Vendors or other users without domain account
Authentication errors
Authentication server not available
Invalid realm configuration
Authorization errors
Authentication succeeds but no authorization data
available
6OLGH8VHULGHQWLILFDWLRQ
You can configure policy (VPM or CPL) to attempt user authentication while permitting specific
authentication or authorization errors. The policy can specify that after certain authentication or
authorization failures, the user transaction should be allowed to proceed and not be terminated.
Authentication and authorization can be permitted to fail if policy has been written to allow
specific failures. The behavior is as follows:
Authentication failures: After an authentication failure occurs, the authentication error is

checked against the list of errors that policy specifies as permitted.
If the error is not on the list, the transaction is terminated.
If the error is on the list, the transaction is allowed to proceed although the user is
unauthenticated. Because the transaction is not considered authenticated, the
authenticated=yes policy condition evaluates as false and the user has no username,
group information, or surrogate credentials. Policy that uses the user, group, domain, or
attribute conditions does not match.
Authorization failures: After an authorization failure occurs, the authorization error is

checked against the list of errors that policy specifies as permitted.
If the error is not on the list, the transaction is terminated.
If the error is on the list, the transaction is allowed to proceed and the user is marked as
not having authorization data.
If a user is successfully authenticated but does not have authorization data, the
authenticated=yes condition evaluates as true and the user has valid authentication
credentials.
The user.authorization_error=any condition is evaluated to true if user

authorization failed. The user object contains username and domain information, but not
group or attribute information. As a result, policy using user or domain actions still
matches, but policy using group or attribute conditions does not.
150
Property
Before creating policy to permit errors, you must:
Identify the type of access that the transactions should be permitted.
Identify under what circumstances transactions can proceed even if authentication or

authorization fails.
Identify which errors correspond to those circumstances.
151
Guest Authentication
Identify a user as a guest
Actual guest account on a backend authentication server
not required
Associate guest to a realm

User not actually authenticated against the realm
User appears as authenticated and authorized in the
specified realm
6OLGH*XHVWDXWKHQWLFDWLRQ
Guest authentication provides the ability to identify a user as a guest without having an actual
guest account on a back-end authentication server. A realm is specified to authenticate the guest
against, but it does not actually authenticate the user against the back-end authentication server.
Instead, it just determines the username using policy substitution evaluation as needed and marks
the user as authenticated and authorized in the specified realm.
Regular (non-guest) authentication has priority over guest authentication. If a transaction
encounters an authenticate() and authenticate.guest() condition, it attempts the
authentication first. If the regular authentication fails with a tolerated error, then the transaction
authenticates as the guest user.
Guest authentication can also be used by itself without any regular authentication properties
specified.
Using policy (VPM or CPL), you can allow a user to log in as a guest user. Guest authentication
allows you to assign a username to a user who would have otherwise been considered
unauthenticated.
Because the user is not actually authenticated, the username does not have to be valid in that
realm. If a transaction matches both a regular authentication action and guest authentication
action, regular authentication is attempted first. This can result in a user challenge before
dropping back to guest authentication. If you inadvertently enter invalid credentials and,
therefore, drop back to guest access, you must log out as a guest or close and reopen the Web
browser if using session cookies or connection surrogates. You then can enter the correct
credentials to obtain regular access.
Policy available for guest authentication includes authenticate.guest(), user.is_guest=,
and authenticated=.
You can also use default groups with any realm, and they can be used when authorization
succeeds, fails or was not attempted at all. Default groups allow you to assign users to groups and
use those groups in reporting and subsequent authorization decisions.
152
Property
You can use default groups in conjunction with guest users, or it can be used with regular user
authentication.
Before creating policy for default groups, you must determine which set of groups is assigned as
default. You can specify a single group or multiple groups. In most cases, only a single group is
required, but occasionally you might need to assign the user to multiple groups:
For extra reporting abilities.
If the policy is structured in a way that users should receive the same access as if they
belonged in multiple groups.
Policy available for default groups includes group= and authorize.add_group().
153
Tolerating Errors
6OLGH7ROHUDWLQJHUURUV
You might need to encourage all users to authenticate using valid credentials any time it is
possible to do so; however, you also might want the users to have access to many (if not all) of the
resources on the Internet if the authentication and authorization process fails.
The above diagram shows how you can configure the ProxySG to handle such errors. The options
(return error, proceed as guest, or proceed unauthenticated) depend on these triggers:
1.
The user initiates a transaction with the ProxySG that requires authentication. This is the first
time the user agent attempts to connect to this proxy. The proxy starts the authentication by
returning an HTTP 401 response (the details about transparent authentication are omitted to
keep the diagram simple). The user submits the credentials.
2.
The ProxySG may or may not connect to the remote authentication server (cached credentials
or authentication are not required for that transaction).
3.
The ProxySG processes the authentication and authorization response from the authentication
subsystem and passes it to the policy engine.
4.
Based on having configured the ProxySG to tolerate errors or not (and which errors are
tolerated compared to the ones resulting from the authentication of the current transaction)
the user might:
a.
Receive an error notifying the unsuccessful authentication or authorization.
b.
Be allowed to proceed either as unauthenticated user or a guest user.
If the transaction proceeds unauthenticated, then this process might happen again at the next
transaction. When the transaction proceeds unauthenticated, the ProxySG does not have a valid
user login object for that connection.
If the connection is allowed to proceed as a guest, then this process does not repeat. The user login
object indicates a guest, it is a member of the specified realm in the guest authentication rule that
was created, and it is a member of the groups that were defined in the policy. (Later transactions
can add to the list of groups using the authorize.add_group() property.)
154
Property
Managing Password Expiration
6OLGH0DQDJLQJSDVVZRUGH[SLUDWLRQ
This diagram shows how the ProxySG administrator can control authentication errors to do more
than just permit users to browse without having to submit valid credentials. This is an example
where the ability to tolerate errors largely improves the overall user experience.
For instance, you can use the ProxySG to enable users to change their password when it is expired.
You can allow the user to change their password in three steps:
1.
The user connects to the ProxySG and receives an authentication challenge; the user responds
by sending the appropriate credentials.
2.
The ProxySG validates the credentials with the authentication server; the server responds
with an error informing the ProxySG that the password has expired.
3.
Rather then simply returning an generic authentication failure error to the user, the ProxySG
redirects the user to a Web page where the password can be changed.
Entirely within the context of the proxy, the user is able to access the requested resource and
change the expired password.
155
Sample Policy
Redirect a user to a password change page after a
password expiration
; Authenticate users in the realm MyLDAP
<proxy>
authenticate(MyLDAP) authentic at e.tolerate_error(exp ir ed_credentials)
; If authentication fails due to expired credentials ,
; then invoke redirect_to_pass wo rd_change_page action
<proxy>
user.authentication_error=(exp ir ed_credentials) \
action.redirect_to_passwor d_ change_page(yes)
; Use HTTP 302 to redirect UA to password management Web interface
define action redirect_to_pass wo rd_change_page
redirect(302, .*, http://ourcompany.com/passw or d_change);
end
6OLGH6DPSOHSROLF\
The policy that was conceptually described on the previous page is implemented here using CPL.
There are three main components to the policy:
1.
A <proxy> layer (or Web Authentication Layer) where you configure the ProxySG to
authenticate the user in a realm called MyLDAP. At the same time, you also allow the proxy to
tolerate the expired_credentials error (combined object)
2.
A <proxy> layer (or Web Access Layer) where you execute the defined action
redirect_to_password_change_page if the users authentication error is
expired_credentials.
3.
A defined action (or Redirect Action object) called redirect_to_password_change_page

which returns an HTTP 302 response to the client and the header:
Location: http://ourcompany.com/password_change
156
Property
Canceling Login
6OLGH&DQFHOLQJORJLQSURPSW
At the beginning of a new connection between the user agent and the proxy, the first GET (or other
method) request is always anonymous. Only after the proxy returns an HTTP 407 (or 401 as
applicable), the user agent first prompts the user to submit credentials and then sends them to the
proxy.
The initial HTTP response from the ProxySG requesting authentication contains, in the data part, a
properly formatted HTML page. The page is not seen by the user if the user submits the
credentials. At the most the user sees a browser pop-up window to type the user name and the
password. The user sees the HTML page only if the browser resets or terminates the connection.
The easiest way to see the page is to click Cancel in the browsers pop-up window. This is
represented as Step 1 above.
If you want to control what happens after the user cancels the login, you need to modify the
HTML page, which the ProxySG sends with the HTTP 401 and HTTP 407. For instance, if you
want users who do not have an account (they are likely to cancel the login prompt) to proceed as a
guest, you need to embed a link in the first HTML page the ProxySG sends to the client. When the
user cancels the login, the page is displayed. The user can then click on the link. In the ProxySG,
you need to have a policy bypassing authentication for the landing page associated with that link,
and you also need to authenticate the user making the request to that landing page as a guest.
157
Best Practices
Carefully determine permitted errors
Advanced URL and access log fields to determine common
errors
https://proxyIPaddr:8082/Auth/Error
6OLGH%HVWSUDFWLFHV
The ability of the ProxySG to tolerate authentication and authorization errors is a very powerful
feature. However, when used incorrectly, it can lead to unwanted effects.
For instance, permitting the error group All, which includes the need_credentials error, results
in the user never being challenged and not being able to enter valid credentials. While this
behavior can be useful for single sign-on (SSO) realms that are not supposed to challenge, it can
cause unwanted behavior for challenged-based realms. Another common error is to specify the
incorrect error group or individual error to permit.
You can use the advanced URL https://proxyIPaddr:8082/Auth/Error or the access log fields
x-sc-authentication-error and x-sc-authorization-error to help determine which
errors are actually being encountered in various circumstances.
The above example shows the general_authentication_error section of the output from the
advanced URL. In this example, there is a relatively large number of errors compared to the
number of authentication attempts, and it is likely that there is some issue not related to the
deployment of the ProxySG. The administrator of this ProxySG might want to decide whether this
is an error that can be tolerated and, if so, write appropriate policy to do so.
Determine when guest access is permitted. If guests always log in from a specific subnet, then you
can likely just authenticate them as guest without challenging for credentials using the subnet as a
source trigger. If guest is to be used as a fallback only, then ensure that policy is written such that
the authenticate() and authenticate.guest() actions are matched.
158
Property
Troubleshooting
User never challenged
Permit Any Errors is the selected option
Verify policy for realms other then SSO
Incorrect users or groups permitted

https://proxyIPaddr:8082/Auth/Error
Use x-sc-authentication-error and
x-sc-authorization-error in access logging
6OLGH7URXEOHVKRRWLQJ
The advanced URL https://proxyIPaddr:8082/Auth/Error and access log fields are two of the best
resources for debugging. Access log records are useful for determining whether the user logged in
as a regular or guest user.
Policy traces are also very useful to determine which authentications were matched and which
errors were matched (you can use the user.authentication_error and
user.authorization_error conditions).
The ProxySG supports many authentication errors. You can browse the complete list via the CLI
using the show security authentication-errors command. A detailed description of the
individual errors is available at https://proxyIPaddr:8082/Auth/Error.
The VPM only contains the group of errors available for selection. Individual errors must be
specified in CPL.
Note:
An authenticate.guest() action can be matched but does nothing if the user is

already successfully authenticated.
159
160
Property
Chapter 12: SSL Proxy
HTTPS, which is simply HTTP over SSL, was designed to offer secure communication between a
client and a server. HTTPS has helped boost online commerce. But HTTPS also presents a
corporate security challenge; malicious internal users and Web sites can retrieve or distribute
inappropriate content over HTTPS.
For example, SSL can be used to distribute spyware and other malware. Because the content of an
SSL transaction is usually known only to the requesting client and the origin content server,
filtering software fails to detect it. Furthermore, a malicious Web site can deliver viruses over
HTTPS, making them completely undetectable to any gateway antivirus software.
The SSL proxy in the Blue Coat ProxySG terminates forward proxy connections, inspects SSL
traffic, determines whether the traffic is safe or approved, and then accepts or drops it. The SSL
proxy can be deployed in either explicit or transparent modes.
You might have privacy concerns about using this feature. To alleviate those concerns, you should
combine your SSL proxy deployment with Blue Coat WebFilter software and a local database. For
example, you can use WebFilter to create a policy that allows banking and investment firm traffic
to bypass the SSL proxy. You might also want to create custom lists of approved and suspicious
sites in the local database. Using this list, approved sites can bypass the SSL proxy and, conversely,
use the SSL proxy to inspect traffic from the suspicious sites.
This chapter contains a brief introduction to the fundamental concepts behind SSL.
You should become familiar with the following definitions:
Tunnel/tunneling: Forwarding data between client and server by the proxy.
Intercept/interception: Decrypting SSL connections at the proxy.
Certificate validation: Doing various checks on an SSL certificate. These checks include
verification of the issuer signature, dates, and revocation status.
CA: Certificate authority.
161
Overview
Secure Sockets Layer (SSL) provides an encrypted
tunnel through which other protocols can pass
SSL uses public-key cryptography to exchange a
symmetric key
HTTPS is HTTP over SSL
6OLGH2YHUYLHZ
HTTPS is the same protocol as HTTP. However, HTTPS is delivered over an SSL tunnel. Without
the correct session key, no part of the TCP payload can be viewed. SSL also is used for protocols
other than HTTP; it can be used for any application protocol that runs on TCP.
Once you have negotiated the session key over an asymmetric key, you open a secure tunnel using
a symmetric encryption algorithm. (The key used to encrypt is the same key used to decrypt.)
SSL provides end-to-end security between clients and servers. Security includes authentication of
both parties of the connection through certificates, information privacy using encryption, and
message-integrity mechanisms. SSL encryption strength can vary. 40-bit, 128-bit, and 256-bit
encryption are available. 128-bit encryption offers 288 (nearly 3.1 x 1026) times as many possible
combinations as 40-bit encryption.
SSL uses asymmetric keys to exchange a symmetric key over an insecure medium such as the
Internet.
To validate a Web sites identity and trustworthiness, SSL certificates are issued. SSL certificates
are issued for a single server in a specific domain and only for verified businesses. SSL
certificates are issued by a trusted authority, such as VeriSign.
162
Property
Certificate Authority
6OLGH&HUWLILFDWH$XWKRULW\
To have confidence that your information is secure, you need to trust the entities you interact with
on the Web. When you initiate an SSL transaction, the other party sends a certificate with their
credentials. You need to be able to validate the authenticity of the credentials with a separate
entity that you trust.
For example, in the case of passports, immigration officials trust that the passport authorities of
other countries have verified the authenticity of a travelers name and picture on the passport.
On the Internet, the role of the passport authority is filled by certificate authorities, which create
the digital certificates used by computers to prove their identity to other computers. CAs make
certificates available to everybody on the Internet. If you can verify a certificate by using the
corresponding CA certificate, you can trust the identity of the sender.
In the above diagram:
1.
The server must obtain a digital certificate and a key ring (private key and public key pair).
1b. The CA publishes its own certificate and public key to all clients so that clients can
authenticate the digital certificates from that CA.
2.
The client requests an SSL connection to the server.
3.
The server sends the digital certificate and the public key.
4.
The client validates the certificates using the information made available by the CA. (Note that
the client does not connect to the CA but maintains a database of trusted CA.)
Public and private key pairs are critical elements in securing the conversation. With the ProxySG,
you create a keyring that consists of a public key, which you can distribute to anybody, and a
private key, which you must protect and keep secure. Systems that use a pair of public and private
keys are often called public-key infrastructures (PKIs).
163
Anybody can encrypt data for you using the public key. However, you are the only person who
can read the information because you have the private key. When you want to talk to Bob, he uses
your public key to securely send you the session key. The session key is smaller key that is used for
a symmetric cipher between you and Bob. The session key is weaker than the public/private key
but it is faster and changes with every transaction.
If you do not want to apply to a CA for a digital certificate, you can create a self-signed certificate or
use a private CA. Anybody can be a CA; all you need is the appropriate software. Microsoft
Windows Server allows you to create a private CA or a self-signed certificate. However, these
certificates are not automatically trusted by other entities. Browsers and other software, which use
SSL connections, have a pre-loaded list of certificates that are used to identify well-known CAs.
You can add (import) a certificate into the relevant software to identify your own CA. For
example, you can create a self-signed certificate with the ProxySG. If you want your browsers to
trust it, you have to import the certificate into the browsers trusted list. If you use a self-signed
certificate from another device (such as Windows Server), you can import that certificate into both
the browser and the ProxySG.
164
Property
SSL Fundamentals
Initial connection in plain text

Asymmetric (long) key used for key exchange
Symmetric (short) key used for data transfer
6OLGH66/IXQGDPHQWDOV
This diagram illustrates the SSL key exchange process. The key exchange (SSL handshake
protocol) begins with an exchange of messages called the SSL handshake. During the handshake,
the server authenticates itself to the client using public-key encryption techniques. Then, the client
and the server create a set of symmetric keys that they use during that session to encrypt and
decrypt data and to detect if someone has tampered with the data.
The transaction uses two types of data encryption: symmetric and asymmetric. Asymmetric
algorithms use one key for encryption and a separate key for decryption. Symmetric cryptography
uses the same key for encryption and decryption. The key is agreed upon by both sides during the
transaction and can remain static.
Symmetric key encryption is much faster than public-key encryption, but public-key encryption
provides better authentication techniques a malicious party must crack two separate keys.
The key exchange process is as follows:
1.
The client initiates a server request.
2.
The server sends its public key to the client.
3.
The client selects a symmetric encryption key, encrypts the key using the servers public key,
and sends it to the server.
4.
The server uses its private key to decrypt the clients message, which contains the symmetric
key.
5.
The client requests content from the server.
6.
The server uses the specified symmetric method to encrypt the requested content and returns
it to the client.
7.
The client decrypts the data.
165
SSL Proxy Features

AV scanning
Content filtering
Control server certificate verification
Apply security policies to all Web traffic
HTTP, HTTPS, IM, etc.
6OLGH66/SUR[\IHDWXUHV
The SSL proxy allows the ProxySG to read the content of SSL transactions, regardless of the
strength of the encryption key or the algorithm used.
Because it reads and inspects SSL traffic, the ProxySG enables you to monitor where your users are
going, with more granularity than ever before. The SSL proxy also allows you to close some of the
backdoors that advanced users exploit to circumvent Web filtering. For example, if you allow
HTTPS traffic without restriction, it is relatively simple for a user to set up a secure proxy on a
static DSL IP address and use that proxy to connect to forbidden Web sites.
Using the SSL proxy, you can scan all content for potential viruses at the gateway level. Without an
SSL proxy, if a user accidentally downloaded a virus through HTTPS, you had to rely solely on the
client software for virus detection.
The SSL proxy expands your ability to create a more secure and compliant network infrastructure.
The ProxySG SSL proxy allows you to:
Determine what HTTPS traffic to intercept through existing policy conditions, such as
destination IP address and port number. You can also use the host name in the server
certificate to make the intercept decision.
Validate the server certificate to confirm the identity of the server, and check Certificate
Revocation Lists (CRLs) to be sure the server certificate has not been revoked.
Apply caching, virus scanning, and URL filtering policies to intercepted HTTPS traffic.
166
Property
SSL Proxy Setup
1. Client sends SSL client HELLO to ProxySG

2. ProxySG sends client HELLO to server
3. Server sends server certificate to ProxySG
4. ProxySG sends its own certificate to client
6OLGH66/SUR[\VHWXS
You have already configured your network so that the ProxySG is in the middle of every
transaction. The SSL proxy allows the ProxySG to terminate SSL requests from the client, present
its own certificate to the client, and request a public key from the server. Once it has the public key,
it opens a connection with the server, exchanges and decrypts data with the server, and then
re-encrypts the data and sends it to the client.
In this configuration, the client has an SSL session with the ProxySG, and the ProxySG has a
separate SSL session with the OCS. The OCS thinks the proxy is the client. The client assumes that
proxy is actually the server.
The browser on the client site will warn the user that it cannot verify the identity of the OCS. This
warning has purposely not been circumvented. Users should be informed that the traffic over a
supposedly secure connection is possibly being intercepted and decrypted. You can use the Notify
User object in the Action column of the Web Access Layer to notify users that their requests are
being intercepted and monitored. Depending on privacy laws, you might also have to obtain user
consent before intercepting HTTPS traffic.
The SSL proxy can also tunnel HTTPS transactions; it does not have to terminate all of them. For
example, you can set up a policy to tunnel all of the traffic for banking sites; the content is not
analyzed. You can also add user-specific restrictions or bypass options. The SSL proxy will tunnel
HTTPS traffic by default. However, if you want to tunnel traffic to certain sites and intercept traffic
to others you can use the SSL Intercept Layer and the Set SSL Forward Proxy Action object.
Note:
The SSL proxy continues to validate server certificates even when tunneling HTTPS
traffic.
167
Basic Implementation
6OLGH%DVLF66/SUR[\LPSOHPHQWDWLRQ
This diagram illustrates a basic SSL proxy deployment. As with other proxies, the SSL proxy is
deployed between the client and server.
When a client sends an HTTPS request to the OCS, the following actions happen:
1.
The ProxySG intercepts the request and sends the client its certificate and public key.
2.
The client assumes that it is communicating with the OCS and encrypts its symmetric key
using the SSL proxys public key.
3.
The SSL proxy decrypts the symmetric key, using its private key.
4.
The client requests content from the SSL proxy.
5.
The SSL proxy receives the request and sends an HTTPS request to the OCS.
6.
The OCS (because it assumes that ProxySG is the client) sends its certificate and public key to
the SSL proxy.
7.
The SSL proxy uses the public key to encrypt its symmetric key and sends it to the server.
8.
The server decrypts the message, using its private key.
9.
The SSL proxy requests content from the OCS.
10. The OCS retrieves the requested content and sends it to the SSL proxy, encrypting it with the
SSL proxys symmetric key.
11. The SSL proxy scans the message for inappropriate content, encrypts the data using the
clients symmetric key, and delivers it to the client.
168
Property
Sample Policy
The default behavior is not to intercept SSL traffic
You can selectively intercept traffic
Financial / Banking site Do not intercept
HR related / Retirement Do not intercept
Other sites Intercept
6OLGH6DPSOHSROLF\
The default behavior is not to intercept SSL traffic. To allow SSL content to be examined, select
Intercept as HTTPS in the Add SSL Forward Proxy Object dialog box in the Management Console.
When the SSL proxy intercepts HTTPS connections, it generates a private key and corresponding
certificate dynamically.
It is advisable to protect user privacy for some SSL transactions. For example, you can use filtering
software such as WebFilter to create rules to exclude financial and other user-sensitive sites from
interception.
169
VPM Layers
SSL Intercept Layer
Triggers and properties to decide tunnel vs. intercept action
SSL Access Layer

Additional SSL-related triggers and properties
6OLGH66/OD\HUVLQWKH9LVXDO3ROLF\0DQDJHU
The Visual Policy Manager (VPM) has two SSL-related layers:
The SSL Intercept Layer has the following columns: Source, Destination, Action, Track, and
Comment.
The SSL Access Layer has the following columns: Source, Destination, Action, Service, Track,
and Comment.
Use the SSL Intercept Layer to control which sites are intercepted and also to control the contents
of the certificate presented to the client. Use the SSL Access Layer to control server certificate
validation and other aspects of SSL communication such as SSL version and ciphers.
Note:
These layers do not have a Time column because it has no meaning here. The SSL
Intercept Layer does not have a service either; it is applicable to SSL only.
170
Property
Tunnel on Protocol Error
10
6OLGH7XQQHORQSURWRFROHUURU
The ProxySG expects that traffic intercepted by the SSL proxy is well-formed, protocol-compliant
SSL traffic. This might not be the case for several reasons:
Unknown client protocols, such as Skype or peer-to-peer traffic, might be configured to use
the SSL port without specifying SSL as the transport protocol.
The server does not present a certificate (as shown in the example above).
The ProxySG does not support the cipher, compression method, or SSL version that the client
presents for possible negotiation with the server.
In these cases, the behavior of the ProxySG depends on the value of the Tunnel on Protocol Error
global proxy setting. When this setting is enabled and the ProxySG cannot interpret the traffic
arriving on the SSL port, the ProxySG will tunnel the traffic without performing policy processing
or other functions on it.
The Tunnel on Protocol Error setting is global and applies to all protocols, not just SSL.
171
172
Property
Chapter 13: Policy Tracing
This chapter explains policy tracing on the Blue Coat ProxySG and how to create policy to
generate very targeted tracers. There are two types of policy trace: global and policy-driven. It is
important to know the difference between these two and when it is appropriate to use each.
Global policy trace: Powerful but dangerous. This traces every single transaction going through
the ProxySG, regardless of source, destination, or any other parameter. However, this can
generate hundreds of thousands of lines of debug code and can put an excessive strain on the
ProxySG, reducing its performance. Although a global policy trace is effective, it should be
used very carefully.
Policy-driven trace: Created in policy to generate the execution a trace when a specific rule is
matched. You can be very granular and significantly limit the maximum number of entries
found in the policy trace file. However, you might not actually trace everything you need and
might miss something significant.
While the global policy trace covers more data, it is more resource-intensive. A policy-driven trace
is less resource-intensive, but you might miss data depending on what you are monitoring and
what triggers you put into the rule. Additionally, when using the global policy trace in conjunction
with an existing policy-driven trace, some information about a transaction might end up in default
policy trace while other information might appear in the policy-driven trace. A policy-based trace
only generates a trace if the rule to which is associated is triggered.
It is important that you have a clear understanding of what traffic is subject to policy processing.
Additionally, it is important to know the constraints under which transactions are processed and
become part of what the ProxySG matches against the existing policy.
Also, there are several pieces of information that you need to know, such as how running policy is
created and what blocks are used to build these elements.
This table lists \ the ways to track policy execution and the policy layers for which they apply:
Object
Admin
Auth
Admin
Access
DNS
Access
SOCKS
Auth
Web
Auth
Web
Access
Web
Content
Event Log
E-mail Log
SNMP Objects
Trace
Forwarding
Policy trace files are available via the Web browser. You can access them directly or via the
Management Console. From the Management Console, go to Statistics > Advanced > Policy > List
of policy URLs. You can also directly point your browser to https://proxyIPaddr:8082/Policy.
The global policy trace is available under the file default_trace.html, while the other policy-specific
traces are available under whatever name you designated.
Important: After using a trace to troubleshoot, remove the trace to save log space.
173
Policy Overview
Intercepted traffic
Policies apply to all intercepted traffic
Evaluation performed at each policy checkpoint
Bypassed traffic
Policies do not apply
ProxySG configuration determines traffic behavior
Bridging configuration allows traffic
IP forwarding enabled allows transparently proxied traffic
All other scenarios terminate traffic not intercepted
6OLGH3ROLF\RYHUYLHZ
The first thing you must know to understand policy tracing is the difference between intercepted
traffic and bypassed traffic. Intercepted traffic is traffic that matches a service whose action is set to
intercept. Only intercepted traffic is subject to policy processing. Therefore, any traffic that is
intercepted by the ProxySG goes through policy processing and appears in the policy trace. Any
policies are applied only to the intercepted traffic.
On the contrary, any traffic that matches a service set to bypass or traffic that does not match any
service is not affected by policy. This does not necessarily mean that traffic is allowed or denied;
that depends on the deployment option and configuration parameters, which determine whether
the traffic is rejected or allowed by the ProxySG. In either case, the traffic is not subject to policy
processing. For instance, if the ProxySG is deployed in transparent mode through bridging or with
IP address forwarding enabled, all of the traffic flows through the ProxySG and is not subject to
policy processing unless it matches a service set to intercept.
For example, if a transparently-deployed ProxySG (in bridging mode) has a default policy of Deny
but is only intercepting FTP traffic on port 21, all traffic is allowed except FTP traffic on port 21. All
other traffic is allowed, and no policy is applied to it.
174
Property
Policy Processing Flow
6OLGH3ROLF\SURFHVVLQJIORZ
The above flowchart describes the process taken by the ProxySG to determine whether policy
should be applied and what policy should be applied to a given transaction.
When the ProxySG receives intercepted traffic, the first analysis made is to determine whether this
a console service or a proxy service. If it is a console service, the ProxySG only evaluates the admin
layers in the VPM and CPL and then returns a response to the client. In the case of a console
service, nothing else is evaluated by the ProxySG.
However, if it is a proxy service, the ProxySG takes these steps in applying policy:
1.
First, the ProxySG evaluates the default policy. If the default policy is Deny, the transaction is
denied unless there is another major role somewhere down the policy process which might
change the transaction from Deny to Allow. If the default policy is Allow, the transaction is
allowed unless there is a Deny or Force-Deny property down the policy-processing line.
2.
After the default policy is processed, the ProxySG processes four CPL policy files: the VPM
policy file, the Local policy file, the Central policy file, and the Forward policy file. This is the
default order for processing these files, but the order can be changed in the Management
Console. After these policy files have been evaluated, the determination is made about what
policy is applied, and the response is returned to the client.
None of this applies to bypassed traffic. If the traffic does not match a service set to intercept,
either for console or proxy service, policy is not applied. Bypassed traffic is only allowed or denied
based on the deployment of the ProxySG and the configuration of the IP forwarding setting.
175
Policy Trace Key Factors

Traces available
Global policy trace
Management Console or CLI
Policy-driven trace
VPM or CPL
Operational details of traces

Each transaction is evaluated separately
Policy is traced until a match
Policy is re-evaluated at each checkpoint (trace does not
reflect it)
6OLGH3ROLF\WUDFHNH\IDFWRUV
There are two types of policy traces: global and policy-driven. Global policy tracing is controlled
in the Management Console or the CLI; policy-driven trace is controlled in the VPM or CPL.
A global policy trace can be enabled at one of two levels:
Trace all policy execution: The policy trace contains every transaction going through the
ProxySG, including console services. This trace generates a lot of data, most of which is not
necessary to troubleshoot a policy. You should use this level only if you suspect issues with
console services.
Trace proxy traffic policy execution: The policy trace only contains information relative to the
transactions matching proxy services. All traffic matching console services is ignored. This is
the recommended level for most policy-tracing scenarios. However, you should avoid global
policy tracing whenever possible and opt for policy-driven traces instead.
Because each Web page or resource that you download from the Internet is composed of several
objects, like when you open a complex site such as www.cnn.com, your browser is likely to
download more than 50 different objects, often from multiple hosts in different categories.
Each object processed by the ProxySG has to go through the policy evaluation, and by doing so
generates an entry in the global policy trace (and in the rule-based trace, if the object triggers the
rule).
A policy trace does not show a request being evaluated against a rule that follows in the same
layer as the rule that the request triggered. This behavior is consistent with the logic of the
ProxySG: When a rule is matched, policy evaluation for that layer is interrupted, and the process
goes to the next layer in the sequence.
At each checkpoint, the policy is evaluated again as new information is available to the ProxySG to
make a decision. This behavior is not reflected in the trace because it might be confusing.
When comparing the transaction to a rule in the policy, the trace can return one of the following
three values:
176
Property
Match: All of the triggers (if any) in the rule evaluated to true. The rule is a match, and the
ProxySG is prepared to execute the action or track operation specified in the rule.
Miss: At least one of the triggers (or all) in the rule evaluate to false. The rule is not a match,
and the ProxySG ignores any action or track operation in the rule
N/A: (not applicable) This is a rare occurrence. In essence, the ProxySG cannot make any
determination against the rule. For instance, if you have an HTTP-specific trigger in the rule
but the current transaction being traced is an FTP one, then the trace shows N/A for this rule.
The details of both types of policy tracing are discussed on the following pages.
177
Global Policy Trace
6OLGH*OREDOSROLF\WUDFH
This diagram shows the results of a global policy trace. On the left is a simple policy, with the
default policy set to Allow. A DNS restriction has been set up for all sites, meaning (for the
purpose of policy evaluation only) the ProxySG does not perform any DNS lookup. Therefore, if
the client connects via a host name, the host name is not translated to an IP address for the
purpose of rules processing only. Of course, the ProxySG has to resolve the address to a DNS value
in order to connect to that given origin content server.
Furthermore, there is a policy with a layer guard that says Deny if one of the three conditions
listed below it are met. If the proxy port is 80, the destination URL address is 216.52.23.9
(www.bluecoat.com at the time of writing this chapter), or the hostname does not end with
.bluecoat.com, the transaction is denied.
The next layer is a simple authentication rule, not a force authenticate. If any of the parameters are
met in the previous layer, the user is not asked to authenticate.
The third layer is another layer guard set to allow based on usernames. Despite the fact that the
previous layer is a simple authenticate, the authentication must still take place because it is
possible that the first layer (DENY) may be overridden by the this layer if the username triggers a
match. The only way to know whether one those triggers is a match is to perform authentication at
the user level. In this case, the simple authenticate and a force authenticate behave the same way
since there are user-based triggers that can override the Deny rule.
The user in the above example is attempting to access www.google.com from the client device at
10.2.15.125, on the proxy port 8080, at 3:36 p.m. The first rule, in the first layer, misses because the
transactions proxy port is 8080, not 80. The next rule is a not applicable; the ProxySG cannot look
up the IP address of www.google.com because of the DNS lookup restriction for the purpose of
policy evaluation. There is match on the next rule of DENY and a match on the next layer because
the hostname does not end with .bluecoat.com. Two matches are shown on the same layer because
there is a layer guard; without a layer guard, this cannot happen. At this point, the transaction is
denied.
178
Property
Policy-driven Trace
6OLGH3ROLF\GULYHQWUDFH
You can create two different types of policy traces: global policy trace and policy-driven trace. The
global policy trace traces every part of every transaction that is intercepted by the ProxySG. It is
very resource-intensive, and the results are very broad.
A similar process happens with policy-driven trace; however, you can specify more narrow
parameters to indicate exactly what you are going to monitor. In the case shown above, if the
default policy trace (global) is enabled, all transactions from the client at 172.16.90.56 and the client
at 172.16.90.110 end up in the same policy trace file (default_trace.html).
Therefore, if you are only trying to resolve an issue with client 172.16.90.110 or only this client is
affected by the problem you are trying to solve, it is much easier and efficient to use a
policy-driven trace. Create a simple CPL statement, which can also be done in the VPM, that says
if the client address is 172.16.90.110, the request is traced, as well as all the rules. The destination is
also traced to the file specified in the policy (ip-172-16-90-110.html). This file is accessible at
https://proxy-ipaddr:8082/Policy.
The parameters shown above define how and what is traced by the ProxySG:
trace.request(yes): Determines whether detailed trace output is generated for the

current request. The default value is no, which produces no output. In this case, the trace is
turned on. The trace output is generated at the end of a request and includes request
parameters, property settings, and the effects of all actions taken.
trace.rules(all): This parameter tells the ProxySG to compare the entire transaction
against all the rules and then show all of the comparisons with those rules. This means that
even if the rule misses, a miss statement is found in the policy trace file or if the rule is not
applicable, it is shown. There are three options for trace.rules: yes, no, and all. By
selecting yes, only rules that match are shown in the trace. No means that no rules are shown
in the trace. And all means that all rules are shown, no matter whether they are matches,
misses, or not applicable.
179
On the next layer, there is a match for the authentication in the next layer. This authentication must
be done because there is an allow rule on the third layer. However, because the client did not
present any authentication information, further processing does not take place and the user is
prompted with an authentication request from the ProxySG, in this case an HTTP 407, because it
cannot proceed to the next layer without proper credentials.
At this point, a lot of useful information about the transaction and deployment can be derived
from the policy trace. This ProxySG is deployed as an explicit proxy; the policy trace displays all of
the client information as well as the name of the service that this request is matching (HTTP). The
hostname that the user is trying to reach is also known. So, from the policy trace, you are able to
get extremely useful and advanced information that gets you closer to solving the issue at hand.
180
Property
Policy-driven Trace
6OLGH3ROLF\GULYHQWUDFH
Unlike the previous example, this example shows the results of a policy-driven trace with minimal
information recorded. Based on the policy created for tracing, the ProxySG records only a small
amount of information about the transaction.
The first policy layer is contains an authentication rule. It tells the ProxySG to authenticate users in
the blue_coat_ldap authentication realm. The rule also specifies that the request should be traced.
However, trace.rules(no) is selected, which means that the trace does not show any matches
or misses, only the final result of what happened to the transaction. Finally, the destination of the
trace is user-auth.html, which can be found at https://proxy-ipaddr:8082/Policy. The second layer is a
Web access layer containing a layer guard, which says the transaction is allowed in the user is
student01 or bcadmin or if the category being requested is News/Media. From this policy, you can
infer that the default policy of this ProxySG is most likely Deny.
The client requests to go to www.google.com through the ProxySG containing the policy described
above. At the top of the policy trace file there is a start transaction notice.The trace file shows that
the client at 10.2.15.125 is connecting using the HTTP service over proxy port 8080, which is a
good indication that this ProxySG in an explicit deployment. The GET request is shown,
containing the entire URL, followed by a notice stating that DNS lookup has been restricted. And,
as a result of the policy processing, you are shown that the authentication failed.
Additionally, the category of the requested site is shown, which indicates that categorization is
done before authentication. No relevant information is included about the second policy layer
because evaluation of the layer is dependent upon the result of the authentication prompt.
The client sends the GET request to the ProxySG, which returns a 407: Proxy Authentication
Required. The net result of what happens after the client receives the 407 is contained in policy
trace between start transaction and stop transaction. Within this space, a great deal of
additional information is provided. You see that the blue_coat_ldap realm uses Basic
authentication credentials, that the transaction was made using Microsoft Internet Explorer 6.0
from a machine using Windows XP with Service Pack 2 and Infopath loaded. Additionally, it
shows that the user is not authenticated because it is the first time the user has made a request to
the ProxySG for this session.
181
Policy-driven Trace Details
6OLGH3ROLF\GULYHQWUDFHGHWDLOV
This diagram takes a more in-depth look at a policy-driven trace. In this example, the policy layer
states that if the user authenticates as Bob Kent, as a user of sunnyvale.training.bluecoat.com, then
the ProxySG should trace the request. The request records everything, including all matches and
misses, and the data is sent to the file bobkent.html.
This policy trace occurs only when the user has been authenticated as Bob Kent. Therefore, until
the user is authenticated, nothing goes into the policy trace file.
1.
The client is attempting to connect to www.google.be, the Belgian version of Google. The
ProxySG returns a 407, asking the client to authenticate. The request and response constitutes
a single transaction. Therefore, because the user is not known, the information regarding that
transaction goes into the default policy trace file, if it is enabled. If the default trace is not
enabled, no information is recorded regarding this transaction up to this point.
2.
When the client reissues the same GET request for www.google.be, the ProxySG puts in the
credentials of Bob Kent. Now the policy rule is matched; therefore, the information is properly
recorded in bobkent.html.
3.
When the client asks the ProxySG for logo_plain.png as user Bob Kent, the transaction
information again is stored in bobkent.html.
4.
This transaction contains Bob Kents credentials, so the information is stored in the proper file.
If a transaction such as numbers 2, 3, or 4 matches a more specific policy trace than the
default, the information appears only in the more specific policy trace file. Therefore, there is no
double tracing of data.
182
Property
Chapter 14: Forwarding
Forwarding is the ability to send Web requests to other appliances before sending the request to an
origin content server. Forwarding allows you to define the host and groups of hosts to which client
requests can be redirected (also known as a proxy hierarchy). Those hosts can be servers or proxies.
The combination of forwarding and the Blue Coat ProxySG policy engine allows extremely
flexible configuration and traffic management. Forwarding is a method for sending requests (for
supported protocols) to a destination other than the IP address specified in the request. You can
use forwarding to organize how Web traffic flows around the network (proxy chaining), or you can
use forwarding to create a basic reverse-proxy scenario.
When you configure forwarding, you can define load-balancing options. You also can specify how
the ProxySG should act if the upstream host is unavailable:
Fail closed: The ProxySG drops the request and returns an error to the user. This is the default
behavior.
Fail open: The ProxySG sends the request to the original OCS, ignoring the forwarding rule.
For example, if you forward all traffic from the London ProxySG to the Amsterdam ProxySG in a
fail-closed configuration, the London users cannot access the Internet when the Amsterdam
ProxySG is unavailable. Conversely, in a fail-open scenario, the London users are able to access the
Internet directly (assuming that the London location has Internet access) when the Amsterdam
ProxySG is unavailable. In a proxy-chaining scenario, fail-open forwarding is probably a better
option because failures do not limit Internet access. In a reverse-proxy scenario, fail closed is
almost a requirement because there is not much else the proxy can do when the upstream OCS is
not available.
You can forward requests to an individual host or to a group of hosts. You can define which OCS
or proxies are members of which group. Groups allow you to create a load-balancing environment
using only ProxySG appliances. However, you can manage load balancing in several ways:
When you forward requests to a specific host and that host DNS-resolves to multiple IP
addresses, then one of the available load-balancing methods (round-robin, least connections,
or none) is applied to those IP addresses.
When you forward to a group, you can load balance using a hash. When a hash is not used, all
of the IP addresses of the group are gathered together, and the groups method is applied
across the entire set of IP addresses. When a hash is used, you can apply the hash to the
domain name or the full URL. This hash value is used to select one member of the group. The
selected host is treated just as an individual host is treated; the only difference is that the
load-balancing method configured for the group is used for the selected host. Hashing
guarantees that when the ProxySG forwards a request for a host or URL that was previously
requested, that request goes to the same host or proxy that received it before.
Similarly to hashing, you can use host affinity to send a request from the same source to the
same destination. While hashing is based on the destination specified in the request, host
affinity is the attempt to direct multiple connections by a single user to the same group
member. For example, consider a Web site that uses shopping carts to allow customers to
purchase items. The site might load balance requests across a group of Web servers working in
parallel, but only one server in the group maintains state for a single user. If the user
connections are sent to a different server, that server has no previous state for the user and
might start over. Host affinity forces the users connections to return to the same server until
the user is idle for a configurable period of time. After a configurable period of inactivity, the
host affinity times out, and the users state is lost.
183
Typical Forwarding Scenario
6OLGH7\SLFDOIRUZDUGLQJVFHQDULR
Forwarding sends traffic to a destination other than that specified by DNS resolution. Traffic is
sent upstream to another proxy, as shown in the above diagram. Forwarding is often used in proxy
hierarchies in which lower-level proxies must use another proxy for Internet access. Forwarding
also can be used for load balancing, caching optimization, or redundancy.
This diagram illustrates a typical forwarding scenario in which a local ProxySG receives a request
and forwards it to a second ProxySG for content retrieval (or some other task, such as
authentication). The ProxySG that receives the forwarded request then delivers the requested
content from its cache or retrieves it from the OCS. A forwarding structure like this often results in
fewer trips to the OCS because of the likelihood that the requested content resides in one of the
upstream caches.
184
Property
Reverse Proxy
6OLGH5HYHUVHSUR[\
In the deployment shown in this diagram, the ProxySG receives all requests for a specific Web
server. It is common to deploy a ProxySG in front of the server to protect a production Web server
and increase its performance.
The DNS server resolves the host name of the OCS to the IP address of the ProxySG; when the
proxy receives the clients request, it needs to know where the request should go. While you could
use split DNS (the proxy uses a different DNS than the Internet), this would not allow the
ProxySG to handle client requests that do not have a host header. In general, forwarding is a
better solution.
Alternatively, you can use forwarding to send a request destined for a specific host to another
host. If your organization has a domain name that is similar to other domain names, you can
forward those requests to the proper domain.
185
Forwarding Host Request Types
6OLGH)RUZDUGLQJKRVWUHTXHVWW\SHV
The request style determines the format of the HTTP request that is forwarded to the upstream
device. You must indicate whether the forwarded host is a server or a proxy because this
configures the ProxySG to format the request correctly. The server variable specifies that the
relative path for URLs should be used in the HTTP header because the next hop is a Web server,
and not a proxy server.
If there is an intervening proxy, a proxy-style request must used. A proxy-style request includes
the entire URL for the same reasons that a browser sends the entire URL to an explicit proxy. The
default request type is proxy-style.
186
Property
Forwarding Host Definition
6OLGH)RUZDUGLQJKRVWGHILQLWLRQ
The forwarding configuration includes directives that create the forwarding hosts and groups and
provide for load balancing and host affinity. Directives are commands that can be used in
installable lists to configure forwarding. Forwarding can be configured through the CLI or by
adding directives to a text file and installing it as an installable list.
When you add forwarding directives to an installable list, you can create and delete the
forwarding host and associate protocols and ports with the host. You can create a maximum of 32
groups, and each group can contain a maximum of 512 hosts. You can create 512 individual hosts
that do not belong to any group.
The options that you must use to create a forwarding host are:
An alias provides a name for this host when referenced in policy (who): Alias names can be
any text string that makes sense to you. However, the name must not include a space or
special characters.
IP address or hostname of the host (where): If a hostname is used instead of an IP address, it is

reresolved periodically. The DNS reresolve is needed because DNS may be in a load-balancing
or failover environment.
Supported protocols (what).
Type of host (how).
By default, no protocol is selected if the forwarding host is a server. Protocols are entered using
protocol=tcp_port syntax. You must choose at least one protocol (the port number range is
from 0 to 65535). If only one protocol is configured, the ProxySG configures the default port for
that protocol. You can configure forwarding for HTTP, HTTPS, FTP, MMS, RTSP, and TCP.
Note:
HTTPS protocols are not allowed if the host is a proxy.
187
The term default-schemes is used to indicate that the forwarding host supports the same
protocol/port pairs as the proxy. If you use default-schemes in the directive, all protocols and their
default ports are selected. This directive is only available for proxy hosts.
You also can use default-schemes and then eliminate protocols by editing the protocol you do not
want; for example, http=no. If you do not want to use the default ports for the protocols, you
must also specify them.
The host definition type specifies whether the forwarding host is a server or proxy. This distinction
is very important because it determines the format of the forwarded request.
The group-name option is used for forwarding to multiple hosts. You define this configuration
by creating several forwarding hosts and assigning the same group name. The group name can
then be used as a policy alias so that requests are forwarded to the group, rather than to an
individual host.
SSL certificate verification (ssl-verify-server=setting, where setting is yes or no) is
similar to the browser pop-up window that indicates that a certificate is not trusted. This option
configures the ProxySG to validate device certification before using the certificate to create the
connection. In other words, the ProxySG checks to ensure the certificate is signed by a trusted
source. If the certificate cannot be verified, nothing is forwarded. This option can be used to
prevent man-in-the-middle attacks inside the network.
188
Property
Load Balancing Properties

Load-balancing method
[load-balance=no|round-robin|least-connections]
Load-balancing host-affinity
[host-affinity=no|client-ip-address|accelerator-cookie]
[host-affinity-ssl=no|client-ip-address|acceleratorcookie|ssl-session-id]
6OLGH/RDGEDODQFLQJSURSHUWLHV
Load balancing is a way to split traffic requests among multiple upstream systems or among
multiple IP addresses on a single host. You can configure load balancing using the following
methods:
For individual hosts: If a host is DNS-resolved to multiple IP addresses, then that hosts
load-balancing method (round-robin, least connections, or none) is applied to those IP
addresses.
For groups, two load balancing choices are available:
Apply a load-balancing method to a group: All the IP addresses of all group members are
gathered together, and the groups method is applied across that entire set of IP addresses.
Use a hash: If you use a hash for load balancing, you can choose to hash the domain or the
full URL.
If you use a group name, you must configure load balancing using the load-balancing directive.
The no-load-balancing option splits the name space. In other words, Yahoo! always goes to one
host, and Google always goes to another. The round-robin method alternates which forwarding
host is used. The least-connections option monitors the sessions sent to each proxy and
determines how long-lived the session is to identify the next forwarding host.
The host-affinity directive enables you to configure forwarding so that all requests from a
specific client are sent to a specific proxy. Host affinity is closely tied to load-balancing behavior;
both should be configured if load balancing is important. The client-ip-address option
forces all requests from the specified IP address to be forwarded to the same host for the duration
of the session.
189
190
Property
Chapter 15: Reverse Proxy Implementation
A reverse proxy is a proxy that acts as a front end to one or more Web servers, typically to improve
performance. Clients use the reverse proxy to access back-end Web servers.
Reverse proxying with the Blue Coat ProxySG provides the following advantages:
The ProxySG terminates the session with the client (even for SSL connections) and establishes
another session with the Web server, off-loading this process from the Web server.
The Web server sees only the IP address of the ProxySG.
Granular policies with authentication, authorization, and logging can be implemented.
The ProxySG has built-in denial-of-service attack detection, protecting the Web servers from
these types of attacks.
The servers identity can be hidden by the ProxySG.
Increased performance with caching provides an improved Web experience.
The flexible advanced-forwarding architecture of the ProxySG, coupled with caching, provides
organizations a best-of-breed solution to leverage their network infrastructure.
Note:
To fully implement a production reverse proxy deployment, you must configure the
two-way URL rewrite (TWURL) feature. For more information, refer to the TWURL
chapter of this course.
191
Reverse Proxy Deployments
6OLGH7\SHVRIUHYHUVHSUR[\GHSOR\PHQWV
In a reverse proxy deployment, the ProxySG can be located at several places on the network. One
option is not necessarily better than the other; evaluate which solution provides the best balance
between performance and security in your enterprise.
The top diagram above shows a deployment in which the ProxySG is in the DMZ. The host name
of your Web server resolves to an IP address, which the firewall then maps to the actual IP address
of the ProxySG. All traffic goes from the clients on the Internet to the ProxySG through the
firewall.
You can easily modify this configuration and replace the Layer 2 switch, shown in the top
diagram, with a Layer 4 switch. In this scenario, the host name of the Web server resolves to an IP
address, which the firewall then maps to the actual IP address of the Web server in the DMZ. The
Layer 4 switch transparently redirects then traffic destined to the Web server to the ProxySG. This
is a fairly common scenario; the Layer 4 switch allows you to easily load-balance multiple
ProxySG appliances and multiple Web servers. No DNS or firewall configuration is required if you
have the Web server in place before you install the ProxySG.
The bottom diagram above shows a configuration in which the ProxySG has two interfaces, one
directly on the Internet. A routable, public IP address is assigned to that interface. The host name
of the Web server resolves to the IP address for the external interface of the ProxySG. The internal
interface is connected to the DMZ, where the actual Web server is located. Implementing this
configuration requires you to make DNS changes; however, it allows you to off-load all the traffic
to your Web server from the firewall.
192
Property
Forwarding for Reverse Proxy

Allow the proxy to services requests for front-ended W eb
servers
Forwarding hosts must be defined as server style
Protocol support must be specific (default-schemes not
allowed)
Protocol conversions (HTTPS<-->HTTP) are automatic
6OLGH5HYHUVHSUR[\FRQVLGHUDWLRQV
The purpose of the reverse proxy is to service requests for back-end Web servers. To redirect
requests to the reverse proxy, you must either set up DNS so that the world believes that the IP
address of the proxy is actually that of the Web server, or you must implement some type of Layer
4 or WCCP redirection. While explicit proxying is the less-expensive solution, many enterprises
choose to implement a device-oriented redirection scheme.
To relay requests from the proxy to the correct Web server, set up advanced forwarding rules.
When creating forwarding rules for reverse proxies, consider the following:
The forwarding hosts must be defined as server. The server variable specifies that the
relative path for URLs should be used in the HTTP header because the next hop is a Web
server, not a proxy server.
The default-schemes variable is not allowed for Web servers, so you must explicitly
specify the supported protocols and ports.
SSL transactions are performed only between the client and the ProxySG. The ProxySG then
communicates with the back-end server over HTTP.
193
6OLGH)RUZDUGLQJUXOHVDQGUHYHUVHSUR[\LQJ
This diagram shows a client requesting content from a reverse proxy that is accelerating the Web
server www.site.com. When the client does a DNS lookup for www.site.com, the DNS server
returns the proxy IP address.
However, when the proxy receives a GET request with its own IP address, it must know where to
forward the request. This is why you must create a forwarding rule to forward the request to the
back-end server.
194
Property
6OLGH7UDIILFIORZDQGEDQGZLGWKPDQDJHPHQW
To help alleviate the strain SSL places on general-purpose Web servers, ProxySG appliances have
integrated full SSL capabilities. Blue Coat has specifically designed the ProxySG to accelerate and
scale high-traffic Web sites. By adding SSL processing, ProxySG appliances offload the origin
server from the delivery of secure objects and the managing and processing of SSL sessions.
This diagram shows a client sending an HTTPS request to a reverse proxy that is accelerating the
Web server www.site.com. Note that the SSL transaction occurs only between the client and the
proxy. The proxy terminates the HTTPS request, performs the key exchange (public key and
master key), and then sends the request to the back-end server.
Blue Coat secure proxy appliances can triple a Web sites throughput and cut user response times
by 50% to 80%. This allows a Web site to serve more content and process more transactions
through the existing server infrastructure. ProxySG appliances can negotiate 10 to 40 times more
new SSL connections than a standard Web server, supporting up to 800 new SSL sessions per
second, and up to 11,000 maximum existing connections. The Blue Coat appliances support
processing both HTTP (public) content and HTTPS (encrypted) content.
ProxySG appliances ship with validation certificates from all major certificate authorities (CAs),
which validate the origin server certificates. Customers can then add their own certificates for
each original domain. Blue Coat appliances support all major CAs for origin server certificates.
195
Reverse Proxy Policy

Default policy of Deny
Allow only recognized hostnames
Modify caching if proxy behavior should vary from client
behavior
VPM = Web Content Layer
6OLGH(QVXULQJWKDWDSUR[\LVQRWRSHQ
An open proxy is a proxy server that has not been configured to disallow connections from
unfamiliar clients. In other words, the proxy accepts requests from any IP address and connects to
any resource on behalf of those clients. Open proxies are often blacklisted; once a proxy has been
blacklisted, it is very difficult to get it removed from the list of untrustworthy sites.
To avoid having an open proxy, you should do the following:
Set a default policy of Deny. This means that you must create rules to explicitly allow clients to
connect to the proxy.
Allow only recognized hostnames. Allow connections only to the Web sites and paths that you
know to be valid.
Modify the proxy caching behavior such that the proxy overrides some client requests.
Because you control the Web server content, you can safely ignore client requests for fresh
content (forced reload) and serve the content from the cache (when fresh).
196
Property
Reverse Proxy Policy

Forwarding policy should match for all permitted
requests
Set HTTP proxy behavior profile to portal
Ignores browser-forced reload attempts
Trust server expiration headers
6OLGH)RUZDUGLQJSROLF\IRUUHYHUVHSUR[\
When setting up forwarding policies, ensure that they are valid that is, permitted requests
should initiate the same correct action.
It is also a good idea to set the HTTP proxy profile to portal. Setting the profile to portal causes
the proxy to ignore client-forced reload attempts and to trust server expiration headers. Because
you own the Web server in this case, you know when content is fresh and can trust the validity of
the server expiration headers. When you set the profile to portal, the proxy is configured to:
Substitute GET for IMS (if modified since). If the time specified by the If-Modified-Since
header in the clients conditional request is greater than the last modified time of the object in
the cache, it is a strong indication that the copy in the cache is stale. If so, the HTTP proxy does
a conditional GET to the origin content server, based on the last modified time of the cached
object.
Substitute GET for PNC (pragma no cache). Typically, if a client sends an HTTP GET request
with a Pragma: no-cache or Cache-Control: no-cache header (for convenience, both
are referred to as PNC), a cache must consult the OCS before serving the content. This means
that HTTP proxy always re-fetches the entire object from the OCS, even if the cached copy of
the object is fresh. Because of this, PNC requests can degrade proxy performance and increase
server-side bandwidth utilization. However, if the Substitute Get for PNC setting is enabled,
then the PNC header from the client request is ignored (the HTTP proxy treats the request as if
the PNC header is not present at all).
Substitute GET for HTTP 1.1 conditionals. If the Substitute Get for HTTP 1.1 Conditionals
setting is enabled, the HTTP proxy ignores the following Cache-Control conditions from
the client request:
max-stale [=delta-seconds ]
max-age=delta-seconds
min-fresh=delta-seconds
must-revalidate
197
proxy-revalidate
Substitute GET for Internet Explorer. Some versions of Internet Explorer issue the Accept:
*/* header instead of the Pragma: no-cache header when you click Refresh. When an
Accept header has only the */* value, the HTTP proxy treats it as a PNC header if it is a Type
N object. You can control this behavior of the HTTP proxy with the Substitute GET for IE
Reload setting. When this setting is enabled, the HTTP proxy ignores the PNC interpretation of
the Accept: */* header.
Never refresh before expiration. Applies only to cached Type T objects. (In a Type T object, the
OCS specifies an explicit expiration time.) When this setting is enabled, the ProxySG does not
asynchronously revalidate such objects before their specified expiration time. When this
setting is disabled, such objects, if they have sufficient relative popularity, can be
asynchronously revalidated and can, after a sufficient number of observations of changes,
have their estimates of expiration time adjusted accordingly.
Never serve after expiration. Applies only to cached Type T objects. If this setting is enabled,
an object is synchronously revalidated before being served to a client if the client accesses the
object after its expiration time. If this setting is disabled, the object is served to the client and,
depending on its relative popularity, might be asynchronously revalidated before it is
accessed again.
198
Property
Chapter 16: Two-way URL Rewrite
In order to complete a successful implementation of a reverse proxy deployment, you need to

ensure consistency and accuracy of the links served by the Blue Coat ProxySG to the client and
consistency and accuracy of the headers from the ProxySG to the server.
It is possible that the internal Web sever contains internal links, or that the relative paths of links
and objects do not resolve correctly. For instance, if your Web server has an internal non-routable
IP address, all of the relative links could potentially refer to that IP; if the ProxySG executes a
simple forwarding without checking the portability of the link, the user who receives the content
will not be able to follow those links.
This chapter presents an example of a simple reverse proxy implementation. The domain
www.bluecoat.nl resolves to the IP address of a ProxySG. The ProxySG forwards the requests for
www.bluecoat.nl to www.bluecoat.com. Bear in mind that www.bluecoat.com is also
DNS-resolvable.
You will see that the links served from www.bluecoat.nl point to www.bluecoat.com; the two-way
URL rewrite (TWURL) is not implemented. When the user follows a link, the content now comes
directly from the www.bluecoat.com site and no longer from the ProxySG that is acting as reverse
proxy for www.bluecoat.nl. Then, you will see how the links for the content served from
www.bluecoat.com point to www.bluecoat.nl. When the user follows the link, the request goes to
the ProxySG and not directly to www.bluecoat.com.
The circumstances under which two-way URL rewrite is required are unpredictable and often
impossible to foresee. However, you should always use it unless you are absolutely confident that
you do not have to.
Note:
The site www.bluecoat.nl does exist; however, it is not the property of Blue Coat and is
not served by a ProxySG. The site is just used as an example in reference to the
previous lab on reverse proxy.
199
The Problem
Forwarding rules change the destination IP
Links are not modified
Headers are not modified
Badly designed Web sites might contain:
Local references
(<img src=http://172.16.10.100/logo.gif>)
Local links
(<A HREF=http://172.16.10.100/page2.htm>)
6OLGH:K\LPSOHPHQW7:85/
A forwarding rule alone does not modify any parameter of the clients request or any parameter of
the servers response. You can imagine that the destination IP address is changed from the DNS
resolved one to the one that you defined.
Links and headers are not changed; this can have unpredictable and often unwanted effects on
what the client receives.
200
Property
The Solution
ProxySG receives a request from a client

for a Web page inside a server portal
Rewrite requested URL; send to server
When the server sends a response

ProxySG rewrites URLs inside the response from server
form back to client form
6OLGH7:85/WKHVROXWLRQ
The idea behind two-way URL rewrite is accuracy and consistency of the content served to the
client.
The above figure shows an example of how two-way URL rewrite can fix poor HTML code. The
client on the left requests content from www.site.com; the site is front-ended by a ProxySG. The
ProxySG modifies the request received from the client by adapting the headers, and in the same
way, adjusts the server responses so that the client only receives resolvable links.
201
Header Modification
Need to change the host header and the possible links

6OLGH+HDGHUPRGLILFDWLRQ
In this example, the ProxySG is configured to forward the requests for www.test.com to the site
www.example.com, but two-way URL rewrite is not configured on the ProxySG.
The HOST header in the client request refers to www.test.com. Because there is not a two-way URL
rewrite policy, the host header still refers to www.test.com when it is received by the
www.example.com site. Most Web servers should safely ignore this header, unless the server is
running more than one site on the same IP address. In the case of virtual hosts (more servers on
the same IP), the host header is key in handling Web requests and delivering the correct content.
202
Property
Virtual Hosts
6OLGH7:85/ZLWKYLUWXDOKRVWV
The situation shown in this diagram is more realistic than the previous one. A client wants to
retrieve content from www.siteB.com; this site is actually front-ended by a ProxySG that does not
have any two-way URL rewrite policy. The client connects to the external IP address of the
ProxySG; the request is then forwarded to the Web server, which contains the requested data. The
server has an internal IP address and hosts two different Web sites: internalsiteA (the default one)
and internalsiteB (the one requested in this example).
Based on the information above, what content will the client receive from the proxy: internalsiteA
or internalsiteB? Discuss the question with the instructor. Hint: The request headers are not
modified by the ProxySG.
203
Forwarding Without TWURL
The forwarding rule does not include TWURL

The links in the page are inconsistent
Browser assumes content from www.bluecoat.nl
Links point to www.bluecoat.com
6OLGH)RUZDUGLQJZLWKRXW7:85/
This diagram shows what happens when you apply a forwarding rule to the incoming requests
without adding a two-way URL rewrite policy. Of course, you need to use two-way URL rewrite
only when you are using forwarding rules for an implementation of reverse proxy.
Note that the user agent assumes that the content is coming from www.bluecoat.nl (as you can see
from the reference in the window); however, the links still point to www.bluecoat.com.
204
Property
Forwarding With TWURL
The forwarding rule includes TWURL

The links in the page are consistent
Browser assumes content from www.bluecoat.nl
Links point to www.bluecoat.nl
6OLGH)RUZDUGLQJZLWK7:85/
This diagram shows what happens when you apply a forwarding rule to incoming requests when
you have a two-way URL rewrite policy. Of course, you need to use two-way URL rewrite only
when you are using forwarding rules for an implementation of reverse proxy.
Note that the user agent assumes that the content is coming from www.bluecoat.nl (as you can see
from the reference in the window); consistent with this assumption, the links all point to
www.bluecoat.nl. The user is unable to detect that the request for www.bluecoat.nl has been
redirected; from the users viewpoint, input is being directed to www.bluecoat.nl and output is
being received from that site, even though the user actually is communicating with
www.bluecoat.com.
205
CPL Syntax
<proxy>
action.action_name(yes)
transform transformer_id
end
define url_rewrite transformer_id
rewrite_url_substring "client_url_substring" "server_url_substring"
rewrite_url_prefix "client_url_substring" "server_url_substring"
end
6OLGH&3/V\QWD[
The command define url_rewrite defines rules for rewriting URLs in HTTP responses. The
URLs are either embedded in tags within HTML, CSS, JavaScript, or ASX documents, or they are
contained in HTTP response headers. In addition to rewriting URLs, you also can rewrite arbitrary
JavaScript. This transformation takes effect only if it is also invoked by a transform action in a
define action block and that block is in turn called from an action() property.
For each URL found within an HTTP response, a url_rewrite transformation first converts the
URL into absolute form, then finds the first rewrite_url_substring or rewrite_url_
prefix statement whose server_url_substring matches the URL being considered. If a
match is found, then that substring is replaced by the client_url_substring. Matching is
always case-insensitive.
The command transform invokes an active_content, JavaScript, or url_rewrite
transformation. The invoked transformation takes effect only if the transform action is used in a
define action block, and that block is in turn enabled by an action() property.
Note:
Any transformed content is not cached, in contrast with content that has been sent to a
virus scanning server. This means the transform action can be safely triggered based
on any condition, including client identity and time of day. The syntax is:
transform transformer_id
where transformer_id is a user-defined identifier for a transformer definition
block. This identifier is not case-sensitive.
206
Property
TWURL and Policy Checkpoints
6OLGH7:85/DQGSROLF\FKHFNSRLQWV
This diagram shows the code necessary to create, using two-way URL rewrite, a rule that allows
clients to request the site www.bluecoat.nl while actually receiving the content from the site
www.bluecoat.com.
The diagram shows the code necessary to implement two-way URL rewrite next to the checkpoint
where the ProxySG executes the requested actions. There are many more checkpoints than the one
discussed in this course; the actions necessary to implement two-way URL rewrite are executed on
the specified checkpoint or on checkpoints close enough to the one discussed in this diagram.
There are two sections in the code: One performs the headers and content modification; the other
performs the actual modification of the request, so that the ProxySG connects to the rewritten URL
and not to the one originally requested by the client.
The syntax of two-way URL rewrite often is confusing because you have one action with a
component that is applied to a request and one to the response. Keep in mind that request and
response are two components of the same transaction, so the action is applied to the entire
transaction.
This is the complete code:
<Proxy>
url=http://www.bluecoat.nl/ action.portal(yes)
define url_rewrite P
rewrite_url_prefix "http://www.bluecoat.nl/" "http://www.bluecoat.com/"
end
define action portal
rewrite( url, "http://www.bluecoat.nl/(.*)","http://www.bluecoat.com/$(1)" )
transform P
end
Here is how this policy works:

207
1.
The <Proxy> layer performs two-way URL rewrite on the request if the request matches a
client url for the server portal. If the ProxySG receives an HTTP request for the host
www.bluecoat.nl, then it executes the action portal. This action has two components:
A rewrite action, which effectively instructs the ProxySG to fetch a different URL
than the one requested.
A transform action, which changes the response received by the ProxySG.
2.
The rewrite() action rewrites the request URL, URL host, or components of the specified
header if it matches the regular-expression pattern. Only the host and port are available for
rewriting by the URL or URL host form when the client browser is using a proxy for an
HTTPS connection and the CONNECT or TUNNEL method is used. This is because the URL
path is encrypted and unavailable for rewriting.
3.
The define url_rewrite statement defines rules for rewriting URLs in HTTP responses.
Important: You do not need to have a forwarding rule if you implement the two-way URL
rewrite with the CPL code shown above.
208
Property
Chapter 17: Failover
Using failover, the Blue Coat ProxySG offers the capability to implement a redundant
configuration. Failover allows a second ProxySG to take over if one fails, providing redundancy to
the network through a master/backup relationship. In normal operations, the master (the
appliance whose IP address matches the group name) owns the address. The master sends
keep-alive messages (advertisements) to the backups. If the backups do not receive advertisements
at the specified interval, the backup with the highest configured priority takes over for the master.
When the master comes back online, the master takes over from the backup again.
The ProxySG failover implementation resembles the Virtual Router Redundancy Protocol (VRRP)
with the following exceptions:
A configurable IP multicast address is the destination of the advertisements.
The advertisement interval is included in protocol messages and is learned by the peers.
A virtual router identifier (VRID) is not used.
Virtual MAC addresses are not used.
MD5 is used for authentication at the application level.
Masters are elected, based on the following factors:
If the failover mechanism is configured for a physical IP address, the machine owning the
physical address has the highest priority. This is not configurable.
If a machine is configured as a master using a virtual IP address, the master has a priority that
is higher than the backups.
When a backup takes over because the master fails, an event is logged in the event log. Using IP
address failover, you can create a redundant network for any explicit proxy configuration. If you
require transparent proxy configuration, you can create software bridges to use failover. Using a
pool of IP addresses to provide redundancy and load balancing, the ProxySG migrates these IP
addresses among a group of machines. The ProxySG failover solution, the Security Gateways
Redundant Protocol (SGRP), uses an active/passive approach. SGRP is a fairly basic solution. All
proxies in the failover group share a virtual IP address (VIP) and are assigned a priority.
Important: While the IP address of the master ProxySG can be used as the VIP, use a neutral
IP address for the VIP so that you can access each machine individually. A
neutral IP address is one that is not being used by either machine.
The proxy with the highest priority is the master. The other proxies are all backups. Though all
proxies monitor the VIP and can answer requests, only the master replies to Address Resolution
Protocol (ARP) requests for the VIP. If the master fails, the backup with the highest priority
becomes the master. When the proxy that failed comes back online, it resumes the role of master.
This failover method is very similar to VRRP.
You can also create a failover configuration when the ProxySG is deployed in bridging mode.
There are two options available to you to create failover in bridging mode:
Parallel failover: Two or more ProxySG appliances are placed between two Layer 2 switches,
with one interface attached to each of the switches.
Serial failover: Two or more ProxySG appliances are connected one after the other, with one
network interface of the first proxy connected to the switch, and the other interface connected
with a cross-over cable to the other proxy.
209
Failover Basics and Configuration

ProxySG provides failover similar to VRRP
Two or more proxies are configured with a virtual IP
address
The master unit makes periodic multicast
announcements
If three announcements are missed, a standby assumes
the shared virtual IP address
6OLGH)DLORYHUEDVLFVDQGFRQILJXUDWLRQ
To configure failover, two or more ProxySG appliances are configured to share a VIP. In normal
operations, the master (the machine whose IP address matches the group name) owns the IP
address and answers all of the ARPs. The master sends keep-alive messages (multicast
advertisements) to the backups. If the backups do not receive advertisements at the specified
interval, the backup with the highest configured priority takes over for the master. When the
master comes back online, the master takes over from the backup again.
When a backup takes over because the master fails, an event is logged in the event log. No e-mail
notification is sent.
The same VIP can be assigned to as many proxies as necessary. You can also back up one proxy
with another by setting up multiple VIPs.
You can create a failover group using either a new IP address or an existing IP address. If the
group has already been created, you cannot change the new IP address without deleting the group
and starting over. When you configure failover, consider the following options:
New IP: IP address of VIP to take place in failover.
Existing IP: Physical interface of existing VIP.
Enable: Activates failover configuration. The enable option specifies whether this group is
active or inactive. Select enabled to enable the failover group.
Multicast address: Specifies where the master/failover advertisements are sent. The Multicast
Address option refers to a Class D IP address that is used for multicast. It is not a virtual IP
address. The multicast address has the form 224.x.x.x. The multicast IP address must be the
same for all members of the failover group; the proxies listen for multicast advertisements on
that IP address.
Note:
Class D IP addresses are reserved for multicast. A Class D IP address has a first bit
value of 1, second bit value of 1, third bit value of 1, and fourth bit value of 0. The
other 28 bits identify the group of computers that receive the multicast message.
210
Property
Relative priority: Weight of that system in the failover group. Relative Priority refers to a range
from 1 to 255 that is assigned to systems in the group. 255 is reserved for the system whose
failover group ID equals the real IP address.
Master: Identifies the system with the highest priority; for example, the appliance to be used
as the master.
Advertisement interval: Refers to the length of time in seconds between advertisements sent
by the group master. The default is 40 seconds. If the group master fails, the backup with the
highest priority takes over (after approximately three times the interval value). Set this value
to control the failover time of the group.
Group secret: Used to hash the information sent out in the multicast advertisement so that
someone cannot spoof the master. This secret must be the same for all members in the failover
group. The default secret is secret.
211
Basic Configuration
6OLGH%DVLFIDLORYHUGHSOR\PHQW
This diagram illustrates the simplest failover configuration. In this example, the client is
configured to send requests through a Layer 2 switch to the VIP shared by the ProxySG
appliances, which are configured in explicit proxy mode. The master ProxySG receives the client
requests and periodically sends multicast keep-alive messages to the network. In essence, the
master ProxySG answers all ARP requests to the VIP. The backup unit is connected to the network
but does not answer any ARP requests. While the master is active, you can access the backup unit
only directly through the backup IP address.
As mentioned before, the master periodically sends a multicast keep-alive announcement. (You
might have issues with certain switches; this creates an environment where both units are trying
to be the master.) If the master does not send three consecutive multicast keep-alive
announcements, a backup takes over for the master and services client requests. When a backup
takes over, it starts replying to the ARP requests for the VIP. Additionally, the backup sends
gratuitous ARP messages announcing that the IP has now moved over to this device.
Whenever you configure VIP, you must have all of the ProxySG appliances running the same exact
set of policies. Because a different proxy can start handling the traffic at any time, ensure that each
proxy handles the traffic in a consistent manner. ProxySG appliances participating in a failover
configuration do not automatically synchronize policies. You must manually reproduce policies
on all of the ProxySG appliances in the failover group, or you can use Blue Coat Director.
Important: While the failover VIP address can be the same address as that assigned to the
master, Blue Coat recommends assigning a separate IP address to the master and
backup, and having them share a third VIP for failover.
212
Property
Advanced Configuration
6OLGH$GYDQFHGIDLORYHU
The basic failover configuration discussed in the previous diagram suffers from a major drawback:
Only one machine is active at any given time. Using only one ProxySG does not maximize your
investment. You can create a double failover configuration using these steps:
Define two separate VIPs.
Assign each ProxySG to be the master for one VIP and backup for the other VIP.
Configure your PAC file to use a virtual name for the ProxySG.
Configure your DNS server to resolve the host name of the ProxySG to each of the VIP
alternatively (DNS round-robin).
The same caveats discussed for the simple failover configuration are true for this more advanced
configuration. In particular, the proxies involved in the failover must have the exact same policies
running. If the policies are not absolutely identical, users experience inconsistent behaviors when
accessing the Internet.
You can scale this configuration to any number of ProxySG appliances; you need to have as many
VIPs as you have ProxySG appliances; you also need to set the priority in which they take over
each other.
213
Parallel Bridging
6OLGH3DUDOOHOEULGJLQJ
The ProxySG supports two types of bridging:
Software (or dynamic): The bridge is constructed using a set of installed interfaces. Within each
logical bridge, interfaces can be assigned or removed.
Hardware (or pass-through): The bridge uses a 10/100 dual interface Ethernet adapter. This
type of bridge provides pass-through support.
The ProxySG supports Spanning Tree Protocol (STP), a link management protocol that prevents
bridge loops in a network that has redundant paths that can cause packets to be bridged infinitely
without ever being removed from the network. STP ensures that a bridge uses a path that is
loop-free. If that path fails, the algorithm recalculates the network and finds another loop-free
path. The administrator can enable or disable use of STP for the interface.
In parallel failover mode, which is shown in the above diagram, only software bridging can be
used. Here, two ProxySG appliances are deployed side by side on redundant paths. In parallel
failover, the backup does not actively bridge any packets unless the master fails. If the master fails,
the backup takes over the master IP address and begins bridging.
Blue Coat recommends that you enable STP if you use parallel bridging. Failure to do so might
have unpredictable results on the stability of your network infrastructure.
Note:
Bridge interfaces cannot be used in WCCP configurations. If the configuration

includes bridge interfaces, you receive the following error if you attempt to load the
WCCP configuration file: Interface 0:0 is member of a bridge.
214
Property
Serial Bridging
6OLGH6HULDOEULGJLQJ
In serial failover mode, the backup proxy is inline and continuously bridges packets, but it does
not perform any other operations to the bridged traffic unless the master fails. If the master fails,
the backup takes over the master IP address and applies policy. The above diagram shows a serial
configuration.
In this scenario, loop detection is not necessary. But you lose the advantage of having multiple
ProxySG appliances: You have failover but not load balancing. This feature, while simple to install
and configure, is not particularly advisable; it yields limited gains to the overall infrastructure.
To implement serial failover, use the command line interface to define a failover service. These
commands must be performed on each ProxySG:
#(config) bridge
#(config bridge) bridge-name
#(config bridge bridge-name) failover mode serial
#(config bridge bridge-name) failover group failover-VIP
In this example, bridge-name is the name of the bridge configuration on the ProxySG, and
failover-VIP is the same virtual IP address for each ProxySG.
The master proxies all traffic. When the master goes down, the backup proxies the traffic.
Note:
Serial bridging can be implemented only by using hardware bridging. Software

bridging cannot be used.
215
216
Property
Chapter 18: Health Checks
The Blue Coat ProxySG performs health checks to test for network connectivity and to
determine the responsiveness of external resources.
Information provided by health checks allows you to:
Detect potential network issues before they become critical. For example, if the health check
for an individual host fails, the ProxySG can send an alert (using e-mail, via SNMP, or by
writing to an event log) to designated recipients.
Track response times and report failures. For example, if the performance of a DNS server is
degraded, users can experience response-time delays. The DNS health check records the
average response time and allows you to interpret the reason for the performance reduction. If
the DNS server becomes unavailable, the failed health check triggers an alert.
The ProxySG uses health check information to:
Redirect traffic, in combination with failover configurations, when a device or service failure
occurs. For example, a health check can detect an unhealthy server, and a forwarding rule can
redirect traffic to a healthy server or proxy.
Monitor the impact of health check states on the overall health of the appliance. Health check
status is a metric in calculating the overall health of the ProxySG and is reflected in the health
monitor, which is located at the upper right hand corner of the Management Console. For
example, if a health check fails, the health monitor can displays a warning, and you can click
on the health monitor link to navigate and view the cause of the warning.
The main types of health checks.
How to create your own health checks.
How to configure settings and notifications for health checks, and how health checks can be
used in creating policy.
How to enable and disable health checks.
How to assign severity to health checks, and how that severity is reflected in health
monitoring.
217
Overview
Health check functions
IP address checks
Service responsiveness
Health check types

Automatically generated
Group
User-defined
Composite
6OLGH2YHUYLHZ
Health checks on the ProxySG have many names and perform many functions, but they all have
one of two main purposes:
Verify that a specific IP address is reachable within a specified response-time threshold. These
checks can verify forwarding hosts, SOCKS gateways, or other user-defined hosts.
Verify that a configured service is responsive. Checks in this category include authentication
servers, DNS servers, ICAP services, Websense off-box services, and the dynamic
categorization service of WebPulse.
There are two categories of health checks: automatically generated and user-defined.
Most health checks are automatically created and deleted when the underlying entity being
checked is created or deleted. A group health check consists of multiple checks and reports health
or sickness as a composite of all of the entities being checked. For example, when a SOCKS
gateway is created, the ProxySG automatically generates a health check object that tests whether
there is a SOCKS service running on the port that you specified in the gateway configuration. The
ProxySG opens a TCP connection on the specified port and then resets it. If the remote host accepts
the connection, the system is labeled as healthy; if the remote host fails to respond or resets the
connection immediately, the gateway is labeled as unhealthy or sick.
The ProxySG also supports two kinds of user-defined health checks: a host check to test a server,
and a composite check to combine the results of multiple checks (both automatically generated
and user-defined). A composite health check is not the same as a group health check. Composite
checks are user-defined; group checks are automatically created by the ProxySG and cannot be
deleted. However, settings for both types of checks can be modified.
218
Property
Automatic Checks
6OLGH$XWRPDWLFDOO\JHQHUDWHGKHDOWKFKHFNV
Depending on the service being checked, the ProxySG performs tests that are relevant to that
service in order to determine its health. There are four main categories of automatically generated
health checks:
Forwarding hosts and SOCKS gateways: The forwarding host health check configuration
defines whether the target being tested is a server or a proxy, which ports are available, and
provides the setting for the server certificate verification. The SOCKS gateways health check
configuration defines the SOCKS port, the version (4 or 5), and possibly a username and
password.
DNS servers: The DNS health check attempts to look up a configurable hostname. The default
hostname depends on the DNS configuration; for a server in the primary or alternate DNS
group, the default is www.bluecoat.com. For a server in a custom DNS group, the default is the
longest domain name listed in the group.
Authentication servers: Authentication health checks assess the realms health based on data
gathered during the most recent authentication attempt. Unlike most health checks,
authentication health checks do not probe the target realm with an authentication request.
Therefore, the health check reports healthy until the ProxySG records a failed authentication
attempt.
ICAP (virus scanning) and content filtering (Websense and dynamic categorization): The tests
for external services are specialized tests devised for each particular kind of external service.
The health check system conducts external service tests by sending requests to the external
services system, which reports back a health check result. The dynamic categorization service
health check is automatically created if you use Blue Coat WebFilter and the rating service is
enabled.
All health checks are given standardized names, based on the type of the target:
Forwarding hosts and groups have a prefix of fwd.
SOCKS gateways and gateway groups have a prefix of socks.
219
DNS servers have a prefix of dns.
Authentication realms have a prefix of auth.
External services have prefixes of icap, ws, and drtr.
In addition to the automatically generated health checks, the ProxySG also performs background
testing of DNS resolution on all resolvable hostnames used in the health check system, including
forwarding and SOCKS gateways. That way, the list of IP addresses associated with a hostname
stays current. The DNS system is checked whenever the time-to-live value of a DNS entry expires.
If a hostname consists of a numeric, four-octet IP address, no background DNS resolution is done.
When a host is resolved by DNS to multiple IP addresses, health checks keep those addresses
current through background updates, the timing of which can be configured. After the test or tests
are conducted for each IP address, the results are combined. If the result for any of the resolved IP
addresses is healthy, then the host is considered healthy because a healthy connection to that
target can be made.
220
Property
User-defined Checks
6OLGH8VHUGHILQHGKHDOWKFKHFNV
You can create, configure, and delete user-defined host health checks. These health checks support
everything an automatically generated health check contains, including background DNS
resolution monitoring and support for multiple addresses.
User-defined health checks can include:
ICMP (ping): The basic connection between the ProxySG and the origin content server is
confirmed. The server must recognize ICMP echoing, and any intervening networking
equipment must support ICMP.
TCP: Establishes that a TCP layer connection can be made to a port on the host. The
connection is then dropped.
HTTP or HTTPS: An HTTP or HTTPS test is defined by the URL supplied. The port used for
this test is as specified in that URL. If no port is explicitly specified in the URL, the port
defaults to the standard Internet value of 80 or 443.
SSL: A connection is made to a target, and the full SSL handshake is confirmed. The
connection is then dropped.
User-defined health checks cannot be created for external services such as authentication servers,
ICAP services, Websense off-box services, and dynamic categorization.
Under most circumstances, you do not need to create user-defined health checks. Automatically
generated health checks meet most needs, and you can modify the default sick/healthy
parameters, change the default test type, or add notification settings. However, you might need
tests to check for things that the ProxySG does not test automatically. For example, you can control
traffic based on the apparent health of the Internet. Using user-defined health check types, you can
target known Internet sites and modify settings to say that if a certain number of the sites are
221
You can create a composite health check to combine the results of multiple health checks. A
composite health check can contain any number of individual health checks. By default, all
members of a composite health check must be healthy in order for the composite check to report
healthy. However, you can configure the number of members that must be healthy for the
composite result to report healthy.
Composite health checks with no members always appear unhealthy.
User-defined and composite health checks are automatically assigned a prefix of user. This prefix
cannot be changed or deleted.
Note:
Use caution when creating user-defined health checks to test external Internet sites
that are not under your control. Frequently testing an external site might cause the
administrators of that site to object to the network traffic.
222
Property
Settings
Setting
Description
Healthy interval
Seconds between checks when healthy
Healthy threshold
Number of consecutive successes to be

considered healthy
Sick interval
Seconds between checks when sick
Sick threshold
Number of consecutive failures to be considered

sick
Failure trigger
threshold
Number of failed connections to trigger check
Response time
threshold
Maximum response time, in milliseconds
6OLGH+HDOWKFKHFNVHWWLQJV
In the Management Console, settings for health checks can be changed:
For individual checks. Go to Configuration > Health Checks > General > Health Checks, select a
health check from the list, click Edit, and click Override the default settings.
For all checks at once. Go to Configuration > Health Checks > General > Default Settings.
The above table shows the settings that can be changed.

The intervals healthy and sick represent the time that the ProxySG waits between checks of
the same resource. Different intervals can be specified for when the service is healthy or sick.
Similarly, the thresholds are counters of consecutive successes or failures of the health check. Only
when the threshold is reached does the status of the check transition to sick or healthy. The
intervals each have a default value of 10 seconds, and the thresholds each have a default value of
one.
The failure trigger threshold is disabled by default, but it can be useful when a service is not
always expected to respond 100% of the time. The number in the failure trigger threshold is the
number of times that a connection can fail before triggering a health check to verify the status of a
service. The count of failures is reset to zero every time a successful connection is made to that
service.
Similarly, the response time threshold is disabled by default, but when enabled, it can be used to
specify a maximum time that a service has to respond before triggering a new health check.
223
Notifications
6OLGH+HDOWKFKHFNQRWLILFDWLRQV
When the status of a health check changes, notifications can be sent three ways:
An e-mail notification can be sent to an administrator. E-mail addresses are specified by going
to Maintenance > Event Logging > Mail. The subject line of the e-mail identifies the health check
that has changed and the previous and current status of that health check.
In the event log, state changes can be logged as either informational or severe events. You can
enable notifications for each resolved IP address of a target device (if applicable), in addition
to the overall health of the device.
An SNMP trap can be configured to provide notification. It is part of the Blue Coat
Management Information Base as blueCoatMgmt 7.2.1.
By default, all notifications are disabled. To set notifications, you can change them globally (for all
health checks) or explicitly (for specific checks). You can separately enable notifications of
transitions to healthy and transitions to sick. A transition to healthy occurs as soon as the target is
sufficiently healthy to be sent a request, even though this might not mean complete health.
Each health check has a severity associated with it:
No effect: The success of this check has no impact on the health of the appliance. If the state of
this check transitions to unhealthy, the overall health status of the appliance does not change.
Warning: A failed health check implies an emerging issue about which the administrator
should be alerted.
Critical: The entity being checked is crucial to the continued operation of the appliance.
The severity for each check can be individually set in the Management Console. Go to
Configuration > Health Checks > General > Health Checks, select a check from the list, click Edit, and
then click Override for default notifications.
224
Property
Health Checks and Policy
6OLGH+HDOWKFKHFNVDQGSROLF\
In addition to the notifications mentioned on the previous page, the results of health checks can be
used in Content Policy Language to control the processing of traffic.
Two policy conditions exist for health checks:
health_check= : This condition tests whether the current transaction is a health check
transaction. Optionally, the condition tests whether the transaction is that of a specific health
check. Possible values are yes, no, and the name of a specific health check.
is_healthy.health_check_name= : This condition tests whether the specified health

check is healthy.
In the above simplified example, the user-defined health check user.internet tests for Internet
connectivity to cnn.com. If the health check fails, the forwarding layer policy shown above can be
used to redirect cnn.com traffic to alternate_route, which would be defined elsewhere in the
policy file and could be an alternate upstream proxy.
There are two other important interactions between health checks and policy:
The results of a health check can be affected through forwarding, SOCKS gateway, or SSL
certificate policy. The health check transactions execute the <forward> layer and (for SSL or
HTTPS tests) the <ssl> layer to determine applicable policy. This allows health check
behavior to match as closely as possible the behavior of the SSL traffic that the health check is
monitoring.
Health checks cannot be deleted while referenced in policy. If a health check is automatically
deleted when its target is deleted, a reference to the health check in policy can block deletion
of the health check and its target.
225
Enabled and Disabled States
6OLGH(QDEOHGDQGGLVDEOHGVWDWHV
Each health check can be individually enabled or disabled and configured to report as healthy or
sick during the time it is disabled. To edit the enable state of a health check in the Management
Console, go to Configuration > Health Checks > General > Health Checks, select a health check from
the list, and click Edit.
Setting a health check at Enabled is the default and causes the check to be performed normally
according to its other settings.
Setting a health check as Disabled but reporting healthy allows the ProxySG to use the device or
service without performing health checks on it. If a group health check is disabled but
reporting healthy, all of the members of the group are treated as healthy, regardless of the
status of the group members individual health checks. The individual health checks remain
active; they still can be used apart from the group.
Setting a health check as Disabled but reporting sick is useful when removing an upstream
device for servicing, testing, or replacement. This setting takes the device offline after is
completes processing any pre-existing traffic. The device then can be safely disconnected from
the network without altering any other configuration.
In the above example, three health checks are configured:
The health check on Server 1 is not performed; it always reports as healthy.
The health check on Server 2 is performed normally; if it fails, the severity of the health check
is passed to the health monitor.
The health check on Server 3 is not performed, and the severity of that health check is passed
to the health monitor.
226
Property
Health Monitor
6OLGH+HDOWKFKHFNVDQGWKHKHDOWKPRQLWRU
The ProxySG health monitor displays the overall health of the appliance by considering the health
of hardware components (such as CPU temperature and fan speed), system metrics (such as
processor and memory utilization), and configured services. Health checks are the means by
which the overall health of configured services is evaluated by the health monitor.
The health status is displayed on every page of the Management Console and is one of three
values: OK, Warning, or Critical. This reflects the most acute condition among the configured health
checks, as defined by the severity of each health check.
In the above example, three health checks are configured: a DNS server check with severity No
effect, a forwarding host with severity Warning, and an authentication server with severity Critical.
Assume that there are no health issues with hardware components and system metrics. The table
shows the overall health check status for all possible outcomes of these three health checks:
If all three checks report healthy, then the health check status is OK.
If the authentication server check reports sick, then the health check status is Critical,
regardless of the status of the other two checks.
If the forwarding host check reports sick, then the health check status is either Warning or
Critical, depending on the status of the authentication server check.
If the DNS check reports sick, this does not effect the overall health check status because its
severity is set to No effect. The health check status is determined by the condition of the
forwarding host and authentication server checks.
227
228
Property
Chapter 19: Web Cache Communication Protocol
The Web Cache Communication Protocol (WCCP) was developed by Cisco Systems and specifies
interactions between one or more routers (or Layer 3 switches) and one or more Web caches.
The purpose of the interaction is to establish and maintain a transparent redirection of selected
types of traffic flowing through a router. The selected traffic is redirected to Web caches, such as
the Blue Coat ProxySG, with the aim of optimizing resource usage and lowering response
times.
The main benefits of using WCCP are:
Scalability: With no reconfiguration overhead, redirected traffic can be automatically

distributed to up to 32 appliances.
Redirection safeguards: If no appliances are available, redirection stops and the router
forwards traffic to the original destination address.
How WCCP redirects requests from a router to the ProxySG.
How a router uses WCCP to communicate with the ProxySG.
How to configure WCCP on the ProxySG.
How to monitor the status of a WCCP connection.
This chapter assumes that you are using WCCP version 2.0, the current and most widely used
version of the protocol. Also, this chapter does not discuss the details of configuring WCCP on a
router.
229
Overview
Web Cache Communication Protocol by Cisco
Available on Cisco routers and L3 switches
Works with ProxySG to achieve transparent proxy
Support for other ports and protocols
HTTP, HTTPS, FTP
Multiple router deployment
Multicast interaction
Does not support IPv6
Blue Coat Systems, Inc. 2010. All Right s Reser ved.
6OLGH2YHUYLHZ
WCCP is supported on various models of Cisco routers and Layer 3 switches. WCCP version 2.0
requires the equipment to have at least IOS version 12.0(3). A WCCP-capable router operates in
conjunction with the appliances to transparently redirect traffic to a set of caches. IP packets are
redirected based on fields within each packet.
You can balance the load on the caches in a service group. When a router receives an IP packet for
redirection, it hashes fields within the packet to yield an index within the hash table. The packet is
forwarded to the owner ProxySG for servicing. The number of redirection hash tables assigned to
each ProxySG can be altered to provide a form of load balancing among caches in a service group.
A hash table is configured by a dynamically elected ProxySG in a service group, enabling the
simultaneous interception of multiple protocols on multiple ports. You can configure up to 256
dynamic or standard service groups. A single service can intercept up to eight port numbers.
The ProxySG and routers become aware of one another and form a service group using WCCP
management packets. Once the service group has been established, one of the ProxySG appliances
is designated to determine the load assignments among other ProxySG appliances. All ProxySG
appliances periodically communicate with the home router to verify WCCP synchronization and
ProxySG availability within the service group. In return, the home router responds to each
ProxySG with information as to which appliances are available in the service group.
WCCP does not support IPv6. For this reason, WCCP cannot be used in IPv6 deployments.
Note:
Blue Coat recommends that WCCP-compliant caches from different vendors be kept
separate and that only one vendors routers be used in a service group.
230
Property
Packet Exchange
6OLGH3DFNHWH[FKDQJH
During the WCCP discovery process:

1.
The ProxySG sends a Here_I_Am packet periodically to a configured WCCP-capable router.
2.
The Router replies with an I_See_You message to verify the connectivity between the router
and the ProxySG.
3.
The ProxySG joins the WCCP-capable router by periodically unicasting or multicasting

Here_I_Am packets at a fixed interval. The source IP address of the Here_I_Am uniquely
identifies the ProxySG. The router sends an I_See_You packet back to the ProxySG in
response to each Here_I_Am it receives.
To specify the address of the WCCP-capable router in the service group, use one of the following
methods:
Unicast: The IP addresses of the router is explicitly defined in the ProxySG.
Multicast: A single multicast address is configured on all ProxySG appliances.
Important: Valid multicast addresses supported by the ProxySG are in the range of 224.0.0.0
to 239.255.255.255. The routers also must be configured to listen to the same
earlier configured multicast address by using ip wccp group-listen
command.
231
WCCP Deployment
6OLGH:&&3GHSOR\PHQW
WCCP requires that each ProxySG be aware of all of the routers in the service group. Optionally,
WCCP can use multicast packet exchange for discovery. Configuring a multicast address on a
WCCP-capable router reduces WCCP traffic and provides the ability to easily add and remove
caches and routers from a service group without having to reconfigure all service group members.
As shown in the above diagram, the following sequence of events explains how WCCP works:
1.
Each ProxySG performs a WCCP discovery process by sending Here_I_Am packets to the
configured list of routers. Routers build a list of all ProxySG appliances that are visible.
2.
Clients send requests to different routers.
3.
WCCP-capable routers redirect any configured TCP traffic to the ProxySG, such as port 21
(FTP), port 554 (RealMedia and QuickTime), and port 1755 (Windows Media).
4.
The ProxySG processes and applies configured policy. If the clients request is not denied, it
resends the request to the Internet and fetches the Web objects from the origin content server.
232
Property
Redirection of Requests
6OLGH5HGLUHFWLRQRIUHTXHVWV
As requests from clients user agents arrive at the router, the router intercepts the request and
forwards it to the ProxySG.
There are three ways by which the request can be intercepted and forwarded to the router:
GRE forwarding and return: Generic Routing Encapsulation is the default forwarding method
performed by the router. Using GRE, redirected packets are encapsulated in a new IP packet
with a GRE header.
L2 MAC rewrite forwarding and return: Using L2 MAC rewrite, redirected packets are not
encapsulated. Instead, the MAC address of the target cache replaces the packets destination
MAC address. This way of directing packets saves the overhead of creating the GRE packet at
the router and decoding it at the cache. Also, it saves network bandwidth that would
otherwise be consumed by the GRE header. L2 MAC rewrite, however, requires that both the
ProxySG and the WCCP-capable router to be in the same broadcast domain.
L2 forwarding with GRE return: This option is available for WCCP configurations in which L2
packet return is not supported. This allows the ProxySG to be used with a wider variety of
routers.
233
Router Affinity
6OLGH5RXWHUDIILQLW\
By default, if a connection is bypassed in a virtual in-line WCCP deployment, the ProxySG

redirects the packets back to the originating WCCP router using its negotiated return method. On
the other hand, if the connection is intercepted, client- and server-bound packets from the
ProxySG use the configured route table to determine the next hop. Because of this, there is no
guarantee that these packets traverse a network path through the WCCP router that initially
redirected the traffic. This usually does not cause issues; however, in some cases, this might
disrupt traffic if the ProxySG is not configured correctly and packets are misrouted.
Router affinity ensures that the client- and server-bound packets from the ProxySG always are sent
back through the originating WCCP router via the negotiated return method, bypassing route
lookup. This feature simplifies the deployment of the ProxySG by:
Minimizing the amount of route configuration on the ProxySG. This reduces the potential of
outbound ProxySG packets being misrouted.
Allowing policy based routing to continue to be maintained at a single point on the existing
routers. Therefore, these policies do not need to be replicated on the ProxySG.
Note:
By using this feature in GRE return deployments, handling of GRE-encapsulated

packets adds additional CPU overhead to the WCCP routers and reduces the TCP
maximum segment size to avoid IP fragmentation.
To illustrate the benefit of using router affinity, the above example shows a specific network layout
where the GRE forward/GRE return configuration is used. R1 and R2 are routers; R1 is a
WCCP-enabled router. R2 does not route to subnets 1 and 2, but it is the default router for the
ProxySG. The diagram illustrates the case when the client in subnet 1 sends packets to a server in
subnet 2, and R1 redirects the packets to the ProxySG via GRE forwarding. Dashed arrows
represent GRE-encapsulated packets.
The diagram on the left shows the default behavior when router affinity is not enabled. Packets
returning from the ProxySG are dropped by R2 because it does not have routing information to
subnet 2.
234
Property
The diagram on the right shows what happens if the router affinity feature is enabled. Enabling
this feature GRE-encapsulates client-bound and server-bound packets with a destination IP
address of the originating WCCP router for intercepted connections. This alleviates the misrouting
of packets destined for subnet 2 by R2 without any additional route configuration on R2.
Router affinity can be enabled for service groups, not individual routers. Therefore, to enable this
feature for some routers and disable it for others, create one service group for the routers that have
the feature enabled and a separate service group for the routers that have the feature disabled.
Each service group can have one of the following router affinity types:
Client: All packets for the client-side connection are returned back to the WCCP router, and all
server-side packets are subject to the standard route lookup.
Server: All server-side packets are routed back to the originating WCCP router, and the
client-side packets are subject to the standard route lookup.
Both: Both the client-side and server-side packets are returned back to the originating WCCP
router.
The router affinity setting must be consistent across all service groups on each router.
235
WCCP Configuration
6OLGH:&&3FRQILJXUDWLRQ
WCCP must be enabled and configured on both the ProxySG and the router before attempting to
send WCCP traffic to a router. In the Management Console, go to Configuration > Network > WCCP
and select Enable WCCP if it is not enabled.
Three methods are available to configure WCCP on the ProxySG:
The user interface of the Management Console.
Installing a file that you create with a text editor.
The command line interface.
Of these methods, the Management Console usually is the easiest to use.

The first step in configuring WCCP is to specify which version of the protocol you are using.
WCCP versions 1.0 and 2.0 both are supported, but version 2.0 is by far the most common version
in use and is the version recommended by Blue Coat. The remainder of this section assumes that
you are configuring WCCP version 2.0.
Next, create a service group or edit an existing one. As shown in the above diagram, some of the
items that you can specify include:
1.
Priority: When multiple service groups that are redirecting the same traffic (for example,
HTTP on port 80) are assigned to a common router interface, the priority defines the order in
which the router evaluates the service groups.
2.
Interface: Apply the service group to a physical or a virtual interface.
3.
Weight: Determines the proportion of traffic that the router redirects to this ProxySG. The
weight value can range from 1 to 255. Use this field only if you have multiple ProxySG
appliances in the service group and you need to allocate the amount of traffic redirected to
each ProxySG in the service group.
236
Property
4.
Ports to redirect: Specifies the direction of traffic to redirect to the ProxySG for this service
group (source, destination, or all), the protocol (TCP or UDP), and the port numbers. You can
list up to eight ports for each service group.
5.
Forwarding and return types: Defines the forwarding method and the return method (L2 or
GRE) for the router to forward packets or to return bypassed packets to the ProxySG.
6.
Router addresses: For a multicast home router, add the group address and a time-to-live (TTL)
for each request. The default TTL value is 1. For an individual home router address, add the IP
address for each router in the service group. The home router address that you use for a
service group on the ProxySG should be consistent with the IP address (virtual or physical)
over which the ProxySG communicates with the router.
7.
Assignment type: Instructs the router how to distribute redirected traffic using the
information in the packet header. You can select a different assignment method for each
service group configured on the same ProxySG.
237
WCCP Statistics
6OLGH:&&3VWDWLVWLFV
The ProxySG Management Console displays the status of WCCP service groups. Go to Statistics >
Network > WCCP; this display shows the following information for each configured service group:
Cache IP address: The designated Web cache (the ProxySG with the lowest IP address) for the
service group.
Router IP address: The router ID.
State: Displays the availability of the service group.
Protocol messages: Number of packets sent and received for Here_I_Am and I_See_You
messages and redirect assignments. The count is reset when WCCP is disabled.
These statistics are not updated automatically while the display is active. To update the statistics,
click Refresh WCCP Statistics.
To monitor WCCP traffic on the router, use this command:
Router# show ip wccp service-group

where service-group optionally specifies a service group about which to display statistics.
Note:
You might see many packets under Total Packets Unassigned at the initial discovery
of the ProxySG or when the ProxySG is dropped from a cluster.
238
Property
Chapter 20: VLAN Support
A bridged/switched network is designed to enhance network services by partitioning the

network into multiple broadcast domains. However, the fact remains that in a switched/bridged
environment, if there is no proper mechanism to mediate the connection, the networked devices
are still within a single broadcast domain in which every node in the broadcast domain can receive
each others frames.
To overcome the bandwidth saturation problem caused by frames flooded out to all ports on a
bridged/switched deployment, administrators employ routers, which operate at Layer 3 of the
OSI model, to physically divide the network into multiple broadcast domains.
A Virtual Local Area Network (VLAN) is a logical broadcast domain that spans multiple physical
LAN segments. Unlike the routers that split the network based on its physical location, VLANs
can logically group switch ports and their connected users by functions, departments, or
applications. The Blue Coat ProxySG treats VLAN interfaces identically to traditional physical
LAN interfaces.
The advantages of using VLANs are:
Enhanced performance: While the number of broadcast domains is increased, the size of each
broadcast domain is reduced. This increases network efficiency.
Simplified network management: The addition, relocation, and deletion of nodes can be
configured quickly and conveniently from the ProxySG Management Console rather than
from the wiring closet.
Reduced hardware requirements: A machine can stay on the same VLAN without the need for
any hardware reconfiguration. It is a simple matter of configuring a port into the VLANs
when a new member joins.
Increased broadcast control: Administrators can configure a VLAN to map directly to an IP

network or subnet.
Improved security options: Separating systems that have sensitive data from the rest of the
network decreases the chances that people will gain access to information they are not
authorized to see.
VLANs complement a switched and routed network by having the ability to place segments
(ports) in individual broadcast domains. A router still is needed to route traffic from one domain
to another.
With VLANs, each switch can distinguish traffic from different broadcast domains. Each
forwarding/switching/filtering decision can be made based on the origin of the frame.
To bridge/switch between the switches, each VLAN must be configured to connect to other
VLANs independently or have some mechanism in place to forward the frames with its associated
VLAN information encapsulated in the packet.
239
VLAN Concepts
6OLGH9/$1FRQFHSWV
VLANs are a Layer 2 implementation in a bridged/switched network topology. For a VLAN to

span multiple switches on a single connection, a trunk is required to connect two switches
together. The trunk does not belong to a single VLAN. It carries traffic from several VLANs over a
point-to-point link between two devices that understand the protocol.
With the trunk in place, inter-switch information exchange can be achieved through frame
tagging.
Frame tagging is a Layer 2 process in which each frame is configured to carry the VLAN
membership in the frame header when the frame is transmitted over the inter-switch trunk as
shown in the above diagram, allowing each switch to make the switching decision upon
individual frame reception.
The trunk port (inter-switch port) on each switch marks frames as they exit the port to indicate
which destination VLAN it is associated with. The trunk port can also read the markings or tags of
the incoming frames as they enter the trunk port.
The VLAN frame-tagging mechanism is standardized by IEEE 802.1Q specification Virtual Bridged
Local Area Networks.
240
Property
VLAN Tags
6OLGH9/$1WDJV
The above diagram illustrates the frame header encapsulating the VLAN tag information for an
Ethernet frame. When the protocol field is replaced by the Tag Protocol Identifier (TPID) 0x8100 in
an Ethernet frame, it indicates the presence of the VLAN Tag Control Information (TCI) field.
In a VLAN TCI field:
The three-bit Priority field represents priority from 0 to 7. These bits indicate the priority of the
frame for quality of service use.
The one-bit Canonical Format Indicator (CFI) flag field indicates whether all of the MAC
address information that might be present in the MAC data carried by the frame is in the
canonical format.
The 12-bit VLAN ID (VID) identifies the VLAN to which the frame belongs. Special values for
this field include:
VID
Meaning
0x0
Null VID: Contains user priority information only. No VLAN identifier is

present in the frame. The VID cannot be configured on any port.
0x1
Default port VID (PVID): Classifies packets based on an ingress rule

through a bridged port.
0xFFF
Reserved for implementation use; not used for PVID assignment.
241
VLAN Processing
VLAN tags
Only processed by VLAN-aware network devices
VLAN-unaware devices drop VLAN tags
Trunked ports on a switch
Accept all VLAN-tagged frames
Accept untagged frames
Non-trunked ports on a switch
Accept untagged frames and frames tagged with the ports
native VLAN
Drop all other tagged frames
6OLGH9/$1SURFHVVLQJ
There are three types of frames:
Priority-tagged frame: A tagged frame whose tag header carries a null VID value.
VLAN-tagged frame: A tagged frame whose tag header carries a VID value.
Untagged frame: A frame that has no VLAN tag header.
A host not specifically configured for a VLAN drops VLAN-tagged frames.

Trunked ports on a switch accept all VLAN-tagged frames. They also accept untagged frames and
assume that they belong to the ports native VLAN.
Non-trunked ports accept only untagged frames and frames tagged with the ports native VLAN.
All other tagged frames are dropped.
242
Property
VLAN Physical Interfaces

Native VLAN
States the native VLAN for the port
Default value is 1; valid values are 1 to 4094
#(config interface 0:0) native-vlan value
VLAN trunk
Controls VLAN trunking on the port
Enabled by default
Status can be changed through CLI only
#(config interface 0:0) vlan-trunk disable
#(config interface 0:0) vlan-trunk enable
6OLGH9/$1SK\VLFDOLQWHUIDFHV
A ProxySG VLAN interface (IP address and subnet) can be configured through the command-line
interface or the Management Console. VLAN trunking allows bridging between VLAN tagged
and untagged ports.
Trunking is enabled by default and must be enabled on all bridging interfaces. When VLAN
trunking is enabled, a trunk link is created on the interfaces to bridge VLAN traffic across the
switches.
VLAN-specific interface configuration commands also can be accessed through the CLI.
To configure a native VLAN on the given network interface:
#(config interface 0:0) native-vlan value

where value is between 1 (the default) and 4094. If another VLAN already exists with the given
VID, then an error message indicating a configuration conflict is displayed.
To disable or enable trunking on an interface:
#(config interface 0:0) vlan-trunk mode

where mode is enable or disable.
Note:
The 0:0 in the config interface command denotes adapter:interface. For

example, the command config interface 0:1.5 command takes you to the
VLAN configuration menu for VLAN 5 on interface 0:1.
243
VLAN Trunking
6OLGH9/$1WUXQNLQJ
When a packet is intercepted by the ProxySG where a VLAN has been configured, the ProxySG
takes the following actions:
The ProxySG checks the packets destination IP address. If it matches (in other words, if this is
an explicit proxy deployment):
If trunking is enabled, then the ProxySG accepts the packet.
If trunking is not enabled and the VLAN ID matches the ID of the native LAN, then the
ProxySG accepts the packet.
Otherwise, the packet is not intended for this VLAN, so it is discarded.
If this is a transparent proxy deployment:
If trunking is enabled, then the ProxySG bridges the packet with a VLAN tag.
If trunking is not enabled and the VLAN ID matches the ID of the native lan, then the
ProxySG bridges the packet without a VLAN tag.
Otherwise, the packet is not intended for this VLAN, so it is discarded.
244
Property
VLAN Transparent Deployment
6OLGH9/$1WUDQVSDUHQWGHSOR\PHQW
In a WAN acceleration environment, the ProxySG must be deployed so that traffic going to
another ADN peer is intercepted.
Bridging is the preferred deployment option in most enterprises because it does not require
reconfiguration of routers or switches. In a bridging network environment, the ProxySG can be
placed between the switch and the edge router as shown in the diagram above.
The challenge, however, is the connectivity between the switch and the router: the trunk link that
carries traffic for multiple VLANs. The router usually performs inter-VLAN routing or enforces
access-control policies between different VLANs. To complement the routers functionalities, the
ProxySG is designed to understand the trunking protocol and to perform seamless trunking
between the router and the switch.
Being able to understand multiple VLANs in a trunk link gives the ProxySG the capability to
handle different VLANs differently, as shown in the behavior of the three VLANs in the above
example.
To view and change VLAN trunk link options in the Management Console, select Configuration >
Network > Adapters, and then click New VLAN to create a new VLAN or Edit to edit an existing one.
Under When receiving packets on this VLAN, there are four options:
Use physical interface setting applies the same configuration to the VLAN as was set on the
physical interface.
Allow transparent interception: The ProxySG intercepts the appropriate traffic based on settings
configured in Configuration > Services; all other traffic is bridged or forwarded.
Bypass transparent interception: The ProxySG bridges or forwards all inbound traffic on this
interface, regardless of the services configuration.
Firewall incoming traffic: The ProxySG drops all inbound connections on this interface,
regardless of the services configuration.
245
VLAN Explicit Deployment
6OLGH9/$1H[SOLFLWGHSOR\PHQW
In VLAN explicit deployment, the ProxySG is configured with multiple subinterfaces.

Once that is done, client computers from different VLANs can configure their browsers to point
explicitly to the IP address of the subinterface. This likely is a local address to them because it has
the same subnet address. This eliminates the need for clients to go through a router to access the
ProxySG.
In the above example, each of the three VLANs is able to communicate directly with the ProxySG
over the trunk link connected to interface f0:0.
246
Property
VLAN Support for WCCP
6OLGH9/$1VXSSRUWIRU:&&3
When configuring WCCP on the ProxySG, you can specify VLAN interfaces so that LAN traffic
can be handled differently from WAN traffic.
In an in-path, bridged deployment, the ProxySG can distinguish traffic coming from the LAN
from traffic coming from the WAN based on the interface on which it receives a packet. However,
in a WCCP deployment, traffic from both the LAN and WAN is redirected from the WCCP router
to the ProxySG over a single physical interface.
If you want the ProxySG to handle LAN traffic differently from WAN traffic, you can create two
separate VLAN interfaces on the ProxySG. One interface is for LAN traffic, and the other is for
WAN traffic. To use this feature, create a VLAN trunk between the WCCP interface on the
ProxySG and the network device to which it is connected. Then, create VLANs on the ProxySG
and all other network devices in-path to the WCCP router. Create separate WCCP service groups
one for LAN traffic and one for WAN traffic and apply them to the corresponding VLAN
interfaces that you defined for your LAN and WAN traffic.
In the above sample deployment, the ProxySG communicates with a WCCP router through a
Layer 2 switch. Two service groups are required: one for client-side traffic, and one for server-side
traffic.
Client-side traffic is associated with a service group on VLAN 3, so the home router must be an IP
address that resides in VLAN 3 on the WCCP router. Similarly, server-side traffic is associated
with a service group on VLAN 4, so the home router must be an IP address that resides on VLAN
4 on the WCCP router. The default gateway for this deployment can be the home router IP address
on either VLAN 3 or VLAN 4. For this example, the default gateway is on VLAN 4. Redirect-in
rules are then applied to both VLAN 2 and the WAN-facing interface on the WCCP router.
Intercepted traffic: Client-side traffic is redirected to the ProxySG and is tagged with VLAN ID
3; server-side traffic is redirected to the ProxySG and is tagged with VLAN ID 4. All outbound
traffic from the ProxySG is on VLAN 4 because the default gateway for this example is in
VLAN 4.
247
Bypassed traffic: Client-side traffic that is being redirected to the ProxySG is tagged with
VLAN ID 3. This traffic is returned to the WCCP router and is tagged with VLAN ID 3
because the traffic is configured to be bypassed. The router forwards the packet to the server
as if the packet was never redirected to the ProxySG. Server-side traffic is also redirected to the
ProxySG due to the redirect-in rule on the WAN-facing interface of the WCCP router. This
traffic is tagged with VLAN ID 4. The ProxySG returns the traffic to the WCCP router tagged
with VLAN ID 4. The router then forwards the packet to the client as if the packet was never
redirected to the ProxySG.
248
Property
Chapter 21: Managing Streaming Media
At its most basic, streaming media is a form of content delivery. Streaming media is used to
deliver many types of content such as audio, video, and stock tickers. With streaming media, a
user can watch or listen to the content without having to wait for the entire file to download before
it can be played.
Streaming media support on the Blue Coat ProxySG provides the following features:
Streaming media files can be live or pre-recorded.
Flexible delivery methods: unicast, multicast, HTTP, TCP, and UDP.
The ability to seek, fast-forward, reverse, and pause (video-on-demand only).
The ability to play an entire file and control media playback, even before it is downloaded.
The ability to adjust media delivery to available bandwidth, including multi-bit-rate and
thinning support.
Using the ProxySG for streaming delivery minimizes bandwidth use by allowing the ProxySG to
handle the broadcast and allows for policy enforcement of streaming use. The delivery method
depends on whether the content is live or video-on-demand.
Additionally, there are many ways that the ProxySG can be used to make streaming media more
easily available and less of a burden on your network:
Type of streaming media: live or video-on-demand.
Delivery method: unicast or multicast.
Caching: video-on-demand content can be fully cached or partially cached on the ProxySG
appliance for easy and quick access.
Managing bandwidth: through configuration, the administrator can place bandwidth limits
on both the server side and client side.
The ProxySG allows you to control and maximize the use of streaming media over your network.
Commonly used streaming media content can be managed in such a way that it is readily
available for use.
The ProxySG supports the following streaming media formats and versions:
Windows Media: Player versions 7 through 11, server version 9.
RealMedia: RealOne Player version 2, RealPlayer versions 8 and 10, RealServer

versions 8 through 10, Helix Universal Server, Helix Player version 11.
QuickTime: Player versions 5.x, 6.x, and 7.x, Darwin Streaming Server versions 3.x and 4.1.x,
Helix Universal Server. The ProxySG does not cache QuickTime content (.mov files). All
QuickTime content is served in pass-through mode only.
249
Overview
Streaming media content types
Live streams
Video-on-demand
ProxySG features
Content pre-population
Authentication
Partial and complete object caching
Split streaming
MMS and RTSP services
6OLGH2YHUYLHZ
In the context of the ProxySG, there are two types of streaming media content:
Live streams: Media content that is occurring live. These streams are watched in real time as
they are happening, so they are not cached on the ProxySG.
Video on demand: This type of streaming media content can be accessed at any time.
Additionally, it can paused, rewound, and fast-forwarded at the control of the viewer. Because
this streaming media content is stored on a media server, it can be cached on the ProxySG.
The ProxySG supports a variety of acceleration, control, and visibility features for streaming
media:
Content pre-population: The ProxySG can be pre-populated with data from an OCS. This
makes it possible for administrators to use server-side traffic during off-peak hours, leaving it
available for traffic during business hours.
Authentication: If content that has been cached on the ProxySG requires authentication on its
OCS, it also requires authentication if it is coming from the ProxySG.
Partial and complete caching: Content can be cached completely or partially. Completely
cached content makes it possible for the client to access the content without ever having to
connect to the OCS. When accessing partially cached content, the client receives the cached
data from the ProxySG, and whatever data is missing comes from the OCS.
Split streaming: The ProxySG can take a single live video stream of video and then split it
locally into enough streams to serve all local viewers.
By default, the ProxySG has streaming services configured on ports 1755 (MMS) and 554 (RTSP).
The services are configured to listen to all IP addresses but are set to bypass.
250
Property
Processing Streaming Content
6OLGH3URFHVVLQJVWUHDPLQJFRQWHQW
The ProxySG can support a multitude of multicasting forms such as multicast-to-unicast,

unicast-to-multicast (shown above), and multicast-to-multicast. The ProxySG supports two
methods for delivering streaming media: unicast and multicast.
The following describes the behavior of the connections for live and video-on-demand unicast
connections:
Live: A ProxySG can serve many clients through one unicast connection by receiving the
content from the origin content server and then splitting that stream to the clients that request
it. This method saves server-side bandwidth and reduces the server load. You cannot pause or
rewind live broadcasts. A live broadcast can be of pre-recorded content. A common example is
a company president making a speech to all employees.
Video on demand: An ProxySG can store frequently requested data and distribute it upon
client requests. Because the ProxySG is closer to the client than to the origin server, the data is
served locally, which saves firewall bandwidth and increases quality of service by reducing
pauses or buffering during playback. The ProxySG provides higher-quality streams (also
dependent on the client connection rate) than the origin server because of its closer proximity
to the end user. VOD content can be paused, rewound, and played back. Common examples
include training videos and news broadcasts.
The ProxySG can take a unicast stream from the OCS and deliver it as a multicast broadcast. The
ProxySG takes a one-to-one connection and splits it into a one-to-many stream. This saves
bandwidth on the server side.
251
Large-scale Streaming Delivery
6OLGH/DUJHVFDOHVWUHDPLQJGHOLYHU\
This diagram shows how the ProxySG can be used to successfully distribute streaming media
content over a WAN while saving bandwidth.
In this deployment, there only needs to be one connection to the origin media server. The first
ProxySG is able to take the streaming date from the media server and redistribute it as is
necessary. The two clients connected to the first ProxySG can access the data through it, instead of
directly connecting to the media server.
The two remote locations also can access the streaming media content from the media server
through their own ProxySG appliances. The first ProxySG has established a multicast connection
with the ProxySG appliances; it took the single connection from the media server and established
two with the other ProxySG appliances. From there, each ProxySG can stream the content to its
individual network.
252
Property
Limiting Bandwidth
6OLGH/LPLWLQJEDQGZLGWK
The ProxySG is able to control the amount of bandwidth on both the server side and client side.
This can be used to limit the amount of bandwidth can be used up when video or audio content is
being streamed. With proper configuration methods, this lets you reduce the amount of
bandwidth used for streaming media.
Streaming media bandwidth limitations are achieved by configuring the ProxySG to restrict the
total number of bits per second the appliance receives from the origin media servers and delivers
to clients. The configuration options are flexible to allow you to configure streaming bandwidth
limits for the ProxySG, as well as for each streaming media format (Windows Media, RealMedia,
and QuickTime).
Note:
Bandwidth claimed by HTTP, non-streaming protocols, and network infrastructure is

not constrained by this limit. Transient bursts that occur on the network can exceed
the hard limits established by the bandwidth limit options.
If a client makes a streaming-media request after a limit has been reached, the client receives an
error message.
Note:
If a maximum bandwidth limitation has been specified for the ProxySG, the following
behavior can occur. If a RealMedia client, followed by a Windows Media client,
requests streams through the same ProxySG and total bandwidth exceeds the
maximum allowance, the RealMedia client enters a rebuffering state. The Windows
Media client continues to stream.
253
Caching
6OLGH&DFKLQJ
The ProxySG also has the ability to cache streaming media. This allows for easy access to
streaming media data without having to connect to the OCS. However, it is not possible to cache
data from live streams.
Once video-on-demand data has been cached on the ProxySG, the clients no longer have to
connect to the OCS to access the data. The video is now stored on the ProxySG, and bandwidth is
saved on the server side, because there is no traffic. In the example above, Client A is requesting
streaming data that has been cached on the ProxySG. Because the data was cached, there is no
need to connect to the OCS.
Additionally, the ProxySG can have partially cached video on demand. In this instance, the client
connects to the ProxySG and begins streaming the data from there. Once the client reaches the
point where partial data ends, the client begins to receive data from the OCS; the stream continues
as though the data was not cached. Bandwidth is reduced here, since the client does not have to
connect to the OCS to stream the entire video file. Unlike Client A, Client B has requested data that
has only been partially cached on the ProxySG. Note that Client B only has to connect to the
ProxySG to retrieve the cached data but then has to connect to the OCS to receive the rest of the
file.
Clients C and D are requesting live streaming media; therefore, they must connect to the OCS
because the ProxySG cannot cache live data.
254
Property
Cache Content Pre-population
6OLGH&DFKHFRQWHQWSUHSRSXODWLRQ
The ProxySG can be pre-populated with streaming media content. This allows the administrator
to make the content immediately available. This can be done at any time, but if it is done during
off-peak hours, the bandwidth can be reserved for regular business activities.
In the example above, the ProxySG is pre-populating is cache from an HTTP server and a
streaming media server. If the administrator decides to populate the cache from the HTTP server,
the time it takes to populate the ProxySG cache is equivalent to the time it would take to
download the file from the OCS. However, if the administrator is populating the ProxySG by
streaming the video from a media server, the population time is the same as it would be to watch
the video.
By taking advantage of pre-population, administrators can reduce the amount of overall
bandwidth usage. Clients no longer need to connect to the OCS to retrieve videos that are already
on the ProxySG.
255
Authentication
6OLGH$XWKHQWLFDWLRQ
As is true with many other types of secure data, it is often desirable to require authentication for
protection purposes. Often, streaming media content requires authentication because it is only to
be used by certain individuals.
The ProxySG can use its ability to cache streaming media content in conjunction with
authentication. As previously stated, the ProxySG can cache streaming media content. However,
some of this data that is being cached might have required authentication when a request was sent
to the OCS. In order to maintain that security, the ProxySG is able to require authentication for
cached streaming media content.
When a client attempts to access secure streaming media content that has been cached on the
ProxySG, the client is prompted with a request to authenticate. For example, in the slide above, the
client has requested access to streaming media content that has been cached on the ProxySG.
However, the streaming media content on that media server is authenticated. Therefore, in order
to maintain security for that data, even after it has been cached, the client is asked to authenticate
before the streaming media content can be accessed. Authentication rules can be applied to fully
cached content and partially cached content.
256
Property
Streaming Handoff
6OLGH6WUHDPLQJKDQGRII
Streaming handoff is a process that allows the ProxySG to appropriately process MMS traffic, no
matter what protocol is used to deliver the content.
For example, in the slide above, streaming media traffic comes over port 1755, the native MMS
protocol; therefore, no handoff is required. However, in common deployments, port 80 is the only
port that allows traffic through the firewall. The HTTP worker does not know how to handle the
MMS data; it is unable to do any splitting or object caching. In order for appropriate caching,
splitting, and application of policy, protocol handoff is triggered, and the HTTP worker gives the
MMS data to the MMS worker. Note that the MMS data being sent over SOCKS is also able to
participate in streaming handoff; this action is not limited to traffic sent with the HTTP protocol.
257
258
Property
Chapter 22: ProxyClient Concepts
Blue Coat ProxyClient is a Windows service capable of accelerating application traffic over the
WAN by connecting to ProxySG appliances concentrators close to servers in various enterprise
locations. ProxyClient is designed for mobile users or a small remote offices with few employees,
where the cost of a ProxySG might not be justified. ProxyClient also can perform content filtering
of incoming Web traffic.
ProxyClient provides acceleration by using byte caching, Web and CIFS object caching, CIFS
protocol optimization, and compression. ProxyClient can be provisioned and configured from a
ProxySG called the Client Manager.
Features and benefits of ProxyClient include:
Connect from anywhere: ProxyClient enables any user to remotely connect to an Application
Delivery Network from anywhere.
Centralized management and distribution: Administrators use a specified ProxySG

designated as the ProxyClient Manager to download updated ProxyClient software and
configuration updates for users.
Location awareness: This is the ability of ProxyClient to enable or disable acceleration and
Web filtering as configured on a ProxySG serving as the client manager. Decisions are made
depending on the network connections: IP address ranges and DNS servers. For example,
ProxyClient should disable both acceleration and Web filtering when in an office behind a
ProxySG, but enables them for mobile or home users.
ADN acceleration: Use of compression for TCP applications. Acceleration of CIFS by client
object caching, protocol optimization and consolidating many small blocks of native CIFS.
Byte caching data compression used in ADN tunnels that uses tokens to represent data.
Byte caching replaces repeating patterns with dictionary tokens.
Web filtering: This allows ProxyClient to allow or block Web sites based on categorization of
URLs as well as categories defined by administrators. Similar to Blue Coat K9, Web filtering
in ProxyClient uses dynamic categorization to filter Web content. The Web filter also can log
all Web traffic or just the exceptions.
Encrypted caching: Byte caches and object caches might contain information that needs to be
secure. The encrypted caching feature in ProxyClient protects the contents of the byte cache
and the object cache from disclosure. Microsofts Encrypted File System is used for
user-generated file encryption.
ProxyClient statistics: Provides users with statistics on real-time traffic acceleration.
The benefits of ProxyClient.
How to set up ProxyClient software.
The role of ProxyClient Managers.
The concept of location awareness for acceleration and filtering.
ProxyClient architecture and directory layout.
How to use the ProxyClient browser window.
259
Overview
LAN-like experience for remote users
ProxyClient is client software
W indows XP/Vista
Freeware, but setup and operation requires ProxySG
Functions
Secure against malware, unsafe URLs
Accelerate networking
Centrally provisioned, updated, monitored
6OLGH2YHUYLHZ
Mobile workers access their enterprise network from home, from airports and cafes, and from
their client enterprise networks. All of these environments require consistent connectivity,
security, availability, and performance. ProxySG technology can provide these features, but
ProxySG appliances are not deployed everywhere. The solution is to install ProxyClient software
on a user computer that connects to an enterprise ADN.
Remote users can be protected from external intrusions by personal firewalls or packet filters. In
contrast, ProxyClient can ensure remote filtering on an application level to enforce enterprise
Internet usage policy, prevent the spread of malware infection, and protect against Web-based
attacks.
ProxyClient software is free, but it would be useless as a stand-alone service. In order to configure
and manage it, an administrator must first configure a ProxySG to serve as a Client Manager.
Operation of ProxyClient requires pushing configuration and software updates from the Client
Manager. Once it is configured, ProxyClient interacts with ProxySG appliances (concentrators for
certain servers) to achieve the best acceleration performance.
To filter content, ProxyClient uses WebPulse, the same online content filtering infrastructure
used by ProxySG appliances. WebPulse includes cloud services that offload URL rating and
categorization tasks, perform malware detection, perform content and reputation analysis,
employ human raters, and accumulate user feedback.
260
Property
ProxyClient Scenarios
6OLGH3UR[\&OLHQWVFHQDULRV
ProxyClient combines acceleration and filtering and is very effective in many cases, particularly in
places where clients are not behind a ProxySG or in cases where network applications in remote
branches pose delay, control, and security problems.
Two important scenarios for ProxyClient deployments are:
Mobile users: A single user with an enterprise-issued laptop, accessing internal enterprise
resources over a public network using a VPN.
Micro-branch: A small remote office with five or fewer users, where the cost of a ProxySG
cannot be justified.
ProxyClient provides noticeable acceleration in both of these cases by overcoming latency and
bandwidth restrictions. ProxyClient offers reliable performance when accessing the enterprises
Web-based resources (such as applications and file shares) from outside the office, and improved
security that protects mobile users and the enterprise from Web-borne threats.
CIFS and HTTP allow both object caching and byte caching, so accelerating them is efficient. For
other protocols, ADN is implemented as byte cache by TCP port numbers. Unlike the ProxySG,
ProxyClient does not understand MAPI compression, so the acceleration of e-mail traffic between
Microsoft Exchange and Outlook is limited to uncompressed traffic (as is the case with the
Microsoft Exchange 2000 server or Microsoft Outlook 2000). Such traffic can benefit from generic
ADN acceleration features byte caching and compression that are supported by the
ProxyClient.
261
Compatibility and Requirements
6OLGH9HUVLRQFRPSDWLELOLW\DQGUHTXLUHPHQWV
ProxyClient version 3.2 requires a Windows workstation and at least one ProxySG. To accelerate
traffic, ProxyClient interacts with ProxySG appliances that can have one or more of these roles:
It receives its configuration from a ProxySG called the Client Manager.
It receives routing data from an ADN Manager, configured by the Client Manager.
Finally, it connects to a ProxySG that is called the concentrator and is located in a data center.
ProxyClient version 3.2 is designed to work with ProxySG appliances running SGOS version
5.3.2.5 or later. Otherwise, some of the features described in this chapter will not work.
ProxyClient software has the following specifications:
Operating system: Windows XP (Home, Media Center, Professional including service packs
1-3) or Windows Vista (all Vista versions are supported including SP1, except Starter Edition).
Hard drive: 5MB available for ProxyClient software installation, up to 40MB for logging, and
an additional 1.5GB available (minimum) for CIFS object caching, 5GB or more available
recommended. The CIFS object cache is stored on the system root volume. If 1GB or less is
available, the client does not cache CIFS objects such as directory listings and file contents.
Processor: A minimum 500MHz processor, such as the Intel Pentium/Celeron family, AMD
K6/Athlon/Duron family, or compatible processor. A 750MHz or faster processor is
recommended.
The recommended method to install ProxyClient depends on two criteria:
Is Client Manager visible from the local computer? If it is, use interactive installation (EXE
file); it will download everything else. Otherwise, use silent installation (MSI file) and supply
the necessary parameters. (This course covers interactive installation.)
Do multiple instances of ProxyClient need to be installed? If not, distribute the software

manually (download or copy the necessary files and parameters); otherwise, use Group Policy
Object distribution.
262
Property
ProxyClient Installations
6OLGH3UR[\&OLHQWVHWXS
ProxyClient software is deployed in these steps:

1.
To upgrade to a new ProxyClient version, the administrator can upload ProxyClient software
(SGClient.car) to the ProxyClient Manager from a remote URL or from a location on the local
file system. To perform upload, go to Configuration > ProxyClient > General > Client Software.
2.
Set up an ADN manager and backup manager, and configure the ADN.
3.
Configure a ProxySG as the ProxyClient Manager for client installation. The ProxyClient
Manager must be licensed.
4.
Configure ProxyClient settings, such as CIFS and ADN settings.
5.
The user can get a copy of the ProxyClient software either from the ProxyClient Manager or
pre-installed by an administrator. The user can download the ProxyClient software from the
ProxyClient Manager via a URL provided by the administrator; see links at Configuration >
ProxyClient > General > Client Manager.
6.
When a user connects to the ProxyClient Manager using the given URL, the user runs a setup
application (ProxyClientSetup.exe) that in turn downloads and starts a Microsoft installer
(ProxyClientSetup.msi). Do not try to run the MSI file directly; it needs configuration from
XML.
7.
After installing ProxyClient software, the user must reboot the workstation.
Periodically, ProxyClient polls the ProxyClient Manager for changes to ProxyClient software and
configuration. ProxyClient upgrades can happen silently when the clients computer is restarted.
263
Sizing Notes for SGOS 5.5

Model
Max WAN
Bandwidth
(Mbps)*
Active
ADN
Clients*
Active
Clients
for Client
Model
Manager*
Max WAN
Bandwidth
Active
ADN
(Mbps)*
Clients*
Active
Clients
for Client
Manager*
210-5
0.5
10
450
810-5
12
500
1,350
210-10
50
900
810-10
30
700
4,500
210-25
50
900
810-20
45
1,000
4,500
510-5
50
900
810-25
45
1,000
4,500
510-10
12
125
1,800
8100-5
30
1,000
2,500
510-20
12
300
1,800
8100-10
60
1,500
10,000
510-25
12
300
1,800
8100-20
100
1,650
10,000
Estim ated figures; subject to change without notice

6OLGH3HUIRUPDQFHFRQVLGHUDWLRQV
This table shows the recommended maximum WAN bandwidth for the ProxySG, recommended
maximum active ProxyClients for WAN optimization, and recommended maximum active
ProxyClient instances connecting to a client manager. These estimates assume that the ProxySG is
dedicated as either as an ADN concentrator for WAN optimization or as a client manager, but not
both.
Scalability and throughput are two of the most important factors of ProxySG performance. While
throughput is typically CPU-bound, ProxySG scalability is memory-bound and CPU-bound. From
a memory perspective, the two numbers that provide the foundation of a scalability calculation
are:
The memory consumption for each TCP connection.
The average memory consumption for data reduction over each TCP connection.
To achieve data reduction, ProxyClient uses native TCP connection and industry-standard and
Blue Coat proprietary compression algorithms. Also, the ProxySG uses SSL connection and byte
caching combined with data compression as data reduction techniques.
Combining all of the related memory consumption numbers produces a good estimate of the
overall scalability of the ProxySG, as shown in the above table.
264
Property
Client Managers
6OLGH&OLHQW0DQDJHUV
ProxyClient Manager provides a location to download the software for local installation. The
ProxyClient Manager also provides software updates and client configuration to all connected
ProxyClients. ProxyClient automatically checks for software and/or configuration updates at an
interval set by the administrator. However, users can check for updates anytime they want they
can open the ProxyClient console, and click Check for Updates Now in the Advanced tab.
When a new ProxyClient software update is made available on the network, users are informed
through a message on their screen, advising them that an update is available for download. After
a successful download, a user is prompted to restart the computer for the new ProxyClient version
to take effect. The user can choose to restart the computer immediately or later.
Note:
Neither client machines nor ProxySG appliances serving as Client Manager need any
specific licence to use the ProxyClient software. Customers with a Blue Touch
Online account can download the newest ProxyClient software file (Windows32.car)
from http://bto.bluecoat.com, or they can use the version of ProxyClient that is
included in their SGOS release.
If the Client Manager goes down, ProxyClient continues to use existing configuration for
acceleration and filtering, but it cannot upgrade and upload its statistics. To instruct an existing
Client Manager to permanently pass the control of its clients to another Client Manager, go to
Configuration > ProxyClient > General > Client Manager, select Use Host, and enter the new Client
Managers IP address.
In version 3.2 and later, the ProxyClient software is tamper-resistant. The configuration files in its
installation directory are binary and not readable. In particular, this means that ProxyClient
cannot locally configure itself a new manager only its manager can. Client Manager can
configure a password that will be required to uninstall ProxyClient software from the workstation.
265
Figure 22-1: Client Manager displaying details about its ProxyClients
Under Statistics > ProxyClient > Details > Client Details, each ProxySG serving as a Client Manager
can view information about its ProxyClient instances. Accordingly to the sizing notes, a single
ProxySG can manage up to 10,000 ProxyClients.
It is possible to get reports with filtered and sorted lists of the ProxyClients, what functionality
(acceleration, filtering, or both) is enabled, which versions they are running, and so on. Such
reports are available for display and download. To see them the Client Manager, must be running
version 5.4 or later of SGOS.
266
Property
Location Awareness
6OLGH/RFDWLRQDZDUHQHVV
Depending on the connection environment, location awareness enables or disables ProxyClient

acceleration or Web filtering features. You can configure the services to be enabled or disabled in
the Management Console. A good rule of thumb is to enable a feature for ProxyClient only if it is
not provided by a configured ProxySG. If it is already provided by a ProxySG, then disable it for
ProxyClient.
In the Management Console, locations can be defined by going to Configuration > ProxyClient >
General > Locations and clicking New. Each location condition contains either a source IP address
(or address range), DNS address, virtual NIC address or address range, or any combination of
these. Moreover, for each location, the administrator can choose to enable or disable acceleration
and filtering. There are four ways to enable or disable these features:
1.
A home office or mobile user that uses VPN to connect to the network. Location condition is
Virtual NICs address range. Source IP can be anything, so it should not be a condition; DNS
address is typically not useful because the Internet provider can change it.
2.
Enterprise headquarters. Location condition is source IP range. If the ProxySG at the

headquarters has acceleration and filtering enabled, then disable both features in ProxyClient.
3.
Branch office with no local ProxySG. ProxyClient can be used to accelerate and filter traffic in
a branch office with no local ProxySG. If there is an IP address conflict in terms of the micro
branchs IP address and the headquarters IP address range, use the DNS address for resolving
it.
4.
Branch office with a local ProxySG. If the ProxySG is configured to do only acceleration, then
configure filtering in ProxyClient.
267
ProxyClient Browser Window
6OLGH3UR[\&OLHQWEURZVHUZLQGRZ
By clicking the ProxyClient icon in the system tray, a user can open its Web console, called the
ProxyClient Browser Window. It has three tabs:
Status: A dashboard displaying general acceleration and content filtering statistics.
Network: ADN related information, such as ADN manager, routes, and exceptions.
Advanced: Diagnostic tools, such as verbose logging and tracing, forcing configuration
updates from Client Manager, and caching information.
On Windows XP, the ProxyClient support folder is on the system drive at Documents and
Settings\All Users\Application Data\Blue Coat Systems\proxyclient\support. ProxyClient also
maintains run-time logs and debug traces in the same folder. The log file compiles and displays
the clients daily activities and events, such as software updates and proxy connection status. It is
a very useful diagnostic tool to track and trace the triggers and errors generated by the client
software.
Additionally, if the service crashes for any reason, a memory dump file is generated. If at any
point a downgrade is performed through the auto-update mechanism, an additional downgrade
log is created. On the users computer, the log can be accessed from the ProxyClient Web interface,
under the Advanced tab. In the Diagnostic Tools section, click View Log.
268
Property
Chapter 23: ProxyClient Filtering
Blue Coat ProxyClient has two main aspects: filtering and acceleration. With content filtering,
ProxyClient can maintain user productivity levels and ensure that enterprise Web usage policies
are maintained on enterprise-owned systems in the field. Only users with administrator privileges
can remove or disable ProxyClient. This chapter covers ProxyClient configuration specifically for
Web content filtering, and related maintenance tasks.
Web content filtering is required by many enterprises for security and compliance. Network
managers want users to be protected from Web sites with malicious content. Filtering also can
prevent accessing offensive content or losing productivity due to too much Web surfing.
Blue Coats Web filtering solution answers these concerns both in the office and on the road. For
an office solution, ProxySG with a local content-filtering database (plus access to the WebPulse
service points) is the best option. For off-site users, ProxyClient remotely configured by its Client
Manager (and using only WebPulse services) ensures filtering by categories, but the policy
conditions cannot be too granular. The Web filtering log, which is encrypted on the users
computer, can be uploaded periodically to an FTP server for analysis.
How to enable ProxyClient content filtering.
How to create category-based policies.
Content filtering architecture and workflow.
ProxyClient access logs and reporting.
How to diagnose and prevent causes of content filter malfunctions.
269
Content Filtering with ProxyClient

Filter anywhere without proxy interception
Use ProxyClient for acceleration and filtering
Access WebPulse service points for categorization
Centralized management
Filtering is enabled depending on location
Centralized software updates, configuration, and reporting
Blue Coat Systems, Inc. 2010. All Rights Reser ved.
6OLGH&RQWHQWILOWHULQJZLWK3UR[\&OLHQW
Content filtering capabilities of ProxyClient are similar to those of Blue Coat K9 a standalone
filtering application that is intended for home use. ProxyClient and K9 both rely on the same
categorization data to implement filtering policy the WebPulse services. The difference from K9
is that ProxyClient is tightly integrated with the ProxySG:
Content filtering is one functional module available in ProxyClient. It can be enabled or

disabled independently from its other function acceleration.
ProxyClient relies on a Client Manager (a ProxySG serving one or more ProxyClient instances)
to do software distribution and filter configuration.
Client Manager should have a Blue Coat WebFilter license, but it does not participate in
categorization. Instead, ProxyClient communicates directly with WebPulse service points.
Access logs are stored on the local computer and are directly uploaded to an FTP server
configurable on the Client Manager. The log files are never physically transferred to the Client
Manager.
To achieve the best possible performance, reliability, and flexibility, content filtering relies on data
located in three places:
The users computer contains a temporary cache of previous categorization results in an

encrypted format.
Filtering policy and other settings are located on the Client Manager.
New URL categorizations are requested from WebPulse service points, including a master
categorization database and dynamic categorization.
270
Property
ProxyClient Filtering vs. Filtering by ProxySG Policy

ProxyClient filtering policy is defined under Configuration > ProxyClient > Filtering rather than
Configuration > Policy. The latter defines the policy for Web requests intercepted by the ProxySG.
ProxyClient filtering can be based only on general or custom-defined content categories; there are
no policy actions depending on properties such as page content, HTTP headers, or TCP ports.
Instead of various actions and exceptions available on the ProxySG, ProxyClient allows only three
different policy actions (allow, warn, and block). Warning is similar to the effect produced by a
custom ProxySG exception or a coaching page it displays a custom message but offers a link to
access the requested page.
Another major difference between ProxyClient Web filtering and ProxySG Web filtering is that
categorization for ProxyClient is never performed by consulting the Client Managers filtering
database. To use ProxyClient Web filtering, you must enable the WebFilter database on the Client
Manager. ProxyClient will always try to contact service points and dynamic categorization
regardless of how dynamic categorization is configured on the Client Manager.
271
Defining Filtering Policy
6OLGH'HILQLQJILOWHULQJSROLF\
To determine whether content filtering on ProxyClient will be enabled, these questions need to be
answered:
1.
Is ProxyClient content filtering enabled by location? Either it is enabled for the default
location (Enable Web Filter is selected under Configuration > ProxyClient > General > Locations),
or the machine by its IP address, Virtual NIC IP address, or DNS happens to be in one of the
custom locations where content filtering is enabled.
2.
Is ProxyClient behind an inline ProxySG with Web filtering auto-detection enabled? The
ProxySG might contain a policy that for any ProxyClient behind it will switch off the
ProxyClient Web filtering (and replace it by ProxySG policy). This happens regardless of
ProxyClient machine location. The policy on the ProxySG looks like this:
<Proxy>
request.header.Host="sp.cwfservice.net" action.i_am_filtering(yes)
define action i_am_filtering
set(response.x_header.X-BCWF-License,"BCWF-USERNAME")
end
3.
Does the ProxyClients Client Manager have Blue Coat WebFilter installed and licensed?
ProxyClient does not use this WebFilter for categorization purposes, but it needs the license in
order to access the WebPulse service. If it is not licensed, then the ProxyClients filtering
behavior is either allow all or deny all.
If all the above reasons imply that ProxyClient Web filtering is enabled, then the filtering policy is
applied. This is an ordered list of rules in which the policy action for any given category can be
either allow, warn, or block.
The first matching filtering rule is applied, so the order of the filtering rules is essential. A best
practice of writing filtering rules is to proceed from the more specific to less specific rules. For
example, put the whitelist from the local database as the first rule to guarantee that these are
always allowed, regardless of WebFilter categorization.
272
Property
A sample order of the rules is:

1.
Whitelist overrides (local database and policy categories you always want to allow).
2.
Blacklist overrides (local database and policy categories you always want to block).
3.
All other categories with policy action set to block.
4.
All other categories with policy action set to warn.
5.
All other categories with policy action set to allow.
The WebFilter database on Client Manager should be present purely for licensing purposes. This
license is necessary even when you only want to allow or restrict categories from your local
database. In all such situations, you can still benefit from the availability of WebFilter categories,
such as by creating more informative reports on ProxyClient-generated access logs.
Source-based Web filtering is supported in ProxyClient version 3.2 and later. ProxyClient Web
filtering can be enforced for users of domain groups. In other words, you can allow, block, or warn
on content according to the specific user or to the domain group to which the user belongs. Each
category has a default behavior, but it can be overridden for particular Active Directory user
groups.
ProxyClient Web Filtering will not function properly if ProxyClient is behind a proxy that does
authentication for realms other than IWA.
273
Content Filtering Workflow
6OLGH&RQWHQWILOWHULQJZRUNIORZ
Three key steps are involved in serving a request:

1.
Categorize the URL. This involves assigning category or categories to the requested URL. This
requires a lookup to local cache and, possibly, a WebPulse service. The result of categorization
is either one category or, generally, an unordered list of categories. The resulting list of
categories can include any of the following:
Blue Coat categories: used by WebFilter and WebPulse. There are more than 60 categories.
Two special categories: System/none, if no category was assigned by WebPulse, and

System/unavailable, if WebPulse services are unavailable. Both categories mean that no
Blue Coat category is assigned.
Local database categories: URL lists defined at the enterprise level.
Policy categories: Defined by the ProxySG at appliance level.
2.
Temporarily cache the categorization result on the users computer.
3.
Determine the policy action: Go through the list of rules in Client Manager configuration, and
pick the first matching action allow, warn, or block.
Additional policy configuration options are available under Configuration > ProxyClient > Web
Filtering > Policy:
On License Expiration. Possible values are fail open or fail closed. This specifies the behavior of
the ProxyClient Web filter if the WebFilter license on its Client Manager expires.
Enforce Safe Search. Most search engines have additional parameters to indicate whether the
search results should include adult content. Use this option to enforce safe search anyway,
regardless of a users settings.
274
Property
Enable HTTPS Filtering. This feature uses a man-in-the-middle approach and overrides the SSL
certificate issued by the original content site with another one issued by a ProxySG acting as a
client manager. Select this to use Web filtering when the content request is sent over an SSL
connection using default port 443. Deselect this to not filter HTTPS traffic if certain browsers
are used.
The following Web browsers are completely compatible with ProxyClient Web filtering, including
HTTPS filtering:
Microsoft Internet Explorer version 6 and later, including version 7.
Mozilla Firefox version 2 and later, including version 3.
Hotspots and Welcome Pages

Mobile users with ProxyClient installed on their laptops need to connect from WiFi hotspots and
from wired or wireless services available in locations such as hotels. Such services often send
welcome pages to request authentication, display terms of service, and so on before connecting the
user to the Internet. ProxyClient allows the user to complete the enrollment process without
filtering. When the authentication is completed and access to the Internet is granted by the access
point, ProxyClient will allow one GET request for a Web site, even if the sites category has a
policy action of block or warn. After that, all requests will be filtered normally.
ProxyClient might cause issues in some guest networks. In these cases, the user should contact the
administrator, who should contact Blue Coat support. As a quick fix, the Client Manager ProxySG
might try to allow System/unavailable, although this should not be necessary under normal
conditions.
Exception Page Templates

Exception pages typically contain links to enterprise policy explaining which categories are
blocked and why. If users receive exception pages without explicit and useful information, they
might think that blocked pages are a result of a network malfunction or a misconfigured
software.These templates might also encourage feedback from users, especially if legitimate
content is blocked by a filter.
Client Manager can customize three exception page templates: block page, warn page, and
unavailable page. Configure these from Configuration > ProxyClient > Web Filtering > Exceptions.
These are extremely useful to provide feedback to the user about why some resource was
unavailable. The templates use variables url (the blocked URL), cs-categories (all categories for
that URL), and cs-categories-exception (the offending category). The template for a warning page
also can use a variable override-url (the URL to click to access the page anyway).
275
Logging
6OLGH/RJJLQJ
Analyzing user Web browsing activity lets you better customize your content-filtering policies
and verify that your users are abiding by enterprise policies. You can configure ProxyClient to
upload user Web browsing activity logs to an anonymous FTP server at regular intervals or when
the local log file reaches a specified size. Connections occur only when the client system has access
to the specified FTP server, which is typically when the user connects to the enterprise network.
Note:
Because log files are uploaded using anonymous FTP, Blue Coat strongly
recommends you put your FTP server behind the enterprise firewall. In addition, you
should configure the FTP server to disable scans and file overwrites. Placing an FTP
server outside the firewall has the advantage that even mobile users can upload log
files to it; however, it exposes the server and your enterprise to potentially serious
malicious activity.
Logging is enabled by selecting a checkbox in Configuration > ProxyClient > Web Filtering > Log.
Table 23-1: Fields in the filtering log
Field
Description
date
Date in Universal Time Code (UTC) format
time
Time stamp in UTC format
c-ip
Clients IP address
c-username
Clients login user name
x-cs-auth-domain
Clients domain name (if available)
c-computername
Clients computer name

One of the following:
- if the content is allowed.
content_filter_warned if the policy action is warn.
x-exception-id
content_filter_denied if the policy action is block.
276
Property
Table 23-1: Fields in the filtering log

Field
Description
cs-categories
Semicolon-delimited categories for the content request.
cs-categories-exception
The first category match; in other words, the category on

which the policy action shown by x-exception-id is
based.
cs-referer
Referring URL, if any.
cs-method
The method used in the content request (for example,

GET).
cs-uri-scheme
The URIs schema (http or https).
cs-host
The host portion of the URI.
cs-uri-port
The port used to access the URI.
cs-uri-path
The path relative to cs-host. If cs-uri-scheme is

https, this field is blank.
cs-uri-query
Query string, if any. If cs-uri-scheme is https, this

field is blank.
cs-uri-extension
File extension of the object.
cs-user-agent
Information about the Web browser that requested the

object.
s-ip
Web servers public IP address.
277
Troubleshooting
If ProxyClient denies access to legitimate sites
Inspect logs to find category
Policies for System categories none, unavailable
Renew WebFilter regularly or use fail-open
Reboot after ProxyClient configuration update
Dispute categorization
http://sitereview.bluecoat.com/sitereview.jsp
6OLGH7URXEOHVKRRWLQJ
Why are users receiving blocked or warning messages for no apparent reason? The most common
message you are likely to receive from users is that ProxyClient is denying them access to a Web
site that they feel does not violate the Acceptable Usage Policy of their enterprise. The first step is
to understand why the page is blocked or warned:
The rating server returned a category that resulted in a block action. The exception page,
admin log, and Most Recent Events list display the category that caused the block action.
The rating server did not return a category, and the none system category is configured with a
block action.
None of the WebFilter service points (rating servers) are available, and the unavailable system
category is associated with a block action.
License expiration is fail-closed, and the Client Manager is not licensed for ProxyClient Web
Filtering or does not have a fresh WebFilter database. ProxyClient displays Not licensed as the
Web filtering status on the Status tab. The tray icon mouse over text also displays this state.
The service is not running or is not responding, and the unavailable system category is
configured with a block action. In this case, the tray icon displays a red X as the status, states
that the service is not running, and the user interface and admin log are not available.
If a configuration update has been received by the client, the update includes a blocked
category, and the user has not rebooted the computer. Because ProxyClient stops running
when a reboot is necessary, the Web filtering driver blocks requests if a new category is set to
block. Normal Web filtering resumes after the user reboots the computer.
Some images on requested pages do not display. This is most likely caused by subsequent
requests on an allowed Web page falling into a blocked category. (For example, a section or
portlet on an allowed Web page might contact a prohibited site for an advertisement.)
Advise your users that this is expected behavior. Various actions to remedy unjustified block (and
warn) actions are available, depending on the reason for the block action:
278
Property
Add a URL to a custom category that is associated with an allow action (that is, create a
whitelist). Move this category above the category that is causing the block action. This causes
the allow action to be processed first. You also have the option to disagree with the rating
decision made by WebFilter and submit a request for categorization change.
Consider modifying the rule base, allowing the blocked category, allowing none or unavailable
categories, or changing the unlicensed behavior to fail open. This option is valid if you are
authorized to change the corporate compliant browsing policy.
Fix the license violation.
Restart ProxyClient to fix nonresponsive services.
ProxyClient Web Filtering Licensing

If your users notify you that the application displays the Filtering Unlicensed message, the
WebFilter license is no longer valid or the URL database has not been refreshed in the past 30 days.
On the Configuration > Content Filtering > Blue Coat > Blue Coat Web Filter tab, verify that you have
a valid license and click Download now to update the database.
Disputing URL Categorization For ProxyClient

If users report that they are blocked from accessing a normally allowable Web site, first make sure
that the problem is not caused by improper ordering of categories in the Web filter rule base. This
is particularly true if a single URL is listed in multiple categories.
If WebFilter is blocking access to the Web site and you disagree with the URLs categorization, you
can submit a Web site for review, stating ProxyClient as the Web filter source. The Web site is
http://sitereview.bluecoat.com/sitereview.jsp.
279
280
Property
Chapter 24: Introduction to ProxyAV
Anti-virus scanning is the process of examining content for files infected with an Internet-based
threat (virus, worm, Trojan, or spyware). These viruses can be brought into an enterprise through
Web-based e-mail programs or other Web-enabled applications. Until recently, Web virus scanning
solutions were too slow to be practical. In traditional e-mail anti-virus (AV) programs, users do not
know they have a message until after it is scanned. However, Web AV must be high-performance
because users are aware of and want to access content before scanning starts. For instance, users
want to click on links in an e-mail message or in a Web page both of which require separate
scanning.
The Blue Coat ProxySG and Blue Coat ProxyAV provide the performance needed for todays
Web environments. The virus-checking capabilities are implemented through an off-box solution
that uses the Internet Content Adaptation Protocol (ICAP) as the communication mechanism
between the ProxySG and the ProxyAV. The policy definition for content scanning is fully
integrated into the policy framework and is defined using the either the Management Console or
Content Policy Language.
Plain ICAP is performed over an unencrypted data channel. This might not be acceptable for users
who perform scanning of confidential data; the data is decrypted on the ProxySG and sent
unencrypted to the ProxyAV. To address this, ICAP can run over a Secure Sockets Layer (SSL)
connection in a configuration known as secure ICAP.
A Blue Coat ICAP configuration allows administrators to select the virus-scanning servers that are
to be used by the ProxySG. The ProxySG ICAP implementation is fully compatible with the
ProxyAV, Finjan SurfinGate, Symantec AntiVirus Scan Engine (SAVSE) Server, Trend Micro
InterScan Web Security Suite (IWSS), and Webwasher.
281
ProxyAV
Powerful defense against
Viruses and worms
Spyware and Trojans
Protects often-overlooked backdoors

Personal Web e-mail accounts
W eb content or e-mail spam with Trojan or spyware
Browser-based file downloads that bypass existing virus-
scanning defenses
6OLGH3UR[\$9SURWHFWLRQ
Traditional anti-virus Web gateways often lack scalability and performance for HTTP and FTP
scanning, leaving desktops to defend themselves. The ProxyAV, combined with the ProxySG,
provides scalability for virus scanning, as well as complete visibility and control of enterprise Web
communications.
The ProxyAV enables organizations to scan for viruses, worms, spyware, and Trojans entering
through Web-based backdoors, including:
Personal Web e-mail accounts, where a majority of viruses and worms propagate.
Web spam or e-mail spam, which can activate Trojan downloads or hidden spyware.
Browser-based file downloads that bypass existing virus-scanning defenses.
The ProxyAV scans traffic sent via the FTP and HTTP protocols. It does not scan traffic sent via
instant-messaging protocols.
282
Property
ProxyAV Deployment
6OLGH3UR[\$9GHSOR\PHQW
The ProxySG provides flexible and granular control of Web traffic and access, and the ProxyAV
provides high-performance AV scanning of both cached and non-cached content. The ProxySG
and the ProxyAV share underlying Blue Coat processes, which allows for easy deployment and
integration. After the integration, this solution allows for the scanning and purging of harmful
viruses and other malicious code without compromising the network control, bandwidth gains, or
security attained from the proxy.
A typical deployment scenario of the ProxyAV is as follows:
1.
A client makes a request to the ProxySG (known as the ICAP client) for an object on an origin
server.
2.
The ProxySG sends the request to the origin content server.
3.
The OCS returns the object to the ProxySG, which sends the response to the ProxyAV.
4.
The ProxyAV executes the ICAP resources service on the response and either removes a virus
and sends the modified object back to the ProxySG, or tells the ProxySG that the object was
not modified because no virus was found.
5.
The ProxySG sends the response to the client.
The ProxySG caches the safe object. Any additional requests for the same content are handled by
the ProxySG without a rescan of the content thus avoiding additional load on the ProxyAV. If
the object requested is infected, the ProxySG does not cache it, the file is rejected, and the client
does not receive the requested file.
283
Connecting To ProxyAV
6OLGH&RQQHFWLQJWRWKH3UR[\$9
The first step in the initial setup of a ProxyAV is to assign a suitable IP address. You must assign a
static IP address to at least one of the interfaces on the proxy. There are two main methods to do so:
Serial cable: The ProxyAV can be configured using a serial console support similar to the
ProxySG functionality. By connecting the ProxyAV to a terminal or a PC running terminal
emulation software, an administrator can perform configuration tasks without relying on a
network connection.
Front LCD panel: You also can use the front LCD panel to perform first-time configuration of
the following networking parameters:
IP address
Subnet mask
Setup password
Gateway address
DNS address
Secure serial console
Console password
Enable password
Once the initial configuration is completed, you can access the ProxyAV using a Web browser. The
ProxyAV supports Microsoft Internet Explorer versions 6.x and 7.x, Netscape Communicator
version 6.x, and Firefox version 1.x or 2.x. Verify that your Web browser is not configured to use a
proxy. To access the ProxyAV Management Console, enter the IP address that you specified
through the serial console or the front LCD panel, followed by the default port number:
https://proxyIPaddr:8082.
284
Property
Licensing ProxyAV
6OLGH/LFHQVLQJ3UR[\$9
When you first connect to the ProxyAV Management Console after installation, the ProxyAV
Automatic Registration page displays. To activate your license for the ProxyAV, perform the
following steps:
1.
2.
If the registration page is not displayed, select Licensing and click Register.
Enter your BlueTouch Online user ID and password into the fields labeled WebPower
credentials.
3.
Enter the activation code you received via e-mail from Blue Coat when your purchased the
ProxyAV. You might need to identify the person in your enterprise who received this e-mail.
4.
Click Register ProxyAV. The ProxyAV connects to the Blue Coat Licensing Portal and
completes the process. You might need to accept the terms of a licensing agreement during
this process.
285
Sample Deployment
6OLGH6DPSOHGHSOR\PHQW
Before connecting your ProxyAV, determine the proper location on your network. The ProxyAV
must be on the same network segment as the ProxySG. Once the ProxySG is configured as an
ICAP client to the ProxyAV, data is sent to the ProxyAV for content scanning. The ProxySG cannot
act as an ICAP server for ICAP clients outside the local network.
If the ProxyAV is physically connected to a Cisco router, a cross-over cable must be used.
The ProxyAV network segment must be configured for the following protocols:
Incoming ICAP.
Incoming HTTPS (for remote configuration and diagnostic and statistic information).
Incoming/outgoing SNMP (monitoring).
Outgoing HTTP and HTTPS (firmware, pattern, and engine updating; licensing, registration,
and serviceability).
Outgoing DNS (only required to resolve the default ProxyAV and firmware update sites).
286
Property
Enabling Malware Scanning
6OLGH(QDEOLQJPDOZDUHVFDQQLQJ
The Management Console provides a simple means for setting up the integration between the
ProxySG and one or more ProxyAV appliances on the network. This is a very quick approach for
enabling general-purpose malware scanning in your solution, but it might not be suitable for
specific and complex malware scanning policies. The procedure and technical considerations for
creating a customized malware scanning solution are described in the next chapter.
To enable the standard malware scanning mechanism:
1.
In the Management Console, go to Configuration > Threat Protection > Malware Scanning and
click Add. The Add ProxyAV ICAP Server window displays.
2.
Specify the IP address of the ProxyAV and its ICAP settings, and click OK. The next chapter
explains ICAP in more detail. You can add more than one ProxyAV. The virus scanning
requests are equally distributed among the entered ProxyAV appliances.
3.
Adjust the following general malware scanning settings:
Protection level: When set to Maximum security, the ProxyAV scans all Web responses;
when set to High performance, it selectively scans Web responses bypassing content that
has a low risk of malware infection.
Connection security: Specifies when the ProxySG chooses to use plain ICAP and secure
ICAP to communicate with the ProxyAV.
Action on unsuccessful scan: Determines what to do with client requested objects that
failed scanning. They can be either denied or served to the client unscanned.
4.
Select Enable malware scanning.
5.
To upload the configuration to the ProxySG, click Apply.
Upon clicking Apply, the ProxySG policy is recompiled to include a pre-written CPL policy that is
specifically designed by Blue Coat to work with the malware scanning configuration. From this
moment, the ProxySG starts sending requested Web objects to the specified ProxyAV appliances
for virus scanning.
287
288
Property
Chapter 25: ICAP Concepts
The Blue Coat ProxySG and Blue Coat ProxyAV provide the performance needed for todays
Web environments. The virus-checking capabilities are implemented through an off-box solution
that uses the Internet Content Adaptation Protocol (ICAP) as the communication mechanism
between the ProxySG and the ProxyAV. Policy definition for content scanning is fully integrated
into the policy framework and can be defined using either the Visual Policy Manager or Content
Policy Language.
As RFC 3507 states, ICAP is a protocol aimed at providing simple object-based content vectoring
for HTTP services. ICAP is, in essence, a lightweight protocol for executing a remote procedure
call on HTTP messages. ICAP is designed to offload specific Internet-based content including
HTTP, HTTPS, and FTP to dedicated servers for possible transformation or other processing
(hence the term adaptation).
For example, a server that handles only language translation is inherently more efficient than any
standard Web server performing many additional tasks. ICAP concentrates on leveraging
edge-based devices (proxies and caches) to help deliver value-added services. At the core of this
process is a cache that proxies all client transactions and processes them through ICAP/Web
servers. These ICAP servers are focused on a specific function for example, ad insertion, virus
scanning, content translation, language translation, or content filtering. Offloading value-added
services from Web servers to ICAP servers allows those same Web servers to be scaled according
to raw HTTP throughput as opposed to having to handle these extra tasks.
A Blue Coat ICAP configuration allows administrators to select the virus-scanning servers to be
used by the ProxySG. The ProxySG ICAP implementation is fully compatible with ProxyAV,
Finjan SurfinGate, Symantec AntiVirus Scan Engine (SAVSE) Server, Trend Micro InterScan
Web Security Suite (IWSS), and Webwasher.
How the ProxySG and ProxyAV work together to scan content.
Response modification and request modification, the two modes used in ICAP transactions.
How to use tools such as deferred scanning, data trickling, and patience pages to inform users
about delays in content delivery due to scanning and verification of data.
How scanning loads can be balanced among multiple ProxyAV appliances.
How secure ICAP differs from plain ICAP.
The steps involved in configuring the ProxySG and ProxyAV integration.
How to monitor ICAP connections on the ProxySG.
289
ICAP Fundamentals
6OLGH,&$3IXQGDPHQWDOV
ICAP offloads specific Internet-based content to dedicated servers that are optimized to perform
specialized tasks such as virus scanning. This frees resources on the proxy or firewall.
ICAP is a request/response protocol similar in semantics and usage to HTTP version 1.1. Despite
the similarity, ICAP is not HTTP, nor is it an application protocol that runs over HTTP. This means,
for example, that ICAP messages cannot be forwarded by HTTP surrogates.
The combination of the ICAP server and its application is known as an ICAP service. The ICAP
service is registered with the ICAP client, which in this case is the ProxySG. The ICAP client sends
client requests or responses to the ICAP server (the ProxyAV) for processing (virus scanning). The
ICAP server (ProxyAV) then returns the processed request or response to the ProxySG, or it
returns an error.
Five steps are involved in deploying ICAP with the ProxySG and the ProxyAV:
1.
Define and configure the ICAP option on the ProxySG. This includes deciding whether to use
plain ICAP (which uses TCP port 1344 by default but can be changed) or secure ICAP (ICAP
over SSL, which uses TCP port 11344 by default but can be changed).
2.
Define and configure ICAP settings for the ProxyAV.
3.
Configure and construct a policy with the desired virus scanning properties.
4.
Create an optional patience page.
5.
Test the configuration and new policy.
290
Property
ICAP RESPMOD
6OLGH5HVSRQVHPRGLILFDWLRQPRGH
Response modification mode (RESPMOD) is the most common ICAP transaction type. Content
obtained from the origin content server is sent by the ICAP client (ProxySG) to the ICAP server
(ProxyAV) for scanning. The ProxyAV can scan and return the modified content or return an error.
Content is usually modified if there is a virus in the object file.
At the beginning of the transaction, the ProxySG sends a preview of the object to the ProxyAV
with information including the headers and the first few bytes of the object. The ProxyAV checks
the information sent and either asks the ProxySG for more information or confirms that the object
is not infected. After the checks are done by the ProxyAV, the object is served to the client.
RESPMOD is intended for post-processing performed on a response before it is delivered to a
client.
The typical path for requests that are to be modified by the RESPMOD method is:
1.
A client sends a request to an origin content server.
2.
The request is fulfilled as would be expected by the OCS.
3.
The response, however, is redirected by the proxy server to the ICAP server.
4.
The ICAP server modifies the response and delivers it to the client via the proxy server.
The RESPMOD method enables scanning of HTTP responses, FTP RETR responses (remote
system file retrieval), and FTP over HTTP. Incoming Web mail and file downloads also are
scanned. The following example shows the RESPMOD message applied to an OCS response from
a GET request. The ICAP client sends a message like this:
RESPMOD icap://icap.example.org/satisf ICAP/1.0

Host: icap.example.org
Encapsulated: req-hdr=0, res-hdr=137, res-body=296
GET /origin-resource HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
291
ICAP REQMOD
6OLGH5HTXHVWPRGLILFDWLRQPRGH
Request modification mode (REQMOD) is used to send client requests to the ICAP server for
processing. The server responds in one of three ways:
It returns a modified version of the request. The ICAP client may then perform the modified
request by contacting an origin content server, or it may pipeline the modified request to
another ICAP server for further modification.
It returns an HTTP response to the request. This is used to provide information useful to the
user in case of an error (such as you sent a request to view a page you are not allowed to
see).
It returns an error.
ICAP clients have flexibility in handling errors. If the ICAP server returns an error, the ICAP client
might choose to return the error to the user, execute the unadapted request as it arrived from the
client, or retry the adaptation.
The typical path for requests that are to be modified by the REQMOD method is:
1.
The client sends a request to an OCS.
2.
This request is redirected to an ICAP server by the intervening proxy server (cache).
3.
The ICAP server modifies the message and sends it back to the proxy server.
4.
The proxy server parses the modified message and forwards it to the OCS to fulfill the clients
request. The request is then executed by the OCS, and the response is delivered to the client.
For example, consider REQMOD in terms of content filtering. Assume that the client sends a
request for a Web page and the proxy server redirects that request to the ICAP server. The ICAP
server parses the HTML request and performs URL-based filtering by comparing the request URL
to a list of banned URLs. If the URL is on the banned list, then the clients request is modified to
request an error message from the OCS or, more likely, from the proxy server (cache). This error
message is then supplied to the client. If the origin server URL was not banned, the ICAP server
would forward the request to the OCS via the proxy server and the request would be fulfilled.
292
Property
The REQMOD method enables scanning of HTTP PUT requests and HTTP POST request bodies.
FTP upload requests and outgoing Web mail also are scanned. The following example shows the
message an ICAP client might send to an ICAP server. Here, the REQMOD method applies to a
POST request. The ICAP client sends a message like this:
REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0

Host: icap-server.net
Encapsulated: req-hdr=0, req-body=147
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Pragma: no-cache
293
ICAP Settings
6OLGH,&$3VHWWLQJV
The ProxySG can automatically configure an ICAP service by detecting the settings of an ICAP
server. When editing an ICAP service in the Management Console at Configuration > External
Services > ICAP, clicking the Sense Settings button directs the ProxySG to automatically detect
ICAP service settings from the specified ICAP server. This helps avoid tedious configuration steps
to set up the service. These settings contain information about the ICAP service, including the
maximum number of connections allowed, the version of the ICAP server, and the methods used
to process transactions.
Before setting up and configuring an ICAP service, an ICAP client sends the OPTIONS command
to the ICAP server to check the options that the server can use. Options that are common to all
ICAP servers as well as those characteristic to the specific ICAP server are returned to the client.
As shown in the sample packet capture in the above diagram, the response is in the form of
headers listing the options that the ICAP server can use.
Supported headers include:
Methods: Specifies the transaction methods that are supported by the ICAP server. In the
example above, RESPMOD and REQMOD are supported.
ISTag: An alphanumeric tag that indicates the current state of the ICAP server. ISTags are
discussed in depth on the next page.
Max-Connections: Specifies the maximum number of simultaneous ICAP connections that

the ICAP server can handle.
Allow: Permits the ICAP server to tell the ICAP client which responses it supports. The
Allow: 204 directive tells the ICAP server to return a 204 No Content response if the
content does not need to be modified. The ProxySG includes the Allow: 204 directive in all
ICAP requests in both RESPMOD and REQMOD. The ProxyAV recognizes only the 204
parameter of the Allow directive.
294
Property
ISTag
6OLGH,&$3VHUYLFHWDJV
The ICAP service tag (ISTag) is a field in the response header that ICAP servers send to ICAP
clients to indicate their current state. ISTags are like timestamps from the ICAP server. ICAP
clients can compare ISTags to determine whether there has been an update or change in the state
of the ICAP server.
The ISTag sent by the ProxyAV is a string of digits, as shown in the above example.
IStags can change depending on upgrades made to the ICAP server, virus definition upgrades, or
the server policy. The ProxyAV updates its ISTag when its anti-virus engine or database is
updated. The ProxyAV and the ProxySG exchange health checks every 10 seconds by default.
Such checks also include exchange of ISTags, thus ensuring that ISTags are checked and updated
at least once every 10 seconds.
If there is a change in the ISTag associated with a cached object, the ProxySG sends the cached
object to the ProxyAV for rescanning and updates the cache to reflect the changed settings.
As shown in the above diagram:
1.
The client sends a request to the ProxySG.
2.
Assuming that the ProxySG has a cached copy of the object, the ProxySG checks the ISTag
associated with the object. If the ISTag matches the ISTag sent by the ProxyAV, the object is
sent from the cache to the client.
3.
If the ISTag does not match, the object is sent to the ProxyAV for scanning.
4.
The response is sent back to the ProxySG with the latest ISTag of the ProxyAV, which is stored
by the ProxySG for future requests of that object.
5.
The ProxySG sends the scanned new copy of the object to the client, fulfilling the request.
295
Data Flow
6OLGH'DWDIORZ
When a client requests data, the ProxySG sends its version of the file to the ProxyAV for scanning
and verification. If there are no changes to the file or to virus definitions, then the ProxyAV returns
the entire file if ICAP 204 is not supported. If the file has been modified, then the latest version is
returned to the ProxySG.
The ProxySG processes the transaction according to the type of request. If the request is a
RESPMOD, as shown in the above diagram, then the ProxySG sends an HTTP request to the origin
content server and gets the object. The ProxySG then sends the object to the ProxyAV for scanning
and verification. If there are no modifications to the file, then the ProxyAV returns an ICAP 204
response to the ProxySG. The object is then cached, if it is cacheable, and is sent to the client.
When data is being obtained from the OCS, the ProxySG stores data in its cache and starts
transmitting the content to the ProxyAV for scanning. This constant transmission of data speeds
the scanning process so that the object can be delivered quickly to the client.
However, if the object is larger than the caching threshold of the ProxySG, then the ProxySG
transmits all of the remaining content to the ProxyAV for scanning and does not cache the object.
The ProxySG cannot send an Allow:204 in its ICAP request headers to the ProxyAV, and the
ProxyAV has to respond with either a 200 (OK) or 500 (server error). If the response is 200, then the
entire scanned object is sent from the ProxyAV to the ProxySG and then delivered to the client.
The ProxySG caching threshold is the smaller of two values: one-fourth the size of the smallest
disk on the ProxySG, and the value of the Do not cache objects larger than field in the Management
Console at Configuration > Proxy Settings > HTTP Proxy > Policies. The default value for this field is
1,024 megabytes.
296
Property
Patience Page
6OLGH3DWLHQFHSDJH
Patience pages are created by an administrator while configuring ICAP on the ProxySG. They are
displayed when the ICAP server is processing a large object. Displaying patience pages can be
enabled or disabled by the administrator on the ProxySG. When a patience page is shown, the user
is informed that the requested content is being scanned.
Patience pages are displayed when the content is not delivered to the client even after the
specified time value for object delivery is reached. The default timeout value for a feedback or
response from the ICAP server is five seconds, but it can be changed by configuring the ProxySG.
Patience pages get displayed even if there is a pop-up blocker enabled on the system.
You also can create and customize text on a patience page used during delays to send HTTP
objects. Patience pages contain HTML (like a Web page) and specify to the user the details of the
scanning progress and the URL of the page being scanned. There is also a help section if users
experience a problem with the patience page.
As shown in the above diagram, the client sends a request for an object and the ProxySG sends the
file to the ProxyAV for scanning. While the scanning is being done, the ProxySG displays a
patience page to the user in the browser window through a JavaScript applet detailing the
process and the time needed to scan the file.
However, patience pages have some limitations:
Infinite streams: When HTTP is used to deliver streaming Web content such as webcam
images, the download from the server never ends. Patience pages get refreshed until the
ProxyAV or the ProxySG hit the maximum cacheable file size limit.
Non-graphical user agent: Because patience pages use JavaScript, user agents that do not
support graphics experience timeouts during the time when ICAP response modification is
processed. In some cases where the user agent tries to emulate a graphical user agent, the
patience page gets saved as the final content, making it difficult for users to access requested
content.
297
Request/response type limitations: Patience pages are sent to clients only when the HTTP
GET method is used. If any other methods are used, the patience page does not get delivered.
Even in the GET method, patience pages are sent only for 200 OK responses and not for any
other responses.
Content refresh and patience loop: In situations where content is refreshed while being
downloaded and scanned, users might experience finite or infinite loops. This is the reason
why patience pages are disabled for situations where such loops might form.
Concurrent requests: If there are multiple simultaneous requests made for cacheable content,
patience pages are delivered for the first request if the scan time is large. The same decision is
then also imposed on concurrent requests even if the process does not require display of
patience pages. All requests made while the ICAP response modification is in progress are
considered concurrent, so the chances of patience pages being displayed unnecessarily are
higher.
Clientless transactions: In transactions where scanning is a result of adaptive refresh or

pipelining of requests, patience pages are not delivered to the client that is waiting for the
result of the scan.
Scan and download times: There can be cases when the download time of an object is small
due to large bandwidth availability and the scan time is large due to overloading of the ICAP
server or decompression of content. In such situations, patience pages are not displayed to the
user even if the time taken to deliver content exceeds the time limit configured to display a
patience page. Patience pages are also not displayed to users when the HTTP proxy is
scanning cached content.
298
Property
Data Trickling
6OLGH'DWDWULFNOLQJ
Data trickling is another method that the ProxySG uses to notify a user that there is a delay in
scanning and processing the requested objects. Trickling is also used when objects are
experiencing scanning delays due to heavy load on the server or bandwidth limitations.
The ProxySG gradually trickles data to the client while the file is being scanned so that there are no
timeouts during the object delivery process. Data trickling can be an efficient alternative to
patience pages, especially since patience pages are available only in response to Web browser
requests.
To prevent a session timeout, the ProxySG can send a small amount of data to the user while the
rest of it is still being scanned. The complete object is sent to the client only after the scanning is
complete to maintain security and prevent entry of malicious software.
Data can be trickled from the start or at the end. When trickled from the start, the ProxySG sends a
small amount of the data to the user while scanning the rest of the object. This is a more secure
way of data trickling because if the object is found to be infected, the ProxySG ends the connection
immediately and does not transfer the remaining data. When trickled at the end, the larger part of
the object is sent to the user, and a smaller amount (16 KB) is kept back to scan.
Though this method is user-friendly (the user sees that they only have to wait for the remaining
1% of the object), it is not very secure. If the content is infected, the connection is terminated, but
the client already receives a large part of the insecure data that could lead to viruses infecting the
clients computer.
299
Deferred Scanning
6OLGH'HIHUUHGVFDQQLQJ
An infinite stream is an HTTP response that does not have any imminent end. Examples of infinite
streams are stock tickers, slow file downloads, and multimedia streams. Deferred scanning detects
ICAP requests that are unnecessarily holding up ICAP connections which often includes
infinite streams and then defers those requests until the full object has been received.
Without implementing deferred scanning or a policy-driven workaround, HTTP traffic on the
ProxySG can come to a halt. On the ProxySG, the maximum number of ICAP connections typically
is limited to between 50 and 200 connections per ICAP service. Each infinite stream uses one of
these ICAP connections until the ProxySG does not have any ICAP connections left. All
subsequent requests to the ProxySG are queued, but because the objects tying up the ICAP
connections have no end, the queued requests never are fulfilled. HTTP traffic does not recover
until the ProxySG is restarted by an administrator.
Deferred scanning is based on two factors: the number of outstanding ICAP transactions for a
service, and the time of the transactions. For each new RESPMOD, the ProxySG follows these
rules:
If the total number of outstanding ICAP actions for the service has reached the configured
deferral threshold, then the ProxySG defers the oldest ICAP connection that has not yet
received a full object.
A RESPMOD that already has sent its request and is waiting for an ICAP response is no longer
eligible to be deferred.
When a request is deferred, the ICAP connection is closed. The application response continues to
be received, and when the full response is received, ICAP attempts to scan the object. This
RESPMOD is not eligible to be deferred because the download is already complete and cannot be
an infinite stream. This RESPMOD still might be queued if there are no available ICAP
connections, but it has a higher priority in the queue than do new requests. A RESPMOD can be
deferred only once.
300
Property
Deferred objects can cause a delay in response because the entire object has to be sent to the ICAP
service at once for scanning. If a patience page is configured, however, the users Web browser
continues to receive a patience page even if the scan is deferred. Also, trickling works as usual.
If a RESPMOD is deferred and the object size grows beyond the maximum cache size, the user
receives an error. This is to prevent the cache from being abused by infinite streams. The
maximum cache size for HTTP objects is set in the Management Console at Configuration > Proxy
Settings > HTTP Proxy > Policies.
The deferral threshold is set in the Management Console at Configuration > External Services >
ICAP. Select the ICAP service from the list, and click Edit. If the Defer scanning at threshold
checkbox is selected, a percentage value can be specified, representing the percentage of ICAP
connections in use at which scanning can be deferred. The default is 80%. Blue Coat does not
recommend setting the deferral threshold to 100% because that level often is too late to prevent
HTTP traffic from halting.
The above example shows a simplified deferred-scanning scenario with a maximum of 10 ICAP
connections and where an 80% threshold has been configured:
1.
Clients have requested a combination of media streams, stock tickers, and slow file
downloads that are being processed by the ProxyAV, using eight of 10 available ICAP
connections to the ProxyAV.
2.
Another client requests an object.
3.
The ProxySG requests the object from its server and prepares to submit it for anti-virus
scanning.
4.
However, because eight of the 10 available ICAP connections are already in use, the ProxySG
defers the ICAP connection of the oldest entry in the list. The ProxySG continues to receive the
slow download that has been deferred, and it is submitted for scanning once the download is
complete.
5.
Now that an ICAP connection is available, the object can be scanned.
6.
After scanning completes, the object is served to the client.
Note:
Deferred scanning does not reliably detect the presence of an infinite stream. Instead,
the age of ICAP connections is used to identify objects that exhibit some properties of
infinite streams, but those same properties can apply to other objects, such as very
slow downloads. This is not a problem for the ProxySG because both all such objects
affect the availability of ICAP connections and, therefore, warrant the same type of
deferral behavior. Also, infinite streams that run at a low data rate (such as a stock
ticker) still might need to be bypassed in policy in order to function properly.
301
Scanning Behavior
6OLGH6FDQQLQJEHKDYLRU
The ProxyAV uses the MD5 cryptographic algorithm to check files while scanning. Files that have
been scanned before are stored in the archive with a 32-character signature to distinguish among
files.
The MD5 hash is a 128-bit value and can be compared to the fingerprint of a file. There is very little
possibility that two files can come up with the same hash. This property of the MD5 hash is very
useful when comparing files.
MD5 hashes change every time the ISTag is changed or when definitions are updated. This feature
allows the ProxyAV to check the results of file scans when the same file is requested and sent by
the ProxySG. Files having the same MD5 hash value are considered to have the same scan result.
Any changes in the value prompts the ProxyAV to rescan the file and process the object request
accordingly.
302
Property
Load Balancing
6OLGH/RDGEDODQFLQJH[DPSOH
The ProxySG supports weighted load balancing in forwarding requests to external service groups
consisting of multiple ICAP servers.
Weighting is set with the service groups Entry weight parameter that can be edited in the
Management Console at Configuration > External Services > Service-Groups. It determines what
proportion of the load one server bears relative to the others.
When a new ICAP request arrives at the load balancing group:
1.
The ProxySG calculates the transaction index for each server as the ratio of waiting
transactions to configured server weight.
2.
The ProxySG searches for the ICAP service with the lowest transaction index and for which
the number of active transactions is less than the number of maximum connections.
3.
If no such service exists, then the ProxySG calculates the queue index for each server as the
ratio of pending queue length to configured server weight.
4.
The ProxySG selects the ICAP service with the lowest queue index and adds the request to its
pending queue.
In the above example, a load balancing group has been configured to contain ProxyAV1 and
ProxyAV2. Because ProxyAV1 has a lower transaction index and has available connection slots,
the ICAP request is directed to ProxyAV1.
303
Load Balancing
13
6OLGH/RDGEDODQFLQJH[DPSOH
In the above example of ICAP load balancing:
ProxyAV1 has a transaction index of 1 (1 waiting connection divided by weight 1).
ProxyAV2 has a transaction index of 5 (5 waiting connections divided by weight 1).
Only ProxyAV2 has free connections available, so the next ICAP action is assigned to
ProxyAV2.
Before configuring weights, consider the relative weights to assign to each server. Factors that
could affect assigned weight of a ICAP server include:
The processing capacity of the server hardware in relationship to other servers (for example,
the number and performance of CPUs or the number of network interface cards).
The maximum number of connections configured for the service. This setting pertains to how
many simultaneous scans can be performed on the server, while weighting applies to
throughput in the integration. While these settings are not directly related, consider both
when configuring weighted load balancing.
304
Property
Secure ICAP
6OLGH6HFXUH,&$3
Plain ICAP request and response modification is done over an unencrypted data channel. This
might not be acceptable for users who perform scanning of confidential data; the data is decrypted
on the ProxySG and sent unencrypted to the ICAP server. To address this, ICAP can run over a
Secure Sockets Layer (SSL) connection in a configuration known as secure ICAP.
Secure ICAP has three goals:
Protect transmission of data between the ProxySG and an ICAP server when the ProxySG
performs ICAP processing.
Authenticate the ICAP server to prevent interception by rogue servers.
Protect the integrity of data to prevent it from being modified by an unauthorized source.
The ProxySG can support both plain ICAP and secure ICAP simultaneously, and secure ICAP can
be configured to failover to plain ICAP. The default TCP port for secure ICAP is port 11344. When
secure ICAP is configured, the administrator must select an SSL device profile to use with the
service. All other ICAP configuration parameters are the same as for standard ICAP.
ICAP servers that support secure ICAP include the ProxyAV and Webwasher.
When the ProxySG is operating in Federal Information Processing Standards (FIPS) 140-2 mode,
only secure ICAP services are allowed. Administrators cannot enable plain connections for ICAP
service. Also, only FIPS-compliant SSL device profiles are allowed for ICAP services. Additional
details of operation in FIPS mode are beyond the scope of this course.
305
Standard Malware Scanning

Creates ICAP response service for each ProxyAV
proxyav1, proxyav2, proxyav3, ...
ICAP services are assigned to service group proxyav
Installs general-purpose CPL policy from Blue Coat
Policy is linked to settings in Management Console
6OLGH6WDQGDUGPDOZDUHVFDQQLQJ
The previous chapter described the simple procedure for quickly setting up malware scanning on
the ProxySG. When this feature is enabled, the ProxySG automatically performs the following
steps:
For every ProxyAV that you specify in the configuration, the ProxySG creates a corresponding
ICAP RESPMOD service named proxyavN, where N is a consecutive number.
All of these ICAP services are assigned to one service group named proxyav. Each ICAP
service in this group is assigned the same weight. This means that ICAP requests are equally
distributed among the configured ProxyAV appliances.
When Enable malware scanning is selected, the ProxySG policy is recompiled to include a
pre-written CPL policy provided by Blue Coat. This policy defines the actual logic followed by
the ProxySG when subjecting Web objects to scanning. It is compiled first, which means that
any virus-scanning policy that you write has a higher priority and overrides the Blue Coat
policy.
The CPL policy is linked to the proxyav service group, and configuration parameters are set in
the Malware Scanning page. For example, by switching the Action on unsuccessful scan
parameter to Continue without malware scanning, the fail_open parameter is added to the
response.icap_service(proxyav) statement in the CPL policy, which means that if an
object cannot be scanned, it is delivered to the client unscanned.
306
Property
Customized Malware Scanning
6OLGH&XVWRPL]HGPDOZDUHVFDQQLQJ
If the standard malware scanning algorithm is not suitable for your environment, you can use an
alternative method that is more complex but provides more detailed control over the ProxySG and
ProxyAV integration. For example, by using this approach, you can create several service groups
or implement a granular policy that considers values in the client or server messages. In fact, one
special case of this procedure is automatically executed by the ProxySG when the standard
scanning feature is enabled.
To implement a customized malware scanning mechanism:
Go to Configuration > External Services > ICAP and define an ICAP service for each ProxyAV to
be used.
For each ICAP service, complete the following steps:
Enter the ICAP service name of the ProxyAV.
Specify whether this ICAP service is associated with RESPMOD or REQMOD

transactions. In the standard malware scanning configuration, all the services are
RESPMOD ICAP services.
Set whether plain ICAP and secure ICAP should be used for communication.
Instruct the ProxySG to sense settings from the ProxyAV. This step is not executed in the
standard malware scanning configuration.
Adjust the maximum number of connections and connection timeout.
Perform any other steps as required.
Assign the ICAP services to service groups if load distribution should be used.
Write a policy that instructs the ProxySG when and how to use the defined ICAP services or
service groups for virus scanning.
In the standard malware scanning configuration, most of these settings are automatically set by
the ProxySG.
307
Monitoring ICAP Sessions
17
6OLGH0RQLWRULQJ,&$3VHVVLRQV
You can view the status of ICAP connections on the ProxySG with the Statistics > Sessions >
Proxied Sessions display. The display shows the status of all sessions on the ProxySG; you can use
the filtering capabilities of the command to show only ICAP connections.
Client connections are available for viewing as soon as the connection request is received.
However, if delayed intercept is enabled, the connection is not shown until the three-way
handshake completes. Server connections are registered and shown in the table after the connect
call completes.
You can filter the display by type (any, REQMOD only, or RESPMOD only), service name, and
ICAP state (any, transferring, deferred, scanning, or completed).
In the Proxied Sessions display, the I column shows the status of each ICAP session:
Transferring (arrow): ICAP requests are being transferred to the ICAP server.
Deferred (clock): ICAP scanning requests have been deferred until the full object has been
received.
Scanning (magnifying glass): ICAP requests are in the process of being scanned.
Completed (checkmark): ICAP scanning requests completed successfully.
Inactive (i): The ICAP feature is inactive for the session.
You can end a session by selecting it and clicking Terminate Session. Other than the interrupted
the connection, a user receives no notification that the session has been terminated.
308
Property
Chapter 26: Introduction to Director
Administering a Blue Coat ProxySG is easy with the Management Console. However,
installing configuration or policy updates on multiple appliances particularly in a distributed
environment can be a tedious and time-consuming task. Blue Coat Director centralizes the
process, enabling organizations to standardize configuration and policy and cut administrative
costs.
Director is a powerful platform for configuring, managing, and monitoring all of the ProxySG
appliances in an organization individually or in groups from a single location. With Director,
you can perform the following tasks:
Install and update configurations and policy.
Monitor ProxySG performance.
Distribute and control content.
Perform backups.
You can perform most tasks through an easy-to-use management interface that runs on any
Microsoft Windows client with a Web browser and the Java Runtime Environment. Some tasks
such as upgrading the SGME operating system on Director are performed through the
command line interface.
Director is a full-featured tool with many options and possible uses that are beyond the scope of
this course. Separate training courses in Director are available from Blue Coat and Blue Coat
Authorized Training Centers.
Ideal for WAN Application Acceleration

Director can be anywhere on your network, provided that it can connect to ProxySG appliances
through SSHv2. Director can manage appliances even over the WAN making it ideal for large
organizations with many branch offices.
Each Director can manage up to 500 ProxySG appliances. Blue Coat recommends the use of
Director for organizations with six or more ProxySG appliances. Organizations with four or more
ProxySG appliances might find Director useful if they make frequent changes to configurations or
policy.
Because of its scalability, features, and ease of use, Director is especially useful for organizations
using Application Delivery Network to accelerate WAN traffic. Director makes it simple to
configure and manage the multiple ProxySG appliances that their networks require.
Director Terminology
The following terms have specific meanings when discussing Director:
Device: A ProxySG when it is connected to Director.
Director: The Director appliance, encompassing the hardware and software.
Director CLI: The command line interface for the SGME operating system.
Director Management Console: Directors graphical user interface software, which is installed on
a PC.
Director management node: The Director hardware.
309
Overlay: A few selected settings used to replace some of the configuration and policy on one or
more devices.
Profile: A snapshot of all the configuration and policy from a source device. It can be applied to
one or more other devices. Note that it does not include device-specific network settings, such
as the IP address.
Pull: Extract settings from a reference device.
Push: Apply settings from a reference device to a target device.
Reference device: A device from which you pull a profile or overlay, which can then be applied
to other devices.
Refresh: To reapply a setting from a reference device to a target device in order to update the
setting.
SGME: The name of Directors operating software.
Target device: A device that receives a profile or overlay from a reference device.
310
Property
Director Deployment
6OLGH'LUHFWRUGHSOR\PHQW
A Director appliance typically is installed at an organizations headquarters. From there, it can

configure, manage, and monitor ProxySG appliances throughout the organization. Centralized
management saves time and reduces costs; it eliminates the need to configure each appliance
individually and the need to be physically near each appliance. Using Director, administrators can
perform a wide range of specific tasks for multiple ProxySG appliances:
Configuration and policy management:
Create and install standard configurations and policies throughout the enterprise. These
can include settings to enable application acceleration over the WAN.
Customize settings for appliances in certain regions or logical groups.
Schedule configuration and policy changes.
Back up and recover settings.
Upgrade systems.
Distribute software licenses.
Resource and content management:
Manage bandwidth to conserve valuable resources.
Distribute content, including frequently used files to ProxySG caches, expediting

downloads and reducing network traffic.
Limit access to Internet and intranet resources.
Monitoring and planning
Monitor key hardware and software metrics of ProxySG appliances remotely.
Create settings to issue alerts when certain changes occur.
Use statistics to evaluate and update network policies.
311
Components and Communication
6OLGH'LUHFWRUFRPSRQHQWVDQGWKHLUVHFXUHFRPPXQLFDWLRQV
The Director platform consists of three elements: the Director appliance and its operating
software, the client computer from which you manage Director, and the ProxySG appliances
connected to Director. Each component communicates securely with the others.
Director appliance: The Director appliance consists of a ProxySG chassis and the Security
Gateway Management Edition (SGME) operating system. Director is available either on an
ProxySG800/810 chassis or a ProxySG510 chassis.
Client interface: You can manage Director from any PC in your organization that can connect
to Director through a Secure Shell (SSH)v2 link. The Java-based Director Management
Console, which you install on the PC, provides the graphical user interface for managing
ProxySG appliances.
ProxySG appliances: After you connect to Director, you can connect, or add, ProxySG
appliances to it. Once a ProxySG is added to Director, it is called a device. You then use the
Director client interface to configure, manage, and monitor the devices.
The three-way communication among Director, the client, and devices is secure: Director
communicates with the client and with devices over an SSHv2 link, and the client and devices
communicate over a Secure Sockets Layer (SSL) link. The client retrieves some system statistics
directly from a ProxySG and uses it to populate the Director Management Console.
312
Property
Managing Devices
6OLGH0DQDJLQJGHYLFHV
Administrators can perform a variety of actions through Director to manage ProxySG appliances
throughout the enterprise. The most basic are grouping devices, applying profiles and overlays,
scheduling jobs, and backing up devices.
Grouping devices: You can manage and monitor ProxySG appliances individually or in
groups. Organizing devices in groups enables you to change their configuration and apply
policies to all members of the group with a single action.
Applying profiles: A profile is a snapshot of all the configuration and policy on a ProxySG for
the IP address and other information specific to the device. You use Director to pull, or extract,
a profile from a reference device, save it, and then push, or apply it, to other devices.
Applying overlays: An overlay consists of one or a few settings that you can apply to devices
in order to fine-tune their configuration or policy. Overlays are used in conjunction with
profiles to create custom settings.
Scheduling jobs: You can apply a device-managing task at once or you can schedule it as a job.
For example, you can schedule jobs to push or refresh profiles and overlays or to back up or
reboot devices. Jobs can be executed a single time or can recur.
Backing up devices: You can back up a device at any time by using the Backup Manager
feature in the client interface. Or you also can create a job to back up one or more devices at a
specific date or time. Appliance backups are stored on Director and can be restored easily.
313
Monitoring Devices
6OLGH0RQLWRULQJGHYLFHVZLWK'LUHFWRU
Directors client interface includes a Monitor tab that enables you to view the status of each
ProxySG device and group of devices quickly and graphically. It includes a summary of the
current health status and alerts for devices that Director manages.
The Current Device Status indicators show how many devices are currently in a particular health
state. Unacknowledged Alerts indicators show how many unacknowledged alerts have
accumulated on Director; however, these alerts do not necessarily represent the current health state
of the device.
Director displays health in the form of a small colored icon: Green indicates the device status is
OK, yellow indicates a warning, and red indicates a problem that requires immediate attention.
In order to monitor devices through Director, you must configure the device to send traps to the
appliance. You can configure devices to send traps to Director either manually or through a profile
or overlay.
You also can use the Monitor tab to view statistics for individual devices.
314
Property
Managing Content
6OLGH0DQDJLQJFRQWHQW
Users throughout a distributed network often need to access content that is typically stored in an
organizations data center. For example, employees often need to retrieve benefits information and
forms, technical documentation, or instructional material. However, accessing these centralized
files from the branch offices can slow down your network.
Content Delivery Networks enable organizations to optimize the delivery of content to end users
throughout distributed networks. In order for a CDN to be efficient, administrators must be able
to delivery data center content to branch offices before users request it, a practice called content
prepopulation.
By placing and maintaining content on branch office ProxySG appliances, you can serve content at
LAN speed to users. You also can save WAN bandwidth by pushing large content files to branch
offices during off-peak hours.
Director helps optimize the CDN by enabling you to add content, either through prepopulation or
on an as-needed basis. It also validates content, which ensures that all users access identical
information at the same time. Director also enables you to create content priority and delete
outdated content.
315
Administering Director
6OLGH$GPLQLVWHULQJ'LUHFWRU
Administrators need to manage the Director appliance itself as well as the devices connected to it.
A key concern for administrators is keeping unauthorized users from accessing Director and,
through it, ProxySG appliances in the organization.
You use the command-line interface to set up user accounts to Director and to authenticate users.
Different levels of privilege can be granted to each account. At the lowest level, a user can view
logs and the results of commands but not make any changes. At the highest level, a user can
schedule jobs, manage content and users, and make permanent changes to Directors
configuration.
Users can be authenticated through locally configured accounts and passwords. This is the default
method and cannot be disabled. However, Director also allows you to use two other
authentication methods: Remote Authentication Dial In Service (RADIUS) and Terminal Access
Controller Access Control System (TACACS+).
Once you have authenticated users, you can keep track of all the tasks that they perform on
Director. Director records all user commands in its event log. Log messages include the username
of the person executing the command, the IP address of the users computer, and other
information specific to the action.
Director, in addition to allowing you to back up ProxySG devices, allows you to back up the
Director configuration. You can make a partial backup, which backs up only the Director
configuration, or you can make a complete backup, which backs up the Director event logs, job
reports, and ProxySG backups in addition to the Director configuration.
316
Property
Appendix A: Understanding Digital Certificates
Classic cryptography relies on a single key, which is used to encrypt and decrypt data. If Bob
wants to share a secret with you, he encrypts the message with a secret key. He then sends you the
message and the key. This method is called symmetric cipher.
Throughout the history of cryptography, the most challenging tasks have been how to share the
keys, how to guarantee that the message is not compromised, and how to ensure that the key
remains secret. In proper terms, a strong and reliable architecture that allows secure data
transmission defines the following five parameters:
Authentication: validation of the parties involved
Key exchange: sharing of the secret keys
Confidentiality: transfer data, which has been encrypted with a strong algorithm
Integrity: assurance that the message is genuine and was not tampered with
Non-repudiation: assurance that the recipient received exactly what the sender transmitted
The Internet demands an encryption system that is fast, reliable, secure, and dynamic. The
fundamental question is how to deliver the key in secure way over the Internet. There is no
practical or efficient answer to that question using a symmetric cipher model.
Public Key Infrastructure

The modern alternative relies on a revolutionary concept in which the key used to encrypt data is
different from the one used to decrypt data; this method is called asymmetric cipher.
Lets assume that you, on the left in Figure 1, want to exchange sensitive information with Bob, on
the right, who is your personal banker. Using the asymmetric system, you send Bob a public key,
which he will use to encrypt data he sends to you. You need not worry if a third party intercepts
that key. All the third party can do is encrypt data; only you can decrypt data using the correct key.
Bob in turn sends you his public key to encrypt data you send to him.
Once the public keys are exchanged, you and Bob can securely communicate both ways. However,
you must keep the private key secret. The private key is the one that you use to decrypt the
documents coded with your matching public key.
Figure 1: Simplified asymmetric cipher model
317
This new approach solves the problem of key exchange, but the model, as explained so far, is too
basic to cover the other four areas of concern. For instance, this solution does not do anything to
authenticate the parties involved. How can Bob be sure that he is talking to you and most
importantly is he actually using your public key and not somebody elses? Lets see how a
hacker can exploit the basic key exchange process to intercept and read your confidential
information.
Man-in-the-middle attack
When you ask Bob to send you confidential information, a hacker can use a well-conceived attack
to gain access to the information without your knowledge. Figure 2: shows how this happens.
The hacker, Kevin, intercepts your message to Bob (1). Kevin grabs the message, substitutes your
key with his, and then sends the message on to Bob (2). Bob replies and encrypts the message
using Kevin public key and not yours (but he thinks hes using yours). Kevin intercepts Bobs
message to you (3), grabs it, decodes it (using his own private key), reads and stores it, encrypts it
using your public key, and then sends it back to you (4).
You and Bob live happily thinking that everything went well and that your information was
delivered securely.
Figure 2: Man-in-the-middle attack
Fortunately, cryptographers and security vendors have enhanced the basic asymmetric cipher
idea to minimize the possibility of such exploits like a man-in-the-middle attack and brute-force
password retrieval.
What is a Digital Certificate?

A digital certificate is the ether-world equivalent of an ID card. Everybody carries a document of
some sort to certify identity. In a very similar way, a digital certificate uses public key encryption
to verify the authenticity of a user. The digital certificate states who the user is and where she lives
and contains the two copies of the public key (one in clear text and one encrypted).
However, that information in itself does not guarantee the users identity. For instance, if you
show up at a bank with a piece of paper with your picture and your name on it, which you printed
yourself, it is unlikely that the clerk will let your withdraw any cash. The picture and the name
alone are not sufficient proof of you identity. The clerk is trained to ask for some form of
government-issued ID for example, a drivers license or passport. The issuing agency must be
an entity that both she and you trust.
In the digital world, the equivalent of the passport authority is called Certification Authority or
CA.
318
Property
A familiar situation in which you receive a digital certificate is online shopping. The success of
e-commerce is based on a secure channel of communication between a seller and a buyer. An
e-commerce Web site sends your browser a digital certificate that was approved by an authority,
which your browser trusts (see below). Most of the time, this process is completely transparent to
the end user. However, you can see a list of digital certificates that your browser has received. In
Internet Explorer, go to the Tools, then click the Internet Options menu option. Select the Content
tab and then click the Certificates button. You can see a list of certificates that your browser trusts.
Figure 3 shows a sample certificate. There are several pieces of information on a certificate; the
most important ones are:
Issued to: The person or the legal entity to whom the certificate was issued.
Issued by: The CA who issued the certificate.
Validity: The life span of the certificate. This can be typically one or two years.
Figure 3: Sample Digital Certificate
This particular certificate was issued using a root CA created inside Senforce for an internal site.
You can see that the Issued to and Issued by fields have the same value; you should also notice that
the certificate is valid for a limited period of time, two years in this case.
Digital Certificates in SSL (Secure Socket Layer)

SSL establishes, in its most common use, a secure connection between a remote user and a Web
server on the Internet. The digital certificate verifies the authenticity of the parties involved. As
mentioned before, the remote user needs to trust the CA, which issued the certificate.
319
Because SSL originally was designed for e-commerce1, speed, ease of use, and transparency are
important factors. SSL does authenticate the server, but it does not require the client to have a
valid digital certificate to authenticate itself. It would be too hard and expensive for the end user
to have a digital certificate issued by a trusted CA. The e-commerce site is willing to take a risk.
After all, an end user must enter enough information about herself in order to process the financial
details of the transaction: full name, credit card number, billing address, zip code, phone number,
and probably more.
During the transaction, some information is exchanged between the browser and the remote site;
these data include:
SSL versions supported by the browser
The encryption algorithms supported by the browser
A string of randomly generated data
The browser now has most of the information needed; for final verification, the browser decrypts
the digital signature attached to the server's certificate. If the key that the browser received can
positively recover the digital signature, then the client accepts the identity of the server. Finally,
based on the information exchanged earlier, the browser will use the most secure encryption
algorithm supported by both client and server.
A pre-master pass phrase is created from the data involved in the transaction up to this point. The
browser encrypts the pre-master pass phrase using the public key received from the server and
sends it back. The server decrypts the pre-master pass phrase. If everything goes according to
plan, after some calculations, both parties determine an identical master secret, which allows them
to create a session key. After the session key is created, the SSL tunnel is active and the browser can
exchange data with the server via the symmetric session key.
Figure 4: Sample SSL transaction
In Figure 4, you can see how the initialization of an SSL transaction works. The actual details are a
bit more complex. For instance, the server and the client need to agree not just on the version of
SSL to use but also on the actual algorithm for the key exchange (RSA or other), the method for
encrypting the secret keys (DES or similar), the method used to compute the message digest and
finally the data compression algorithm (gzip or other). Note that most of the Internet transactions
exchange data, which have been compressed using gzip or a similar function. Even the HTTP
protocol, supports, starting with HTTP/1.1, compressed data.
Message Digest
When you receive a message, you need the assurance that the message is really from the person
you think it is, and that the message was not tampered with while in transit.
1. Netscape developed SSL in 1994. The most recent release of SSL is v. 3.

320
Property
A number of algorithms are used to calculate a signature for a given file. For instance, CRC and
MD5 generate something very similar to a digital signature. The limitation of these processes is that
they are, in general, not reversible; you can calculate the signature of any document, but you
cannot retrieve the message from the signature. The advantage offered by these methods is the
total length of the signature, which is relatively small compared to the length of the message.
Bob wants to send you a message and ensure that it was not tampered with. He creates the
message, then, using MD5 hashing, calculates the digest for the message. He sends you the
message and then the digest. You receive the message, apply the same MD5 process to the
message, and finally you check your digest with the one that Bob sent you. If there is a match, the
message was not tampered with; otherwise, you cannot trust the message content.
Of course, you need to take an extra step to protect your message and your digest. The hacker,
Kevin, is well versed in hashing technologies and knows how to create an MD5 signature.
You need to encrypt the message digest using your private key so that only your matching public
key will decrypt it. The use of public/private key pair allows you to verify both the authenticity
and the integrity of the message.
What is a Certification Authority?

The CAs role is to validate that Marcie is really Marcie and the public key that she is sharing is her
own. For example, when you connect to an e-commerce Web site and place an order, you want to
make sure that the public key that you receive from the site does indeed belong to that Web site
and not to a hacker who is trying to hijack your credit card information.
Figure 5: The role of a Certification Authority
Figure 5 shows the role of a CA. You want to obtain a digital certificate, so you apply for it by
sending a request to the CA (1). The CA examines your request and approves it, issuing you a
digital certificate (2); the digital certificate will prove your identity to third parties. You can now
send your digital certificate to Bob (3). Bob needs to make sure that you are who you claim to be.
Since the digital certificate contains the name of the issuing CA, Bob verifies it with the CA (4). If
the certificate is authentic then the CA validates it1; at this point Bob knows that you are really the
person he is talking to (5).
In general terms, a CA issues the certificates that you need to implement your public key
infrastructure (PKI).
1. It is actually the browser that trusts the CA and validates the certificate using the CA public key.
321
There are different types of CA; you can run a CA within your own company. Microsoft Windows
2000 Server and higher allows you to create two types of CAs: Enterprise CA and Stand-alone CA,
based on which option you select during the install. There are two sub-types for each type of CA:
root and subordinate. The actions that your CA can take are defined by which policy modules you
have. A CA can issue, reissue, or revoke a digital certificate.
Mathematical Basis of Digital Ciphers

You want Bob to send you a message that is encrypted with your public key. Bob gives you an
answer based on the numbers that he chooses from a list. He needs to send you back a single
number, which contains the choices he made.
For instance, you want Bob to pick the list of items from a menu. If you assign each item a number
and you choose the numbers in a way the next one in the sequence is greater than the sum of all
previous numbers, you have a magic list, where the sum of any numbers of items from the
menu makes a unique value.
Table 1 shows a sample menu with assigned values to each choice.
Table 1: Super-increasing sequence
Value
Menu Item
Salad
Steak
Chicken
14
Salmon
28
Minestrone
56
Pasta
If Bob wants a salad, steak, and pasta, he will reply with the number 62. Now for you it is easy to
figure out what he wants:
62 is greater than 56, so you know that he wants pasta. Then 62-56=6, which means that he wants
steak. Finally, 6-5=1 tells you that he also wants salad. 1-1=0: You are done!
You are probably wondering what is the rigorous process to get back from the number to the items
on the menu. To start, remember that:
n1
Xi < Xn
i=1
where n is the number of items in the menu, X is the value of the item in position i on the menu. So
if the value returned by Bob is greater then Xi but smaller than X(i+1), then he had to have ordered
at least the item in position i and could not have ordered item (i+1).
Unfortunately, you are not the only one good at math. Kevin, our hacker, is just as good, if not
better. So you need to make his life difficult.
322
Property
Modular Mathematics
In a simple division between two numbers, for instance 14 and 3, you define 14 as the dividend, 3
as the divisor, 4 as the quotient, and 2 as the remainder. So you have
divisor x quotient + remainder = dividend
Now, there is a less well-known mathematical operator called modulus. The modulus between
two numbers is basically the remainder of the division between the two:
(1) 14 mod 3 = 2.
Simple! Given two prime numbers x and y, you can determine a number
(2) n = (x-1) * (y-1)
so that:
(2b) z(n+1) mod (x*y) = z for any value of z
The product of x * y must be greater, at least by one, than the maximum number that you want to
encrypt. Pick x=17 and y=5, so that you can play with somewhat large numbers:
(2c) n = (17-1) * (5-1) = 64.
As per the formula (2) above
(3) z(64+1) mod 85 = z for any value of z
The number 65 can be factored1 as 13 x 5. This means that still:
(4) z(13*5) mod 85 = z for any value of z, which can be re-written as
(5) (z13)5 mod 85 = z so if you calculate
(6) z13 mod 85 = k then you can obtain
(7) k5 mod 85 = z
The formulas (6) and (7) clearly show how you can use the prime factorization of the value n + 1
also known as the Euler totient or to create a public and a private keypair.
You can now give 13 to Bob to be his public key and ask him to encrypt his answer using the
simple formula:
(8) k13 mod 85
Bob answer was 62, so applying the formula you obtain:
(9) 6213 mod 85 = 7 so 62 did encrypt as 7.
When Bob sends you his result, you will apply the private key (5) and use the formula
(10) 75 mod 85 = 62, which is exactly what Bob, wanted you to have.
Kevin will have a very hard time figuring out the modular inverse of 7, even if he has your public
key, which, as the calculation shows, offers no help in calculating your private key. In a simple case
like this, Kevin can calculate all of the possible combination of food that you may pick, which are
26-1=63. Then he can use your public key to encrypt every one of the 63 choices and match them
with your encrypted response. By doing so, Kevin does not even need to bother with your private
key. Of course the greater the number of possibilities, the more impractical this attacks becomes.
However, this approach remains one of the simplest ways to figure out what is being sent in an
encrypted message.
1. Any integer can be expressed as the product of its prime factors. A prime number has only two factors, 1
and itself. For instance, 24 factors as 1 x 2 x 2 x 2 x 3, while 3 factors as 1 x 3.
323
324
Property
Appendix B: Understanding Kerberos Authentication
The Kerberos authentication protocol, as described in RFC 1510, provides a means of verifying the
identities of a principal (such as a workstation user or a file server) on an unprotected network.
Since its inception in 1993, the Kerberos protocol was designed to handle authentication in a
network environment, which cannot be assumed to be secure.
Several fundamental differences exist between the Kerberos model and the NT LAN Manager
(NTLM) model. The single biggest difference between the two is that in the Kerberos model,
neither server nor clients are assumed to be trusted. Both the client and the server need to trust a
third entity that is in charge of verifying the identity of each party involved with authentication.
Another difference is the concept of obtaining authentication for a principal. A client does not
require simple authentication but more precisely asks for authentication for a principal.
The client issues a request to an Authentication Server (AS) for credentials for a specific principal.
The AS replies with an authentication ticket and an encryption key. The client uses the encryption
key to exchange data with the server over a symmetric cipher. The session key sent to the client is
encrypted in the ticket using a key shared between the AS and the client. The ticket contains the
same session key and the client identification. This information is encrypted in the ticket using a
key shared between the AS and the principal for which the client asked to authenticate.
Additional measures are defined in the protocol to void any attempts to use a reply attack.
Kerberos is the name of the three-headed dog that guarded the underworld in ancient Greek
mythology. The creature appears in Dantes Inferno under its better-known Latin name, Cerberus.
Three components are required in order to implement Kerberos authentication in a network. The
three heads in the Kerberos protocol represent:
1.
A client that needs to be authenticated.
2.
The Key Distribution Center (KDC), which manages the tickets necessary to access resources
and services on the network.
3.
A server hosting the services that users want to access.
The domain controllers in Microsoft Active Directory play the role of the KDC. The KDC
processes the authentication request from the clients and generates the necessary tickets that the
clients need to present to the services and resources on the network in order to get access to them.
A ticket is divided into two parts. The first part is in plaintext. The second part is encrypted (using
RC4) with the long-term server key. The second part of the message is exactly the same as it was
received by the client from the KDC. Because it is encrypted with the server long-term key, the
client cannot read its content; only the server can.
Key Distribution
Figure 1 shows a simplified version of Kerberos authentication and describes it from a logical
rather than functional standpoint.
325
Figure 1: Simplified key distribution
In this example, George (the client) wants to authenticate with Bob (the server). Imagine the
process being divided into three steps:
1.
George asks the Key Distribution Center for a session key to talk to Bob.
2.
The KDC generates a session key and sends it to George encrypted with Georges long-term
key.
3.
The KDC sends the same session key to Bob encrypted with Bobs long-term key.
Once the two parties have received the session key from the KDC, they do not need to have any
further interaction with it. As long as the session key is valid (the time value is configured), the
KDC is no longer involved.
The reduced need for communication between the client/server and the KDC is one of the main
advantages of Kerberos over NTLM.
Figure 2: Distribution of session tickets
In reality, however, the KDC does not send any information to the server. As shown in Figure 2,
the actual process is as follows:
1.
George asks the Key Distribution Center for a session key to talk to Bob.
2.
The KDC generates a ticket and sends it to George. The ticket George receives from the KDC is
separated into two parts:
3.
The client part, in which the session key is encrypted using the clients long-term key.
The server part, in which the session key is encrypted using the servers long term-key.
George extracts and reads the session key from the client part of the ticket, which he can read
and then sends the rest the server part to Bob.
The client can read only the first part (the client part) of the response received from the KDC. The
part that it does not understand is sent as-is to the server. Because this part is encrypted with the
servers long-term key, the server has no difficulty reading it.
Because only the server and the KDC know the servers long-term key, the server can trust the
ticket received by the client as authentic and generated directly by the KDC.
326
Property
Appendix B: Understanding Kerberos Authentication
In this model, server and client can trust each other and the KDC because the correct long-term
and session keys are known to the appropriate parties.
Ticket Types
Kerberos uses two different types of tickets. The client obtains the first ticket when it first logs in
the network. This ticket is known as Ticket Granting Ticket (TGT). The other type of ticket is used
to obtain a ticket to obtain access to a given resource; this is called Ticket Granting Service (TGS).
The Authentication Service (AS) assigns a TGT to the client. The client uses the information in the
TGT to obtain a TGS. The process works like this:
1.
The client connects to the KDC and requests a TGT. (The AS is one of the roles that the KDC
assumes in the Kerberos model.)
2.
The AS responds with a TGT that consists of two parts:
3.
A session key encrypted with the clients long-term key.
A session key encrypted with the KDC long-term key.
The client connects to the KDC using the session key to request a TGS.
Authentication in Multiple Domains

Users in one domain can access resources in another domain, as long as there is a path of trusts
between the two. In Figure 3, the client in Domain A wants to access a file server in Domain B.
Figure 3: Authentication in multiple domains
Kerberos uses the concept of referral tickets to allow clients in one domain to obtain access to
resources in another domain. The referral ticket works very similarly to the other tickets discussed
so far.
In the example illustrated in Figure 3:
1.
The client in Domain A sends a request to the KDC in Domain A. The request is encrypted
using the session key, which the client shares with that domain. (The client is assumed to have
already authenticated.)
2.
The KDC replies with a TGT (ticket-granting-ticket) for Domain B. As always, one part of the
TGT is encrypted with the session key the KDC in Domain A shares with the client and the
other part is encrypted with the session key, which the KDC in Domain A shares with the
KDC in Domain B. This ticket contains a session key for the client to share with Domain B.
327
3.
The client now presents the ticket to Domain B. Because that information is encrypted with the
session key that Domain A and Domain B share, Domain B can trust the ticket as authentic
(generated by the KDC who manages the realm where the client is coming from).
4.
The KDC in Domain B issues a TGT to the client. The TGT is divided into two parts:
5.
A session key encrypted with the session key shared between the client and the KDC in
Domain B.
A session key encrypted with the file servers session key, which it shares with the KDC in
Domain B.
The client in Domain A can present the TGT to the file server in Domain B. Because the TGT is
encrypted using the session key, which the file server shares with the KDC in Domain B, the
server can accept the request.
If there are N intermediate domains between the client and the server, the process operates
virtually in the same way except that Steps 3 and 4 are repeated N-1 times.
Service Principal Name

The Service Principal Name (SPN) represents a service that is available for Kerberos
authentication. Only services listed as SPNs are available for clients to authenticate. The SPN must
be unique in any Active Directory forest. You can associate the SPN to a user account or to a
machine account. In either case, a given SPN can only be associated with one account.
The Windows resource kit contains an executable command that allows a domain administrator to
add, remove, and list the SPNs in a domain (forest):
c:\Program Files\Resource Kit>setspn switches computer-name

where computer-name is in name or domain\name format and optional switches include:
-R: Reset an SPN.
-A: Add an arbitrary SPN.
-D: Delete an arbitrary SPN.
-L: List registered SPNs.
For instance, if you have set up a new Web server and you want to use Kerberos authentication,
you need to add it as an SPN to the domain where you registered it.
328
Property
Your comments, please

Thank you for taking this BlueTouch Training Services course. Your comments on this course are
appreciated and will help Blue Coat improve future versions of this course.
Course: BCCPP
Edition: Student textbook
Version: 3.4.1
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
Send your comments via postal mail to:
Blue Coat Systems Inc.
BlueTouch Training Services
410 North Mary Avenue
Sunnyvale, California USA 94085
Or you can send comments via e-mail to:
training.books@bluecoat.com
When e-mailing, please include the course name, edition, and version as shown above.
For information on other courses offered by BlueTouch Training Services, go online to:
http://bluecoat.com/support/training
329
330
Property

BCCPP Student v341 Us WMK PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BCCPP Student v341 Us WMK PDF

Uploaded by

Copyright:

Available Formats

1[dT2^Pc2TacXUXTS

Property of Blue Touch Training Services.

BlueTouch Training Services BCCPP Course v3.4.1

Course Introduction .....................................................................................1

BlueTouch Training Services BCCPP Course v3.4.1

Chapter 18: Health Checks ..................................................................... 217

The architecture of the ProxySG.

How to use Content Policy Language and trace policy execution.

Authentication realms and how to configure them on the ProxySG.

How to use the ProxySG for forwarding and failover.

Streaming media and bandwidth management.

Applicable Software Versions

BlueTouch Training Services BCCPP Course v3.4.1

Chapter 1: System Architecture

Analyzes and processes policy.

The basic software architecture of the ProxySG.

How ProxySG hardware sizing can affect performance.

BlueTouch Training Services BCCPP Course v3.4.1

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

Chapter 1: System Architecture

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

BlueTouch Training Services BCCPP Course v3.4.1

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

Chapter 1: System Architecture

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

BlueTouch Training Services BCCPP Course v3.4.1

Error: Late condition guards early action: authenticate(MyRealm)

Chapter 1: System Architecture

Blu e Co at Sy ste ms, Inc. 2 010. All Rig ht s Reserved.

BlueTouch Training Services BCCPP Course v3.4.1

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

How rapidly new objects can be acquired and stored on disk.

Chapter 1: System Architecture

BlueTouch Training Services BCCPP Course v3.4.1

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

Chapter 1: System Architecture

New client connections are delayed.

TCP/IP sockets for all proxies stop accepting new requests.

The HTTP proxy begins to shut down idle persistent connections.

This description should be used only as a high-level guide to understanding sizing.

BlueTouch Training Services BCCPP Course v3.4.1

Chapter 2: Caching Architecture

BlueTouch Training Services BCCPP Course v3.4.1

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

Caching is useful on the Web because it improves performance considerably by speeding up

Chapter 2: Caching Architecture

BlueTouch Training Services BCCPP Course v3.4.1

HTTP Headers for Caching

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

Cache-Control directives used in HTTP requests include:

Chapter 2: Caching Architecture

Cache-Control directives used in HTTP responses include:

must-revalidate: A cache might not validate a requested object if it is set up to

proxy-revalidate: This directive is similar to must-revalidate except that it is not

BlueTouch Training Services BCCPP Course v3.4.1

HTTP Object Types

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.

Chapter 2: Caching Architecture

Blu e Co at Sy ste ms, Inc. 2 010. All Rig ht s Reserved.

BlueTouch Training Services BCCPP Course v3.4.1

Blu e Co at Sy ste ms, Inc. 2 010. All Rig ht s Reserved.

Chapter 2: Caching Architecture

Blue Coat Systems, Inc. 2010. All Ri ghts Reser ved.