BCCPP Ebook

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
1[dT2^Pc2TacXUXTS
?a^gh?a^UTbbX^]P[2^dabT
8]bcadRc^aCTgcQ^^Z
eTabX^]""
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Blue Coat Education and Training Services BCCPP Course v 3.0.3
Contact Information
Blue Coat Systems Inc.

420 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-2006 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. Blue Coat SG, Blue Coat AV, Blue Coat RA, Blue Coat WebFilter, Blue Coat Director, Blue
Coat Reporter, ProxySG, ProxyAV, CacheOS, SGOS, Spyware Interceptor, Scope are trademarks of Blue
Coat Systems, Inc. and CacheFlow, Blue Coat, Accelerating The Internet, WinProxy, AccessNow, Ositis,
Powering Internet Management, and The Ultimate Internet Sharing Solution 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.
ii Instructor Edition
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Third Party Copyright Notices
Blue Coat Systems, Inc. utilizes third party software from various sources. Portions of this software are copyrighted by their respective
owners as indicated in the copyright notices below.
The following lists the copyright notices for:
BPF
Copyright (c) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that: (1) source code distributions
retain the above copyright notice and this paragraph in its entirety, (2) distributions including binary code include the above copyright notice
and this paragraph in its entirety in the documentation or other materials provided with the distribution, and (3) all advertising materials
mentioning features or use of this software display the following acknowledgement:
This product includes software developed by the University of California, Lawrence Berkeley Laboratory and its contributors.
Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software
without specific prior written permission. THIS SOFTWARE IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE.
DES
Software DES functions written 12 Dec 1986 by Phil Karn, KA9Q; large sections adapted from the 1977 public-domain program by Jim
Gillogly.
EXPAT
Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Finjan Software
Copyright (c) 2003 Finjan Software, Inc. All rights reserved.

Flowerfire
Copyright (c) 1996-2002 Greg Ferrar

ISODE
ISODE 8.0 NOTICE
Acquisition, use, and distribution of this module and related materials are subject to the restrictions of a license agreement. Consult the
Preface in the Users Manual for the full terms of this agreement.
4BSD/ISODE SMP NOTICE
Acquisition, use, and distribution of this module and related materials are subject to the restrictions given in the file SMP-READ-ME.
UNIX is a registered trademark in the US and other countries, licensed exclusively through X/Open Company Ltd.
MD5
RSA Data Security, Inc. MD5 Message-Digest Algorithm
Copyright (c) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.
License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message-Digest
Algorithm" in all material mentioning or referencing this software or this function.
License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security,
Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing the derived work.
RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for
any particular purpose. It is provided "as is" without express or implied warranty of any kind.
THE BEER-WARE LICENSE" (Revision 42):
<phk@FreeBSD.org <mailto:phk@FreeBSD.org>> wrote this file. As long as you retain this notice you can do whatever you want with this
stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
Microsoft Windows Media Streaming
Copyright (c) 2003 Microsoft Corporation. All rights reserved.

OpenLDAP
Copyright (c) 1999-2001 The OpenLDAP Foundation, Redwood City, California, USA. All Rights Reserved. Permission to copy and
distribute verbatim copies of this document is granted.
http://www.openldap.org/software/release/license.html
The OpenLDAP Public License Version 2.7, 7 September 2001
Redistribution and use of this software and associated documentation ("Software"), with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain copyright statements and notices,
2. Redistributions in binary form must reproduce applicable copyright statements and notices, this list of conditions, and the following
disclaimer in the documentation and/or other materials provided with the distribution, and
3. Redistributions must contain a verbatim copy of this document.
Instructor Edition iii
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The OpenLDAP Foundation may revise this license from time to time. Each revision is distinguished by a version number. You may use this
Software under terms of this license revision or under the terms of any subsequent revision of the license.
THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS CONTRIBUTORS AS IS AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR
THE AUTHOR(S) OR OWNER(S) OF THE SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The names of the authors and copyright holders must not be used in advertising or otherwise to promote the sale, use or other dealing in this
Software without specific, written prior permission. Title to copyright in this Software shall at all times remain with copyright holders.
OpenLDAP is a registered trademark of the OpenLDAP Foundation.
OpenSSH
Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland. All rights reserved
This file is part of the OpenSSH software.
The licences which components of this software fall under are as follows. First, we will summarize and say that all components are under a
BSD licence, or a licence more free than that.
OpenSSH contains no GPL code.
1) As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this
software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be
called by a name other than "ssh" or "Secure Shell".
[Tatu continues]
However, I am not implying to give any licenses to any patents or copyrights held by third parties, and the software includes parts that are
not under my direct control. As far as I know, all included source code is used in accordance with the relevant license agreements and can be
used freely for any purpose (the GNU license being the most restrictive); see below for details.
[However, none of that term is relevant at this point in time. All of these restrictively licenced software components which he talks about
have been removed from OpenSSH, i.e.,
- RSA is no longer included, found in the OpenSSL library
- IDEA is no longer included, its use is deprecated
- DES is now external, in the OpenSSL library
- GMP is no longer used, and instead we call BN code from OpenSSL

- Zlib is now external, in a library
- The make-ssh-known-hosts script is no longer included

- TSS has been removed
- MD5 is now external, in the OpenSSL library
- RC4 support has been replaced with ARC4 support from OpenSSL
- Blowfish is now external, in the OpenSSL library
[The licence continues]
Note that any information and cryptographic algorithms used in this software are publicly available on the Internet and at any major
bookstore, scientific library, and patent office worldwide. More information can be found e.g. at "http://www.cs.hut.fi/crypto".
The legal status of this program is some combination of all these permissions and restrictions. Use only at your own responsibility. You will
be responsible for any legal consequences yourself; I am not making any claims whether possessing or using this is legal or not in your
country, and I am not taking any responsibility on your behalf.
NO WARRANTY
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT
PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO
EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER
PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY
TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
2) The 32-bit CRC compensation attack detector in deattack.c was contributed by CORE SDI S.A. under a BSD-style license.
Cryptographic attack detector for ssh - source code
Copyright (c) 1998 CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. Redistribution and use in source and binary forms, with or
without modification, are permitted provided that this copyright notice is retained. THIS SOFTWARE IS PROVIDED AS IS AND ANY
EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OR MISUSE OF
THIS SOFTWARE.
Ariel Futoransky <futo@core-sdi.com> <http://www.core-sdi.com>
3) ssh-keygen was contributed by David Mazieres under a BSD-style license.
Copyright 1995, 1996 by David Mazieres <dm@lcs.mit.edu>. Modification and redistribution in source and binary forms is permitted
provided that due credit is given to the author and the OpenBSD project by leaving this copyright notice intact.
4) The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto is in the public domain and distributed with the
following license:
@version 3.0 (December 2000)
Optimised ANSI C code for the Rijndael cipher (now AES)
@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
iv Instructor Edition
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>

@author Paulo Barreto <paulo.barreto@terra.com.br>
This code is hereby placed in the public domain.
THIS SOFTWARE IS PROVIDED BY THE AUTHORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
5) One component of the ssh source code is under a 3-clause BSD license, held by the University of California, since we pulled these parts
from original Berkeley code.
Copyright (c) 1983, 1990, 1992, 1993, 1995
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
6) Remaining components of the software are provided under a standard 2-term BSD licence with the following names as copyright holders:
Markus Friedl
Theo de Raadt
Niels Provos
Dug Song
Aaron Campbell
Damien Miller
Kevin Steves
Daniel Kouril
Wesley Griffin
Per Allansson
Nils Nordman
Simon Wilkinson
met:
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
OpenSSL
Copyright (c) 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.
http://www.openssl.org/about/
http://www.openssl.org/about/
OpenSSL is based on the excellent SSLeay library developed by Eric A. Young <mailto:eay@cryptsoft.com> and Tim J. Hudson
<mailto:tjh@cryptsoft.com>.
The OpenSSL toolkit is licensed under a Apache-style license which basically means that you are free to get and use it for commercial and
non-commercial purposes.
This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to conform with
Netscapes SSL.
This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following conditions
apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included
with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com).
Copyright remains Eric Youngs, and as such any Copyright notices in the code are not to be removed. If this package is used in a product,
Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program
startup or in documentation (online or textual) provided with the package.
met:
Instructor Edition v
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes
cryptographic software written by Eric Young (eay@cryptsoft.com)" The word cryptographic can be left out if the routines from the library
being used are not cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an
acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot
simply be copied and put under another distribution license [including the GNU Public License.]
Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved.
met:
3. All advertising materials mentioning features or use of this software must display the following acknowledgment:
"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software
without prior written permission. For written permission, please contact openssl-core@openssl.org.
5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written
permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the
OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)"
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
DAMAGE.
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim
Hudson (tjh@cryptsoft.com).
PCRE
Copyright (c) 1997-2001 University of Cambridge
University of Cambridge Computing Service, Cambridge, England. Phone: +44 1223 334714.
Written by: Philip Hazel <ph10@cam.ac.uk>
Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the
following restrictions:
1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
2. Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and
copyright by the University of Cambridge, England.
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
PHAOS SSLava and SSLavaThin
Copyright (c) 1996-2003 Phaos Technology Corporation. All Rights Reserved.
The software contains commercially valuable proprietary products of Phaos which have been secretly developed by Phaos, the design and
development of which have involved expenditure of substantial amounts of money and the use of skilled development experts over
substantial periods of time. The software and any portions or copies thereof shall at all times remain the property of Phaos.
PHAOS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTY OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, REGARDING THE SOFTWARE, OR ITS USE AND OPERATION
ALONE OR IN COMBINATION WITH ANY OTHER SOFTWARE.
PHAOS SHALL NOT BE LIABLE TO THE OTHER OR ANY OTHER PERSON CLAIMING DAMAGES AS A RESULT OF THE USE OF
ANY PRODUCT OR SOFTWARE FOR ANY DAMAGES WHATSOEVER. IN NO EVENT WILL PHAOS BE LIABLE FOR SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF ADVISED OF THE POSSIBLITY OF SUCH DAMAGES.
RealSystem
The RealNetworks RealProxy Server is included under license from RealNetworks, Inc. Copyright 1996-1999, RealNetworks, Inc. All
rights reserved.
SNMP
Copyright (C) 1992-2001 by SNMP Research, Incorporated.
This software is furnished under a license and may be used and copied only in accordance with the terms of such license and with the
inclusion of the above copyright notice. This software or any other copies thereof may not be provided or otherwise made available to any
other person. No title to and ownership of the software is hereby transferred. The information in this software is subject to change without
notice and should not be construed as a commitment by SNMP Research, Incorporated.
vi Instructor Edition
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Restricted Rights Legend:
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical
Data and Computer Software clause at DFARS 252.227-7013; subparagraphs (c)(4) and (d) of the Commercial Computer Software-Restricted
Rights Clause, FAR 52.227-19; and in similar clauses in the NASA FAR Supplement and other corresponding governmental regulations.
PROPRIETARY NOTICE
This software is an unpublished work subject to a confidentiality agreement and is protected by copyright and trade secret law.
Unauthorized copying, redistribution or other use of this work is prohibited. The above notice of copyright on this source code product does
not indicate any actual or intended publication of such source code.
STLport
Copyright (c) 1999, 2000 Boris Fomitchev
This material is provided "as is", with absolutely no warranty expressed or implied. Any use is at your own risk.
Permission to use or copy this software for any purpose is hereby granted without fee, provided the above notices are retained on all copies.
Permission to modify the code and to distribute modified code is granted, provided the above notices are retained, and a notice that the code
was modified is included with the above copyright notice.
The code has been modified.
Copyright (c) 1994 Hewlett-Packard Company
Copyright (c) 1996-1999 Silicon Graphics Computer Systems, Inc.

Copyright (c) 1997 Moscow Center for SPARC Technology
Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in
supporting documentation. Hewlett-Packard Company makes no representations about the suitability of this software for any purpose. It is
provided "as is" without express or implied warranty.
supporting documentation. Silicon Graphics makes no representations about the suitability of this software for any purpose. It is provided
"as is" without express or implied warranty.
supporting documentation. Moscow Center for SPARC Technology makes no representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty.
SmartFilter
Copyright (c) 2003 Secure Computing Corporation. All rights reserved.

SurfControl
Copyright (c) 2003 SurfControl, Inc. All rights reserved.

Symantec AntiVirus Scan Engine
Copyright (c) 2003 Symantec Corporation. All rights reserved.

TCPIP
Some of the files in this project were derived from the 4.X BSD (Berkeley Software Distribution) source.
Their copyright header follows:
Copyright (c) 1982, 1986, 1988, 1990, 1993, 1994, 1995
met:
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:
This product includes software developed by the University of California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
DAMAGE.
Trend Micro
Copyright (c) 1989-2003 Trend Micro, Inc. All rights reserved.

zlib
Copyright (c) 2003 by the Open Source Initiative
This software is provided as-is, without any express or implied warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
ICU License - ICU 1.8.1 and later COPYRIGHT AND PERMISSION NOTICE Copyright (c) 1995-2003 International Business Machines
Corporation and others All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do
so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above
copyright notice(s) and this permission notice appear in supporting documentation. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT
SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL
Instructor Edition vii
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Except as contained in this notice, the name of a copyright
holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written
authorization of the copyright holder.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document
itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the
Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
viii Instructor Edition
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Table of Contents
Chapter 1: System Architecture .................................................................. 1

Chapter 2: Advanced Services TCP Tunneling .................................... 19
Chapter 3: Content Policy Language ........................................................ 39

Chapter 4: Regular Expressions ............................................................... 73
Chapter 5: Managing Downloads and Apparent Data Types .................... 91

Chapter 6: Policy Tracing ........................................................................ 105
Chapter 7: HTTP Details ......................................................................... 113
Chapter 8: Using Authentication In Transparent Proxy Mode ................. 127
Chapter 9: Understanding Kerberos Authentication (Optional) ............... 143

Chapter 10: Using Kerberos Authentication ............................................ 157
Chapter 11: Substitution Realm .............................................................. 169
Chapter 12: Windows SSO ..................................................................... 181

Chapter 13: Advanced Authentication .................................................... 189
Chapter 14: Guest Authentication ........................................................... 209

Chapter 15: SSL Proxy ........................................................................... 225
Chapter 16: Bandwidth Management ..................................................... 239

Chapter 17: Managing Streaming Media ................................................ 259
Chapter 18: Forwarding .......................................................................... 273

Chapter 19: Reverse Proxy Implementation ...................................... 285
Instructor Edition ix
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 20: Two-Way URL Rewrite ........................................................295
Chapter 21: Failover ................................................................................307

Chapter 22: Access Logging Advanced Topics ..................................319
Chapter 23: Web Cache Communication Protocol (WCCP) ..................337

Chapter 24: Health Checks .....................................................................349
Chapter 25: ProxySG Security ................................................................361
Chapter 26: Introduction to Blue Coat Director ........................................365
Chapter 27: Introduction to Blue Coat ProxyRA ......................................375
Appendix: Understanding Digital Certificates ..........................................395

Appendix B: Blue Coat Authentication and Authorization Agent .............403
x Instructor Edition
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 1: System Architecture
Estimated Lesson Time: ProxySG 45 minutes
Instructors Note: This chapter discusses, at a very high level, the internal system
architecture of the Blue Coat SG. You must point out to the students that this chapter does
not give all the details. Deliver the message that the most intricate details of internal
architecture cannot be made public for obvious reasons. However, this chapter is an accurate
description of how ProxySG processes transactions and manages cached content.
ProxySG architecture 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.
This chapter is intended to help you understand how the ProxySG processes information,
validates policy statements, and decides how to manage cacheable content. In particular, you will
learn why certain policies must be ordered in a certain way, when some policy statements are
evaluated, and why the ProxySG is the most efficient and secure caching appliance on the market.
A section is also dedicated to discussing how the ProxySG can enhance the performance of Web
response time when it is deployed in either forward proxy mode or reverse proxy mode.
This chapter also offers some tips and tricks that are helpful when you use older-generation
firewalls or routers, which may react in an unpredictable manner to pipelining.
Finally, the topics covered in this section allow you to get a much better understanding of ProxySG
policy tracing results; policy tracing, which is discussed later on in this book, is an essential
troubleshooting tool.
The SGOS contains no general-purpose code, and does not re-use code from other systems. The
OS 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. The following pages focus on providing a high-level overview of core SGOS
technologies specifically those designed to improve the Internet user experience.
Instructor Edition 1
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
System Architecture
Software Workers
Policy Checkpoints
Caching Techniques
Pipelining Requests
6OLGH(OHPHQWVRIV\VWHPDUFKLWHFWXUH
Instructors Note: This slide summarizes the content of the section. Spend a little bit of time
describing what each bullet point represents. Mention that each topic is detailed in the
remainder of the presentation.
This chapter discusses some of the key components of ProxySG internal structure. 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 if the transaction request must be fulfilled from cache, if data must
be obtained from the Internet, or if the request should be denied. The ProxySG uses a series of very
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.
The combination and integration of the four elements described above give you a pretty solid
understanding of the internal system architecture for ProxySG.
2 Instructor Edition
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Software Workers
Client Worker (CW) Maintains HTTP sessions

between the Blue Coat SG and clients
Server Worker (SW) Maintains HTTP sessions

between the Blue Coat SG and OCS
Retrieval Worker (RW) Keeps the contents of
the cache fresh
Specialized Worker Handles a specific protocol,

like IM, streaming, etc.
6OLGH0DLQVRIWZDUHZRUNHUV
Instructors Note: The main workers are listed in this slide. Tell your students that there are
many other workers used by the ProxySG. You can mention the HTTP worker because it is
useful to explain the concept of HTTP handoff later in this book. The HTTP workers (client and
server) are workers dedicated to processing HTTP requests and also are used to manage IM
traffic (when the proper license is installed). With the support of new protocols, the SGOS may
introduce new and dedicated workers, which understand that particular protocol.
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 the SGOS. The functionalities covered by each worker and their interconnections may
also change.
Full discussion of all the workers is beyond the scope of this course.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Software Workers
6OLGH6RIWZDUHZRUNHUVPRGHO
Instructors Note: You need to discuss this slide in detail. This is the prelude to
understanding the policy checkpoint, which is key to understanding how policies are
interpreted and applied. Point out that each client causes the ProxySG to initiate one or more
client workers. Each user agent can cause the ProxySG to initiate multiple client workers, one
per connection. The diagram above shows the primary workers used by the HTTP proxy. Each
upper lever (Layer 7) protocol has a corresponding set of workers, the exact details of which
depend on the protocol and the control and visibility features offered. From release to release,
new workers are introduced as required for in-depth inspection and control of new protocols.
The diagram in Slide 1-3 shows the main workers that the SGOS implements to manage HTTP
transactions. You need to read the diagram from the left to the right.
When a client makes an HTTP connection to the ProxySG, the 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 OS 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 if 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 if 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 the OS 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Performance
Feature
200-0
400-1
800-1
8000-1
8000-4
Memory
256 MB
512 MB
1 GB
1 GB
4 GB
HDD
40 GB
2x40 GB
73 GB
2x73 GB
8x73 GB
Object
Limit
N/A
2,290,000
4,518,000
4,576,000
18,302,000
6OLGH3URGXFWSHUIRUPDQFH
Instructors Note: This slide covers some of the key performance parameters of the ProxySG
family of products. This list is not all-inclusive; you can look up more details on the Blue Coat
corporate Web site. The idea is to list some of the hardware from the lowest (ProxySG 200-0)
to the highest (ProxySG 8000-4). These figures refer to older hardware; this is done
intentionally.
Important: The numbers listed in the row HTTP Clients represent the total number of client
HTTP workers. The numbers in the row Object Limit refer to the maximum number of RAM
cache objects; each variant of an item is an additional object.
The table displayed in the slide above should be used as a reference guide to size the hardware
and to better understand under which conditions a ProxySG may 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) and the maximum number of concurrent HTTP
sessions that can be managed concurrently.
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 like 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 like 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.
7KHFRQWHQWRIWKHVOLGHLVDFFXUDWHDVRI0D\VXEMHFWWRFKDQJHZLWKRXWQRWLFH
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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. As an example, far from being
accurate, you can compare the RAM hash table with the FAT table on Windows-based systems;
however, the ProxySG does not have a FAT or NTFS file system but an object store (see Slide 1-13).
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 (TM), 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 percent. The memory pressure state is abandoned after committed RAM drops below
90 percent.
During memory pressure situations:
New client connections will be delayed.
TCP/IP sockets for all proxies stop accepting new requests.
HTTP proxy begins to shut down idle persistent connections.
Management-related services (SSH, Telnet, HTTP-Console, and HTTPS-GUI) do not change

behavior.
The HTTP proxy will also adhere to a maximum active client connections count that is set per
platform. When max-active clients is reached, the idle persistent connections also begin to be shut
down. The maximum active HTTP client count supersedes TM.
Note:
This textbook 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 SE.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Late condition [name]' guards early action:
[name]'
6OLGH3ROLF\SURFHVVLQJIORZ
Instructors Note: The easiest way for you to explain the concept of policy checkpoints is with
an example of improper policy that generates the {Late condition [name]' guards early action:
[name]' } message. For instance, you can use the example:
response.header.Content-type=text/html forward(
http://www.somesite.com )
The determination of content type is done at the server in checkpoint, while the forward
decision is done at the server out checkpoint.
Additional Note: In this section you may start introducing some concepts about CPL. This
section is pivotal to a better understanding of CPL. However, you may want to carry on most of
the discussion of the text on this page with the next slide projected on the screen.
The evaluation of the running policy is performed at various points within 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 wherever possible, the policy writer is shielded
from the variations among protocols. This is done by making the systems timing requirements
accommodate all 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 rules 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
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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, here is a rule that 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 and the resulting message at compile time:
group=xyz authenticate(MyRealm)
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Checkpoints
6OLGH3ROLF\FKHFNSRLQWV
Instructors Note: You have already discussed most of this slide with the material detailed for
Slide 1-5. In this section you can focus on the fact that many checkpoints are not detailed
here. For instance, there are at least three cache-related checkpoints: Cache Query (CQ)
occurs when the cache is about to be queried to determine the availability of the requested
object; Cache Hit (CH) occurs after a response has been obtained from the cache; and Cache
Charge (CC) occurs after a response has been received from the origin server and is
cacheable. That response is about to be placed into the cache when this checkpoint is
evaluated.
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 will be 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. Here the result of response virus scanning is available.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Caching Techniques
Adaptive Refresh
Adapt to user patterns

Estimate staleness probability
Cost-based Deletion
Link speed analysis
Popularity Contest
6OLGH&DFKLQJWHFKQLTXHV
Instructors Note: You need to emphasize that the ProxySG is a security appliance; however
at its core it retains all the advanced caching enhancements that made CacheFlow the market
leader in the caching market. Make sure to point out that caching is now a minimal part of the
feature set offered by the proxy. However the performance gain that caching adds to your
network is significant, and it can be very visible in the branch-core deployment model.
The SGOS automatically measures and reports on the freshness of content it delivers to end users.
This reporting functionality is based on the Web object properties that are tracked by the Adaptive
Refresh algorithms. The measurement function begins by tracking the number of times an object
in the proxy appliances store is delivered to an end user since the last time its freshness was
checked. These facts are then contrasted with the results of the Adaptive Refresh activity. When a
refresh check occurs for that object, various outcomes can be calculated:
If the object has not changed on the server, the previous deliveries of that object are recorded
as having been fresh.
If the object has changed on the server, the OS calculates the percentage of previous deliveries
of the object that were fresh and whether or not any were delivered stale with respect to the
time the object changed on the origin server.
Through this reporting mechanism, network administrators can be confident that the content their
users are receiving is in fact the content that existed on the Web at the time of the request.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Asynchronous Adaptive Refresh
6OLGH$V\QFKURQRXV$GDSWLYH5HIUHVK
Instructors Note: This page discusses the patent-pending Asynchronous Adaptive Refresh
algorithm. It selectively refreshes Web objects based on their need to be refreshed.
Because content on Web servers changes, a proxy appliance must keep its cache of content up to
date. Traditionally, for a proxy to deliver fresh content to the end user, it must send a refresh
check to the origin server. However, to serve the content quickly, it must not wait until a user
requests the content before it performs this refreshing activity. If the refresh checks are performed
only at the moment the user requests the content, the user will endure the round-trip delays that
cause the Internet to be slow in the first place and Web page response time will not be
substantially improved.
The only method for delivering Web pages quickly and accurately is for the refreshing activity to
be uncoupled from the actual end-user requests. The SGOS performs this activity with another
latency-attacking algorithm called Asynchronous Adaptive Refresh. This patent-pending
algorithm selectively refreshes Web objects based upon their need to be refreshed. This refreshing
activity occurs asynchronous to actual user requests so as to not impact response times.
Selecting what objects to refresh and when requires an understanding of object behaviors. Web
objects change at different rates. Some change frequently, some rarely, and many have change
rates in between. The histogram shown on the next page is derived from data extracted from Blue
Coat proxy appliances in use around the world. (The histogram does not represent an absolute
model of how frequently objects change; it simply highlights the change rates that were observed
during the time of the analysis.)
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Figure 1-1: Object Change Rate
The Asynchronous Adaptive Refresh algorithm integral to the SGOS is the only technology in the
industry that develops a model of change for every Web object in its store. It also develops a
model of use based upon that object's history of being requested by users. It then combines
these two pieces of information to determine the refresh pattern appropriate to that object. (The
values derived by the algorithms also adapt to changes produced by these models over time.)
Using the Asynchronous Adaptive Refresh algorithm, the ProxySG automatically performs
freshness checks with the origin server to ensure that old content is expunged and replaced with
fresh content. For example, if the objects within the www.nbcnews.com home page are popular
among the population of users that are accessing the proxy, the OS will update the objects that
change. (For instance, the NBC logo object). This ensures that current content will be delivered
to end users quickly.
While Object Pipelining improves response times for first-time Web page requests, Asynchronous
Adaptive Refresh significantly speeds subsequent requests by removing the latency involved in
refreshing the objects.
Only through the latency-attacking algorithms pioneered by Blue Coat Systems can the Internet be
accelerated for first-time and N-time requests for content. The SGOS, through its ability to deliver
content quickly and accurately, is the foundation of the industry's most effective secure proxy
solution.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Cost Based Deletion
6OLGH&RVWEDVHGGHOHWLRQ
Instructors Note: Make it clear to that all of the different caching and deletion techniques are
used at the same time. Actual details are proprietary to Blue Coat. Reinforce the concept that
cost-based = time to download the object.
Cost-Based Deletion is a powerful algorithm used by ProxySG to determine which objects to

delete first where there is no more room in the object store. Because a caches storage is full all the
time, to make room for new incoming objects some objects must be deleted.
Cost-Based Deletion chooses to delete objects based upon their cost to end-user response time in
combination with the objects relative popularity. Basically, the average time it took to retrieve
each chunk of an object is examined. The time depends on the link and is averaged over all
retrievals. If the system has to remove an object, it makes more sense to remove one that is both
inexpensive to re-download and unpopular. (See the next page for more about popularity.)
If an object is deleted and is requested again, the request is fulfilled relatively quickly.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Popularity Contest
6OLGH3RSXODULW\FRQWHVW
Instructors Note: This is not a concept unique to Blue Coat; however, not all caching
engines use an actual algorithm as sophisticated as the one implemented in the ProxySG.
Again, this is just one of the many factors that ProxySG evaluates before deciding which
object to delete.
Typically, there two main ways of handling and swapping data in a queue: FIFO (first-in, first-out)
or LIFO (last-in, first-out). While FIFO seems a reasonable approach to handling cached objects, it
fails to recognize the most important characteristic associated with the objects in the data store. An
object that has been requested only once in the last few cycles is less likely to be cached than an
object requested more frequently. On the other hand, an object that has been requested several
times should be cached because the bandwidth saving is more significant if the object is served
from the local cache.
The image in Slide 1-10 shows how the objects are sorted in the queue relative to their probability
of being deleted next. The stack on the left represents the ProxySG sorting algorithm and the one
on the right represents a generic FIFO approach. When a new object arrives and needs to be added
to the stack on the left, the least popular object is replaced; when the same object is added to a
regular stack, the oldest object in the stack in deleted, regardless of its popularity.
You should note that the popularity is not strictly based on the number of requests. The ProxySG
uses the concept of relative popularity. This concept allows the CA to prefer to refresh a
relatively popular but costly object over a relatively unpopular but inexpensive object.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
RAM Object Cache
6OLGH5$0REMHFWFDFKH
Instructors Note: Do not spend too much time on this slide because the details are not
relevant to this class. The key is to explain that all of the objects served by the ProxySG to the
client appear as if they are coming from the cache. Objects are stored in RAM first, served to
the client, and swapped into the object store as needed. Point out that the way the ProxySG is
designed, there is no real marked separation between data on disk and data in RAM. The
concept of paged memory, applicable to the generic purpose OS, is not relevant to the SGOS.
The ProxySG manages the data in the object store (see next page) and objects in RAM as the same
type of entity. Every object served to the client appears as if it comes from the cache, even if it is
retrieved from the OCS. The process of serving data to the client and feeding the object store for
cached data is virtually transparent.
Objects are retrieved from the OCS and put into RAM; they will be placed in the object store based
on considerations similar to the ones used for caching. For instance, if an object is very popular it
may remain as a RAM object for a while, compared to a less popular object.
Very simply, the object store is a two-level cache, consisting of a first level of RAM cache for objects
being accessed currently and for the most popular objects. The second cache level is on the disk.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pipeline Retrieval
A client uses typically two threads per request

The Blue Coat SG can use large number of
server workers to pre-fetch content
6OLGH3LSHOLQHUHWULHYDO
Instructors Note: Emphasize the importance of pipeline retrieval. This is critical not just for
forward proxy but also for reverse proxy deployments. Do not fail to mention that at times a
firewall may not like the high number of concurrent connections that ProxySG is trying to
establish with the outside world. You can either limit the amount of pipelining performed by the
proxy (reduced performance gain) or disable the relevant alarms and policies on your firewall
and routers.
When a browser requests content, dozens of round trips must take place between the browser and
the distant Web server. This is because a Web page is typically composed of dozens of objects, and
for each object there typically must first be a TCP session setup followed by an HTTP GET request.
This serial retrieval of objects presents a major delay for the end user. With a ProxySG deployed, a
large portion of this delay is eliminated. The client connection terminates at the ProxySG, which
leverages the latency-attacking algorithms provided by the SGOS. One of these algorithms is
called Object Pipelining. Instead of retrieving objects serially, this patent-pending algorithm opens
as many simultaneous TCP connections as the origin server will allow and then retrieves objects in
parallel. The objects are then delivered from the appliance straight to the users desktop as fast as
the browser can request them.
As a result of Object Pipelining, Blue Coat typically accelerates first-time Web page retrievals by 50
percent. The NSS Group, in a published technical evaluation of Blue Coat products, has confirmed
the effects of Object Pipelining: The most surprising figures are the second set, taken during
proxy cache initialization. At this point, the proxy cache was completely empty and you would
thus expect to see no improvement over the non-cached set of figures. However, the fact that
there is a clear performance gain (retrieval times with the cache are less than half of those where
no cache is used) proves that the object pipelining technique employed by Blue Coat provides
significant benefits.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Storage Subsystem
6OLGH6WRUDJHVXEV\VWHP
Instructors Note: Use this slide to make very clear, one more time, that the SGOS is not a
UNIX-like OS. It is a custom OS, designed to store cached content. The performance of the
Blue Coat caching mechanism cannot be matched by devices using a regular file system like
NTFS or EFS. Regular file systems are designed to retrieve files. The SGOS data store is
designed to retrieve Web objects. Discuss how the disk is organized in 8KB blocks and how
the data is stored in the same pattern as the URL. Make sure to explain the fundamental
difference between a file system and an object store.
The method of storing objects on disk is critical for achieving both high performance and high
scalability. It determines (1) how quickly a cached object can be accessed when a client requests it,
(2) how rapidly new objects can be acquired and stored on disk, and (3) 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 OS. 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 proxy appliance 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 OS 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 hot added to an existing
proxy to increase its storage capacity.
You should also consider the following statements, which describe the difference between a file
system and an object store.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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's reasonably efficient to access all 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 the intermediate directories every time.
Object stores store things differently, indexing all files 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, no matter how deep in the directory structure it is. 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 you explicitly delete them. 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 will fill all available disk space. Instead of requiring the administrator to
manually clean up 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 will be most useful based on past access patterns.
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 2: Advanced Services TCP Tunneling
Estimated Lesson Time: 15 minutes
Instructors Note: The goal of this chapter is to formalize what TCP tunneling is and how you
should use it. You need to emphasize the edge-core deployment scenario once again. TCP
tunneling, which already existed in several previous releases, is now more effective because it
can be combined with byte caching and gzip compression to reduce bandwidth and increase
performance. It is useful for detecting peer-to-peer connections going over open ports on the
firewall.
Additional Note: Point out to the students that they should have a TCP tunnel proxy for each
port open on the firewall and route all traffic to the proxy (transparently or explicitly) in order to
achieve the most effective P2P control-and-prevention policy. If you are in a transparent proxy
deployment scenario, then you can set the default proxy service to intercept without the need
to create many different services for each used port on the firewall.
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. The two
available options are to forward it to the next hop, or to drop it. You can configure ProxySG to
perform either action, depending on deployment and configuration options that you select.
Every time ProxySG decides to process a packet, which means apply policies if necessary, it needs
to know how to handle it. In particular the device needs to know which layer 7 protocol that
packet contains. You can associate each layer 7 protocol to a foreign language. When the ProxySG
receives the packet, it needs to know ahead of time which interpreter is attempting to read the
packet in question. Currently ProxySG supports (or you can say understands) a number of layer 7
protocols, including but not limited to: HTTP, HTTPS, FTP, CIFS, RPC, Streaming, IM, P2P, and
others.
The TCP Tunnel service, is a generic interpreter for TCP packets, which you can use to process
traffic which does not fall in the list of protocols known to ProxySG. For instance, if you have a
custom application, using a proprietary or non-standard layer 7 protocol, you can still proxy that
application through ProxySG using the TCP Tunnel service. You can compare this service 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. This service works in the exact same
way; while the information at lower layers (in particular data link, network, and transport) may be
changed, the application level information remains untouched. Later in the chapter, you will
discover how ProxySG has some built-in detection capabilities, which enable the device to
recognize selected traffic, even when passing through the ProxySG on a TCP port managed with a
TCP Tunnel service.
The Blue Coat SG supports both explicit and transparent TCP tunneling. You may choose
either method depending on your needs. Explicit TCP tunneling allows connections to one of the
ProxySG's IP addresses. 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.
Note:
The TCP-Tunnel service does not support content filtering with Websense offbox or
ICAP.
If you want to create a transparent TCP tunneling protocol, you can do so from either the CLI 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Important: If you created a transparent TCP-Tunnel service, you have completed the
procedure. However, if you created an explicit TCP-Tunnel service, you must
configure a forwarding destination port.
In essence, if you connect to the proxy on a TCP tunnel port in explicit mode, you need to give the
proxy instructions on where to route the traffic next. Since, in general, the ProxySG cannot
interpret the protocol stream, when the connection is terminated in explicit mode, you need to
create a forwarding rule to specify where the traffic has to be sent.
On the other hand, when you connect to the ProxySG on a TCP tunnel port in transparent mode,
the proxy knows where to send the traffic next. As you have learned in this class, the destination
IP address in a transparent proxy request is the one of the target OCS (Origin Content Server);
therefore, a forwarding rule is not required. ProxySG simply passes the protocol level information
to the machine with the IP address specified in the packet received from the client.
The default proxy service (which listens on all ports not assigned to other services), uses the
TCP-Tunnel proxy. The default proxy service has only one listener; its action can be set to bypass
or intercept. No new listeners can be added to the default proxy service, and the default listener
and service cannot be deleted.
Important: The default proxy service can be used only when the ProxySG acts as a bridge or
as a router (transparent proxy deployment).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Explicit vs. Transparent Proxy
6OLGH'HSOR\PHQWRSWLRQV
Instructors Note: At this point most of your students should be very familiar with the
differences between an explicit and a transparent proxy deployment environment. However,
you want to discuss this slide in details one more time. There are few scenarios where you
need to use TCP Tunnel service in explicit proxy mode; in any case, this slide helps you
explain clearly why you need to have a forwarding rule when you are in explicit proxy
scenarios (the destination IP address in the clients request is the one of the ProxySG and the
protocol, which may contain information about the final OCS, may be unreadable to the proxy).
Similarly you can use this slide to explain why you do not need a forwarding rule in a
transparent proxy scenario (the destination IP address in the clients request is the IP address
of the final OCS).
It is important to note the differences between the two proxy deployment methods.
Explicit Proxy
The ProxySG cannot forward traffic, when operating in explicit proxy mode, 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 the ProxySG on port 8781, where, by default there are no services running, you
will 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 the
packets that have a destination TCP port that does not match any of the services running on the
proxy will be forwarded to the next hop as specified in the packet or frame1. Another point to note
is that if you have set the Default Service to Intercept, then all the traffic will be optimized and sent
to the next hop in the application delivery network or to its final destination.
1. Routing mode requires that you have Enable IP forwarding checked (active).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Transparent Proxy - Overview
6OLGH3URFHVVLQJWUDIILFLQWUDQVSDUHQWSUR[\PRGH
Instructors Note: Use this slide to remind students that in bridging or routing mode, the
ProxySG can deliver any packet but still can process only the traffic whose destination TCP
port matches one of the services running on the ProxySG. This slide shows a proxy with three
services managing 5 ports (80, 8080, 443, 22, and 3596). If the traffic received by the proxy
matches any of these five ports, it will be processed and policies may be applied. All other
traffic will be simply forwarded as-is or rejected.
Point out that in this slide the ProxySG does not have the Defaul TCP Tunnel service set to
intercept.
In transparent proxy mode, the ProxySG can operate as a Layer 2 switch (bridge) or a Layer 3
switch (router). In this deployment scenario, the ProxySG must be able to deliver and route any
kind of traffic (UDP, TCP, NetBIOS, unicast, multicast, broadcast, etc.). Nevertheless, the ProxySG
can only terminate and process those transactions in which the destination TCP port matches one
of the services running.
For instance, if there is a TCP connection on port N and the ProxySG has a TCP tunnel enabled on
port N, and a service is enabled, the action Intercept is selected, then the connection is terminated,
the traffic processed and then sent forward to its original destination (if the traffic is permitted).
If there are no services on the ProxySG listening for connections on port N, the default TCP tunnel
is set to bypass, and the proxy is in bridging mode (or acting as a router, with Enable IP forwarding
turned on), traffic is simply forwarded to the next hop as determined by the destination IP address
and MAC address.
However if the default TCP tunnel service is enabled, it is considered a service match and it will
process the traffic.
Important: Note by default, the TCP Tunnel service is set to bypass.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
TCP Tunnel - Details
6OLGH7&37XQQHOGHWDLOV
Instructors Note: Before getting into the details for this slide, you need to go over one more
time the definition of transparent and explicit proxy. If the students clearly understand it, then
they also naturally understand why you need a forwarding rule for the traffic which arrives
explicitly to the proxy and it is part of an unknown protocol. After you discuss Slide 2-5, come
back to this slide and ask: Do you still need to have a forwarding policy if the traffic on port
3128 is actually HTTP traffic ?.
Answer: If you have protocol detection enabled, you do not need the forwarding rule, as the
final destination IP address can be read in the URL (or at least in the host header).
In the slide above you have two different connections to the proxy; one is over explicit proxy and
the other one is over transparent proxy. A TCP tunnel service intercepts both connections.
The explicit proxy connection on TCP port 31282 contains a generic protocol, which ProxySG does
not recognize. Since the connection is sent over explicit proxy, ProxySG cannot determine the
destination of the connection. The destination IP address in the client request is the IP address of
the ProxySG. The only way the proxy can deliver the packet to the intended OCS is by using a
forwarding rule. You need to create a forwarding host and a forwarding rule to instruct ProxySG
where to send the traffic, which is explicitly proxied to port 3128.
The transparent connection on TCP port 25 contains most likely SMTP traffic. ProxySG does not
handle this protocol in any specific manner; however it is easy to determine the location of the
actual OCS. The destination IP address in the client request is the IP address of the final OCS, since
the connection is a transparent proxy connection.
ProxySG can open a connection with the machine located at that IP address and starts transmitting
the TCP payload byte-by-byte; it is not necessary for ProxySG to understand the content of this
data.
On TCP tunnel ports, ProxySG is always on the lookout for possible peer-to-peer activity; this
detection is done automatically, for added security. If you have a policy to control P2P traffic, the
policy is executed only when the P2P protocol detection is enabled .
2. TCP port 3128 is commonly used by squid clients. However, in this example the traffic is not necessarily
HTTP.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Early Intercept
6OLGH(DUO\LQWHUFHSWRSWLRQ
Instructors Note: In previous releases of SGOS, early intercept was the only option that
ProxySG supported. The option to have delayed intercept (by turning off early intercept)
allows ProxySG to improve the transparency of the proxy. The default TCP Tunnel service that
captures all TCP ports needs to be able to correctly report back to the client which server ports
return an immediate TCP RST (connection refused) and which returns no response at all
(connection timed out). If early intercept was the only option, then all of these cases would
look to the client like the connection was successful, but then shortly after that the client
would suddenly see the connection drop (with a TCP RST) with no explanation. Clients
(excluding HTTP clients) may not handle this scenario well.
The early intercept feature controls whether the proxy 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 may 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 it takes 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 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 like 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 proxy responds to the
client. In case the server is not available (not responding), the client is not able to complete the
three-way TCP handshake. The advantage of not enabling early intercept is that ProxySG can
properly reflect back a connection refused or connection timed out error from a server back to the
client, since ProxySG has not yet actually responded to the clients connection request (TCP SYN).
Note:
When you enable the Detect Protocol option, Early Intercept is automatically enabled.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Protocol Detection
6OLGH3URWRFRO'HWHFWLRQ
Instructors Note: Protocol detection is a tricky topic. Your goal is to clearly explain the
difference between protocol detection and protocol handoff; particularly clarify when one
requires the other. In particular, protocol detection inside a TCP Tunnel, HTTP CONNECT
tunnel, or SOCKS CONNECT tunnel can also trigger handoffs to HTTP, SSL, or Endpoint
Mapper. Protocol detection can also be used to identify P2P traffic, though that doesnt exactly
trigger a handoff in the normal sense.
The illustration above discusses a scenario very similar to the one in Slide 2-3. The major
difference with the previous slide is that now the ProxySG has the option detect protocol enabled.
Traffic on port 3128 is often coming from a client attempting to connect over HTTP proxy with a
machine running Squid proxy. Assuming this is the case, when the traffic over TCP port 3128
arrives to the ProxySG, the proxy immediately identifies the traffic as HTTP and begins
performing HTTP processing on the request. Since the traffic has been recognized as HTTP, all
HTTP specific triggers and actions can be used in the policy.
As long as there is a service that intercepts a connection, the connection goes through policy
processing and policies apply. However if the protocol is unknown, then only generic policies
apply. On the contrary, when the ProxySG can correct detect the protocol, additional policies
specific to that protocol can be applied to the connection.
The ProxySGs protocol detection can also look for other specific P2P protocols that masquerade as
plain requests in HTTP. With this capability, the ProxySG can classify the traffic as BitTorrent,
Fast track, or Gnutella. This is useful when you want to detect traffic that masquerades as an
HTTP traffic.
The ProxySG performs protocol detection on the clients request and not on the servers response;
this is an important difference, as certain protocols cannot be detected. For instance, HTTP can be
easily detected, as the client issues an HTTP request immediately after the three-way TCP
handshake. Other protocols, where the server speaks first, cannot be detected. For instance, in
SMTP, after the client completes the three-way handshake, it will not send any command before
receiving the prompt from the server. The ProxySG, when receiving traffic like SMTP, cannot
detect protocol, as it is waiting for the client to take some actions. When a maximum time-out time
lapses, the ProxySG process the connection as unknown protocol.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The ProxySG attempts to make the decision about what protocol is being used before deciding
which server to connect to, as it might make different policy decisions about what forwarding host
to use or what URL rewrite to apply or various other similar actions based on the client protocol.
In order to perform protocol detection, the ProxySG reads the initial bytes of the client request; this
can be achieved only by allowing the clients connection request to complete. Therefore, enabling
protocol detection also enables early intercept to allow the ProxySG to read the client request bytes
before connecting to the remote server.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Protocol Handoff
6OLGH3URWRFROKDQGRII
Instructors Note: Protocol handoff is often a tricky subject. Spend time on these concepts
and discuss the licensing details for IM and streaming protocols when protocol handoff is
enabled. (In essence, you need to have IM or streaming licenses if you want to create policies
for these protocols and to be able to use the handoff functionality.) For IM and streaming,
explain clearly that the ProxySG can process the traffic correctly only if such traffic is proxied
over HTTP; if you try to send native streaming or IM traffic over an HTTP port, the traffic will
not be allowed because it is not recognized as HTTP-compliant.
Protocol Handoff is a term used for a number of different cases where one protocol worker hands
a request or a connection off to another protocol worker. Some of these are triggered by protocol
detection, but a large number of them are not. All of the following involve handoffs without
involving protocol detection:
SOCKS acceleration by port number of HTTP or IM
SSL Forward Proxy interception as HTTPS
Streaming over HTTP
IM over HTTP
In this chapter, the focus is only on streaming media and IM protocol detection.
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 a HTTP
server donot trigger the handoff and are instead processedby the regular HTTP proxy on the
ProxySG. An HTTP connection established through port 80 allows you to send streaming data
from the origin server to the clients through the ProxySG.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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.
For Instant Messaging
IM handoff allows the Blue Coat 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
may be necessary to temporarily pass through traffic from new versions of IM clients that are not
yet supported by Blue Coat.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Static and Dynamic Bypass
6OLGH6WDWLFDQGG\QDPLFE\SDVV
Instructors Note: The slide may seem intimidating but you can easily explain it; the goal is to
point out the difference between static and dynamic bypass list. The static bypass list allows
you to create Client address and Server address pairs. When a request matches an entry in the
static bypass list, the request is passed to the OCS without being processed by the proxy. No
parameter of the connection is modified.
Static Bypass:
A- Client requests the URL http://www.bluecoat.com/, which resolves to the IP address
216.52.23.9; this matches an entry in the bypass list
B- The OCS receives the original, unmodified request from the client via the ProxySG
Dynamic Bypass:
1- Client requests the URL http://www.somesite.com/, which resolves to the IP address
10.10.2.36. There is no entry for this source/destination pair in the bypass list
2- The OCS receives the traffic processed (policies applied) from the ProxySG
3- The OCS returns an error code, which you have defined to trigger a dynamic bypass entry
4- The IP address of the OCS and the requesting client are placed in the dynamic bypass list
5- The client receives the error; further requests from that client to that same OCS will not go
through policy processing.
The bypass list contains IP addresses/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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 (OCS), 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.
Notes:
Dynamic bypass entries are lost when the ProxySG is restarted.
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 86400. 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
If connect-error is enabled, any connection failure to the origin content server (OCS), 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
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Restricted Intercept
6OLGH5HVWULFWHG,QWHUFHSW
Instructors Note: This is a very useful sales and debugging tool. It allows an administrator to
test the features and functionalities of the ProxySG for few initial clients and roll out the
solution very gradually. Also, in case of some severe issues to be diagnosed, the administrator
can limit the traffic that is intercepted by the proxy so that the logs and packet captures contain
less data to process.
By default, all clients and servers evaluate the entries in Proxy Services (Configuration > Services >
Proxy Services) where the decision is made 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Trust Destination IP
6OLGH7UXVWGHVWLQDWLRQ,3
Instructors Note: The concept of trusting destination IP is relatively simple and may be
exaplained but saying that the SG0 in the Slide 2-9 does not perform DNS resolution on the
host name found in the requests but will use whatever destination IP address the client have in
the request.
In the slide above point out the following:
- SG0 is a transparent proxy
- The clients are explicitally proxied using a PAC file, which load balances SG1 and SG2
- For one client, the trust destination IP option is disabled (default setting); when it tries to go to
www.bluecoat.com via either SG1 or SG2 proxy, the SG0 terminates the connection, performs
DNS lookup on the hostname and sends the request directly to the OCS
- For the other client, the trust destination IP option is enabled; when it tries to go to
www.bluecoat.com via either SG1 or SG2 proxy, the SG0 terminates the connection,applies
policies, but DOES NOT perform DNS resolve on the hostname. It sends it directly to IP
address found in the client request.
Important: All policies you set in your PAC file are not affected but the transparent SG0 proxy.
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 WINS 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.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The ProxySG has policy that rewrites the server URL.
By default, the ProxySG does not trust a client-provided destination IP address. You can change
this default through the Management Console, the CLI, or through policy.
Note:
In the MACH5 edition, the ProxySG trusts the client-provided destination IP address
by default.
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(yes|no) property
This property allows the SG to honor client's destination IP when it intercepts client requests
transparently.
The Proxy SG will trust the client provided destination IP and not do the DNS lookup for the
HOST value in appropriate cases. This feature will not apply (i.e. existing behaviour will be
preserved) if :
The ProxySG recieves the client requets 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 destination IP you can use the policy
shown below:
<forward>
proxy.address=10.10.167.0/24 trust_destination_ip(no)
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for TCP Tunneling Lab

Overview
In this lab you set up a TCP-Tunnel service to handle protocol requests on port 22.You want to
configure your Blue Coat SG appliance to accept connections on port 22 and redirect those
requests to an SSH server, for instance 172.16.90.100.
Note:
The scenario proposed in this lab is to control all SSH requests going to a specific
server. You should block access to SSH and port 22 for outbound traffic on the
firewall.
Computer Hardware and Software Requirements

Table 2-1: Requirements for the Instructor
Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F version 6.0 or above
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F SSH Server
F Open SSH version 4.0
Table 2-1: Requirements for Students

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F PuTTY
F Release 0.60
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 3: Content Policy Language
Instructors Note: You need to emphasize the basic terminology used in Content Policy
Language (CPL). In particular, you need to make sure that the students are familiar and clearly
understand the following terms: rule, trigger, property, definition, and action. Emphasize the
concept of layer and layer guard. Spend some time showing the VPM-generated CPL code
and compare with CPL code you would write to accomplish the same task. If you have
experience of C or other programming language, try to point out analogies and differences.
You can create policy rules using either the Visual Policy Manager (VPM), which is accessible
through the Management Console, or by composing Content Policy Language (CPL). CPL is
proprietary programming language specific to the Blue Coat SG platform. It allows you to
express the policy rules that are enforced by the ProxySG.
Almost all of the policy operations can be expressed through the VPM; however, there are a few
advanced operations which are possible only in CPL.
In this chapter, you will learn how to compose policy rules in CPL. You will then install the policy
on the ProxySG. You also will examine how that policy is evaluated during request processing to
override any default decisions arising from the initial configuration rules.
Key Concepts
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. This section provides an overview of important concepts.
Policy
The term policy, as used here, 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). Often, the policy references system configuration for the default values
for some settings and then evaluates rules to see if those settings should be overridden.
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:
Q
Q
Q
Q
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.
Q In a few special cases, two or more transactions can be created for a single request.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 or not requests should be
allowed or denied. The defaults for the various transaction types are:
Q Administrator Transaction: The default is to deny requests

Q Cache Transactions: The default is to allow requests
Q 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.
; Default proxy policy is DENY
That line in a policy listing is a CPL comment, defining the starting point for proxy policy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Content Policy Language (CPL)
Programming Language used by Blue Coat SG

VPM is a GUI for CPL
Three CPL Policy Files

Local
Central
Forward
6OLGH&RQWHQW3ROLF\/DQJXDJH&3/
Instructors Note: This slide introduces CPL and its associated files.
The VPM is the GUI for composing CPL on the ProxySG, and the generated code is stored in
read-only files. Unfortunately, there is no way to have the code written in CPL be reflected in the
VPM rules.
Three files are associated with policy processing on the ProxySG:
Local policy file: Contains most of the policy rules for a system when the VPM is not used.
Central policy file: Contains policies typically managed by Blue Coat.
Forward policy file: Contains policy rules associated with forwarding requests.
The policy rules from all sources (VPM and the three files above) are combined at any time into
one large set of rules called the current policy. You can specify the order of evaluation of all policy
sources in the Management Console.
The total combined current policy (VPM and CPL) in effect at any time can be viewed through the
Management Console.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
CPL Policy Files
6OLGH&3/ILOHV3URFHVVLQJRUGHU
Instructors Note: This slide represents graphically how the different policy files interact and
how they contribute to creating the running policy that the ProxySG uses. The VPM generates
a VPM-CPL file, which cannot be edited. The easiest way to explain the roles of the Local,
Central, and Forward files is to compare them to containers for your policies. You write and
edit CPL code inside the Local and Forward files. The Central file is typically managed by Blue
Coat; however, you can create a custom Central file instead.
VPM-CPL, Local, and Central policy files can be placed in any order you want. Point out that
the last one has priority because the files and therefore the layers in them are processed
from top to bottom. The Forward policy file is always the last file to be processed. Aside from
having the policy better organized, it makes no difference in which file you write your policy.
The ProxySG allows you to create policies in four different files; each file is simply a container for
CPL code. The ProxySG combines all of the four files to create the current (running) policy.
You can define in which order the files are processed; the only exception is the Forward policy file,
which is always processed last.
The content of each file, as well as the entire running policy, can be viewed from the Management
Console.
VPM-CPL File
The VPM GUI generates the code in this file, and you cannot edit it. If you try to do so, the policies
may work incorrectly or may not work at all.
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 will be empty. (However, there are some advanced
policies, which can be created using CPL only.) On upgrade from a CacheOS 4.x system, the Local
file will contain any filter rules configured under the old system.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Central Policy File
Blue Coat provides the Central policy file to help keep virus and other threat definitions
up-to-date. However, you can have the ProxySG point to a custom Central policy file instead.
If you configure your ProxySG to use it, you can set some parameters for the file through the CLI.
You can specify how frequently the ProxySG checks for a new version of the Central policy file. By
default, the appliance checks for an updated Central policy file once every 24 hours (1440
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:
SGOS#(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 at the (config) command prompt:
command:
SGOS#(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 three policy files. The Forward policy file was originally introduced to
contain Advanced Forwarding rules when the system is upgraded from a previous version of
SGOS (2.x) or CacheOS (4.x).
Each of the previous files may contain rules and definitions, but an empty file is also legal. (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 four files by concatenating
their contents. The order of assembly of the VPM, Central, and Local policy files is configurable.
The default evaluation order is VPM, Local, Central. The Forward policy file is always last.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
6OLGH&3/OD\HUV
Instructors Note: Point out that layers in CPL work the same way as layers in the VPM.
Remind the students that the VPM was created as a GUI to CPL later in the life span of the
ProxySG. More features are available in CPL than in the VPM. As in the VPM, the last layer is
the most significant. Spend some time talking about the layer guard construct, which is
currently not yet available in the VPM. You should be able to create an example, similar to the
one shown here, where the use of a layer guard is advantageous. Discuss the fact that a layer
guard offers a performance improvement; if the layer_condition is not met, the entire
layer is skipped.
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 the <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 will 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:
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
set layer_properties then set rule2 properties
else if (rule3_condition is true) then
set layer_properties then set rule3 properties
...
}
Collectively, layer_condition and layer_properties are often 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.
Note:
The layer guard construct is not yet available in VPM.
1. This is the layer_type

2. This is the layer_condition
3. This is the layer_property
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
6OLGH&3/VHFWLRQV
Instructors Note: There are two main reasons for creating sections within a layer:
performance and structural organization. The most significant benefit of using sections is the
performance improvement that you have when you use long lists of URLs to define a
condition. The URLs listed in the [url] section are loaded by ProxySG as a hashed table;
comparing hashed signatures is much faster than doing string matching between the rule
condition and the requested URL. Focus some time on the example at the end of this section.
In the lab you will show your students how the Blue Coat Central policy file is organized. There
are several sections in that policy file. Review it ahead of time and be ready to explain it line by
line. The file is available at https://download.bluecoat.com/release/SG4/files/CentralPolicy.txt
A section is a way of grouping rules that have like 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 sections 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]
The [url.domain] 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. (The [url.domain] section replaces the [domain-suffix] section used in
previous versions of CPL.) 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
[url.regex]
The [url.regex] 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.
[server_url.domain]
The [server_url.domain] 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. Certainly for lists of several hundred or thousands of
URLs, the performance advantage is significant.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
CPL and VPM Layers
VPM
CPL
Description
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
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
SSL Intercept
<ssl-proxy>
Determines whether to tunnel or intercept

HTTPS traffic
SSL Access
<ssl>
Determines the actions for intercepted

HTTPS traffic
N/A
<exception>
Control of exception responses including

header set/rewrite/delete
6OLGH&3/DQG930OD\HUV
Instructors Note: Make sure the students understand that not all CPL layer types are
available in VPM. Also VPM splits some layers, which are the same layer in CPL. Mention that
this course does not cover the <exception>, <dns-proxy>, and Socks Authentication
layers as they are seldom used.
In CPL you have seven layer types. This is fewer than what is available in the VPM; however,
there is no loss of functionality. For instance, all 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.
Slide 3-5 is a useful reference that allows you to transition easily from VPM-based to CPL-based
rules. In most cases, you will be using <proxy> layers. Below 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 (CLI).
<SSL-Intercept>
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 transaction will be
intercepted. If the transaction is not being intercepted the policies in the <SSL> will not apply.
<SSL>
This layer lists the triggers and properties that apply to the connections that are intercepted in
the SSL-Intercept layer.
<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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Content Policy Language (CPL)

CPL is a combination of:
Rules
Triggers
Properties
Definitions
Actions
6OLGH&RQWHQW3ROLF\/DQJXDJH&3/
Instructors Note: Slide 3-6 lists the components of CPL that are covered in subsequent
pages. Try to avoid too much discussion until the material is covered on the following pages.
The components listed in Slide 3-6 are the building blocks of CPL. They will be discussed in the
next few pages.
It is important that you learn what each of these building blocks does and in which contexts each
can be used.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Rule
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
Instructors Note: Rules are fundamental to enforcing policy on our system. Tell students that
in the next few pages they will see the relationship between the VPM rules used throughout
the class and CPL rule syntax.
Rules are crucial to enforcing policy on the ProxySG system. 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 forth. 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
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Triggers
Request (url=)
Response (response.header.Content-Type=)
User (user=, group=)
System state (time=)
6OLGH&3/WULJJHUV
Instructors Note: Slide 3-8 begins the discussion of triggers. Have some sample triggers
ready to show the class in response to questions. The Content Policy Language Guide
contains many examples.
A condition is a Boolean combination of trigger expressions. 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 one of the trigger expressions is true.
CPL triggers have the form trigger_name=pattern_expression.
CPL properties have the form property_name(setting), except for a few imperative gestures,
such as allow and deny.
The text in policy rules is case-insensitive, with a few exceptions that will be identified later.
Triggers are used in rules and in condition definitions.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Triggers HTTP
Protocol
Host
Port
Path
File
Extension
Query
http://www.bluecoat.com:81/path.path_path/demo_file.html?sess=1234
url.scheme=
url.host=
url.host.regex=
url.port=
url.path=
url.query=
url.path.regex=
url.query.regex=
url.address=
url.extension=
url.domain=
url=
url.regex=
6OLGH&3/WULJJHUV+773
Instructors Note: Please point out ALL possibilities for tests that can be part of a trigger.
Describe how the url= trigger can match on anything from the protocol scheme to the
query string. Define the difference between url= and url.regex= as described in the table
below. In particular, describe how url.substring tests if the string pattern is a substring of
the URL or component; the substring need not match on a boundary (such as a subdomain or
path directory) within a component.
Carefully note all 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 our CPL code.
Note the numerous regex components that allow us to fully use the power of regular
expressions in determining whether a trigger test matches or not. A separate chapter of this book
discusses regular expressions in detail. 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 the one shown below:
url.domain=example.com
Table 3-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
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Properties
6OLGH&3/SURSHUWLHV
Instructors Note: Spend some time defining transactions and giving the students an idea of
the many applications that use the transaction concept.
You learned about transactions in the chapter on System Architecture. A transaction is defined as a
unit of work that cannot be interrupted and must succeed or fail as a unit. Transactions are
considered to be a set of operations that are executed as though they were a single operation with
all or none being the final result of the transaction.
Properties are settings that control transaction processing, such as deny, or the handling of the
object, such as cache(no), indicating that the object is not to be cached locally.
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 retains the final value setting when evaluation ends, and the transaction is processed
accordingly.
Properties that are not set within the policy maintain their default values.
CPL properties have the form property_name(setting), except for a few imperative gestures
such as allow and deny.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Named Definitions
Subnet Definitions
Define a list of IP addresses or IP subnet masks

that can be used to test
Condition Definitions
Include any triggers that are legal in the layer

referencing the condition.
Allow for arbitrary Boolean combinations of trigger

expressions
condition= trigger
6OLGH&3/QDPHGGHILQLWLRQV
Instructors Note: Discuss the examples contained in the student section of this page. You
should create and demonstrate a simple CPL policy, which allows or blocks users based on a
subnet definition.
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. An example is the clients address or
the requests destination address.
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.
Since conditions definitions can include other triggers, 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 any http request through proxy port
;8080.
define condition QA
client.address=1.2.3.4
proxy.port=8080
end
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Named Definitions
Category Definitions
Extend vendor content categories

Tested using category= trigger
Action Definitions
Are turned on/off for a transaction using action()
Transformer Definitions
Specify a transformation to an HTTP response.

url_rewrite, active_content, javascript
6OLGH&3/QDPHGGHILQLWLRQV
Instructors Note: This slide continues the discussion of named definitions; as before discuss
the examples contained in the students section.
Category definitions are used to extend vendor content categories or to create your own. These
categories are tested (along with any vendor-defined categories) using the category= trigger.
An action takes arguments and is wrapped in a named action definition block. Actions are turned
on or off for a transaction through setting the action( ) property. The action property has
syntax that allows for individual actions to be turned on and off independently. When the action
definition is turned on, any actions it contains operate on their respective arguments.
A transformer definition is a kind of named definition that specifies a transformation that is to be
applied to an HTTP response. There are three types: url_rewrite definitions,
active_content definitions, and javascript definitions.
Here is an example of a category named definition:
define category Grand_Canyon

kaibab.org
www2.nature.nps.gov/ard/parks/grca/
end
Here is an example of an action named definition:
<cache>
url.domain=!my_internal_site.com action.scrub_private_info(yes)
define action scrub_private_info
set( request.header.From, "" )
set( request.header.Referer, "" )
end
Here is an example of a transformer named definition:

define url_rewrite ijk_portal
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
rewrite_url_substring "http://www.ijk.com/" "http://www.server1.ijk.com/"
end
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Actions
Two types of Actions in CPL
Properties change proxy configuration for this

transaction
Defined Actions change transaction
Common Properties
deny
allow
access_log()
authenticate()
6OLGH&3/DFWLRQV
Instructors Note: This slide gives a brief introduction to actions in CPL. Remind students of
the form of actions used in VPM rules.
An action takes arguments and is wrapped in a user-named action definition block.
When the action definition is called from a policy rule, any actions it contains operate on their
respective arguments. Within a rule, named action definitions are enabled and disabled using the
action( ) property.
Actions appear only within action definitions and they cannot appear in <Admin> layers.
Actions take the following general form: action( argument1, ...)

The allowed syntax for action arguments depends on the action.
There are four types of arguments:
String
Enumeration
Regular expression
Variable substitution
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Actions
Common Defined Actions
append (header_name, text_string)

delete (header_name)
delete_matching (header_name, regex)

redirect (HTTP_response_code, regex,
new_destination_url)
rewrite (header, regex, replacement)
rewrite (url[.host], regex, replacement)

set (header_name, header_value)
6OLGH&3/DFWLRQV
Instructors Note: This slide gives several examples of defined actions. Mention their
similarities with functions and methods in normal programming languages.
Note that each defined action takes a special set of arguments. Here are more 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.
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. There are several forms. Please check
action() reference section of the Content Policy Language Guide.
set()
Sets the specified header to the specified string after deleting all components of the header.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Define Actions Example
define action removeUA

delete(request.header.user-agent)
end
<Proxy>
; Remove the user-agent header from all
HTTP requests
action.removeUA(yes)
6OLGH'HILQHDFWLRQVH[DPSOH
Instructors Note: Use this slide to explain the syntax used to create a define action. The
items in bold are the required elements in CPL, the ones in italics represent an arbitrary name
that you can use. The other text is standard CPL code. Point out that there is not a statement
like action.removeUA(no). The reason is simple: If you do not want an action to execute,
you need to create a proper trigger to determine when it should indeed be invoked. The policy
is rather simple and should not be used as it may interfere with the functionalities of some
OCS. Discuss with the students some better way of masking or reducing the amount of
information made available in the user-agent header.
This slide shows a simple example where you have created a defined action. The objective of the
code is to remove completely the user-agent header from any HTTP request made by the
clients. You can improve on this policy; the text here is just for your reference.
Before you can invoke an action, you need to create a defined action with the following structure:
define action action_name

actions...
end
The parameter action_name can be any alphanumeric string (without spaces); you should use a
name which closely describes what the action is going to do.
Once you have declared the action, you can invoke its execution from anywhere in the CPL code;
obviously you cannot invoke it from a layer where the action is not valid. You can control when
the action is actually executed, using any of the triggers available for that layer. The construct to
invoke the execution of a define action is:
action.action_name(yes)
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Special Characters
user="John Doe" ; value contains a space
deny( "You dont have access to that page!" ) ;

several special chars
user="john.doe" ; quotes not required,
Long lines can be split using \
6OLGH6SHFLDOFKDUDFWHUVLQ&3/
Instructors Note: There is a complete list of special characters in the Content Policy
Language Guide.
Certain characters are considered special by CPL and have meaning as punctuation elements of
the language. For example, = (equal) separates a trigger name from its associated value, and blank
space separates expressions in a rule.
To use a value that contains one of these characters, the value must be quoted with either single ()
or double (") quotation marks, so that the special characters are not interpreted as punctuation.
Text within single quotation marks can include any character other than a single quotation mark.
Text within double quotation marks can include any character other than a double quotation
mark.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Synonyms
deny.unauthorized
exception(authorization_failed)
force_deny.unauthorized
force_exception(authorization_failed)
deny
exception(policy_denied)
6OLGH&3/V\QRQ\PV
Instructors Note: Slide 3-17 shows different ways to specify the same operation.
Policy listings are normalized in several ways. First, condition and action definitions that may
appear anywhere in the source will be grouped following the policy rules. Second, the order of the
conditions and properties on a rule may change. This is because the CPL compiler always puts a
deny or allow at the beginning of the rule and orders conditions to optimize evaluation. Finally,
several phrases are synonyms for phrases that are preferred.
In Slide 3-17, the main bullet points show the preferred usage of three operations. The sub-bullets
show the synonyms. For example, deny.unauthorized is the preferred form, and
exception (authorization_failed) is the synonym.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Categories: Solutions with Policy
Policy to allow text and block images
<proxy>
category=Adult/Mature Content
url.extension=(jpg, gif) DENY
category=Adult/Mature Content
response.header.content-type=image DENY
category=Adult/Mature Content ALLOW
Deny Sports during work hours
<proxy>
category=Sports time=0800..1800 DENY
6OLGH&DWHJRULHVVROXWLRQVZLWKSROLF\
Instructors Note: You need to use Slide 3-18 to start a conversation with the students. The
top bullet point contains some questionable policies. Ask your students the following
questions:
1) Based on the rules that you see in this slide, does the ProxySG have a default policy of allow
or deny? (ANSWER: deny)
2) Do you really need the policy

category=Adult/Mature Content url.extension=(jpg, gif) DENY
based on the fact the following policy is:
category=Adult/Mature Content response.header.content-type=image
DENY (ANSWER: Not really; the second rule blocks objects based on the image MIME type. A
file with the extension .jpg or .gif will most likely have the MIME type set to image/jpg and
image/gif respectively.)
The first <proxy> layer contains three policies. The idea is to block all .jpg,.gif, and
MIME-type images. The last rule in the first layer allows all traffic from Adult/Mature sites;
however, because of the previous two rules, all images are blocked4.
The rule in the second <proxy> layer simply denies access to sports-related sites during work
hours (8 a.m. to 6 p.m.) Note that time is always expressed using military time (24-hour clock).
Finally, it is worth nothing that the spaces between triggers should be interpreted as the logical
operator AND while the space before the action clause should be interpreted as THEN keyword.
There is an understood IF statement before each rule. So the rule would actually be interpreted as:
IF category=Adult/Mature Content AND url.extension=(jpg, gif)

THEN DENY
etc...
4. Note that flash and other video file formats are not blocked.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Categories: Solutions with Policy
Authenticate a site for a work section
<proxy>
category=HR authenticate(HR_Realm)
Deny Access if site is not categorized
<proxy>
category=(drugs, violence, none) DENY
6OLGH&DWHJRULHVVROXWLRQVZLWKSROLF\
Instructors Note: Slide 3-19 contains more examples. Point out that because the category is
a valid trigger in an authentication rule, the categorization is done before authentication.
In the second example, point out how the round parentheses and the comma can be used to
construct a logical OR statement.
The first layer in Slide 3-19 shows how you can authenticate based on a destination. Users trying
to access sites categorized as HR will be authenticated in the HR_Realm realm.
The first example should be interpreted
IF category = HR
THEN authenticate
The second example should be interpreted
IF category = drugs OR violence OR none

THEN deny.
The commas should be interpreted as the logical operator OR in the rule.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
CPL Substitutions
Rewrite the URL request
Modify HTTP request headers

Modify HTTP response
Substitutions have the form:

$(name)
6OLGH&3/VXEVWLWXWLRQV
Instructors Note: CPL substitutions can be used for a variety of purposes. Explain with some
examples where policy substitution can be used. A lab follows the next slide, which continues
the discussion of CPL substitutions, so be sure to introduce some of the key concepts for that
lab.
CPL 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, which will expand at runtime 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 will be displayed to users.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Common CPL Substitutions
$(url)
$(url.host)
$(client.address)
$(user)
$(proxy.name)
=> client requested URL

=> URL hostname
=> Requesting clients IP
=> Authenticated username
=> Proxys hostname
Example:
set(response.header.Referer, $(url.host))
6OLGH&3/VXEVWLWXWLRQV
Instructors Note: Slide 3-21 lists some of the most commonly used CPL substitutions.
In each case, the substitution on the left is defined by the text on the right. For example, $(url) is
the substitution for 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Configuring the Central Policy File Lab

Overview
Configuring the Blue Coat SG appliance to retrieve the Blue Coat Central policy file every
hour.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F PuTTY
F Release 0.60
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Creating Sample CPL Policy Lab

Overview
In this lab, you create the following HR-approved policy for company XYZ, Inc.:
Users are authenticated against an IWA realm, even when they are going to be blocked.
Everybody is blocked from accessing hacking sites, with the exception of the IT staff.
Everybody is blocked from accessing pornography Web sites.
When users are blocked, a message appears referring them to an acceptable usage policy page.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for CPL Policy Using a Flowchart Lab

Overview
You want to allow employees in your company to access news sites, but only one page each day
for each site. For example, each employee can read one page from www.cnn.com, one page from
www.latimes.com, and one page from www.foxnews.com.; however, when employees try to pass
the limit, access is blocked.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F Live HTTP Headers
F version 0.13.1
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 4: Regular Expressions
Instructors Note: This section describes regular expressions, which many students have
some experience using. Students will find regular expressions very useful in writing policy.
Students also may want to try software that creates and tests regular expressions, such as
Regex Coach and RegexBuddy, both available over the Internet.
Before you start the session, ask your class how familiar are they with regular expressions
(regex). If they are not very familiar with them you may want to supplement the chapter with
additional samples. Make sure that you use examples based on some hands-on experience
writing CPL code.
There are several sample policies in the text of this chapter. Make sure that you cover all of
them and also demonstrate them on your proxy.
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, the
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. Ever since that time, 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 Perl's
regular expression functionality, and is used by many modern tools such as PHP and Apache.
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,
like 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 a Courier font, usually without
quotes, and strings to be matched are in single quotes.
Some characters, like | (vertical bar or pipe) or ( (parenthesis), are special. Special characters,
called metacharacters, either stand for classes of ordinary characters, or affect how the regular
expressions around them are interpreted.
Blue Coat regex differ from the Perl regex. The list below addresses some of the main differences.
Normally space matches space, formfeed, newline, carriage return, horizontal tab, and
vertical tab. Perl 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
RE ENGINE 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.
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.
RE ENGINE does not support the (?{code}) construction.
There are at the time of writing 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 of RE ENGINE.
Another as yet unresolved discrepancy is that in Perl 5.005_02 the pattern

/^(a)?(?(1)a|b)+$/ matches the string a, whereas in RE ENGINE it does not. However,
in both Perl and RE ENGINE /^(a)?a/ matched against a leaves $1 unset.
RE ENGINE 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Regular Expressions
Regular expressions compare a substring to a

target string
NET
OATH
OTH
6OLGH5HJXODUH[SUHVVLRQV
Instructors Note: This is a very simple introduction to regular expressions. If you have
students who come from a database background they will expect some sort of wild character
before and after the pattern, in order to match it anywhere in the reference string. For instance,
it is common for student to expect *NET* as the syntax to match NET anywhere it appears.
Regular expressions work with the opposite logic. By default, the pattern is matched anywhere
it appears in the reference string. Make this point very clear.
The slide shows a reference string and three different patterns. The reference string is
onetwothreefour and the patterns are: net, oath, and oth.
You can see that only two of the pattern exists 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.
Lets 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 the follwing policy on your Blue Coat SG:
<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 string.
The following slides cover additional regex syntax, which allows you to better define how to
match the pattern in the reference string.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Character Classes
. (period)
Matches any character
\w
Matches a word. A word is anything made of letters,

numbers, and the _ (underscore)
\s
Matches a white space
6OLGH*HQHULFFKDUDFWHUFODVVHVRUW\SHV
Instructors Note: This slide introduces generic character classes (or types). Spend some
time talking about the dot. It matches any character, but only one occurrence of a character.
The other classes are shown here mostly for reference purpose only; they are seldom used in
writing CPL code.
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)
newline. (Note that 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
Consider the two URLs, http://www.bluecoat.com and http://wwwwbluecoat.com. Consider a

policy like the one below:
<proxy>
url.regex=www.bluecoat.com
The policy matched both URL as the dot in the regex matches any character.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: Continue the conversation from the example in the student section
mentioned in the previous slide. Discuss how you need to have an operator, which tells the
regex engine when to interprete a metacharacter as literal or as an operator.
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 the regular
expressions.
When you need to use one of these metacharacters literally in a regular expression, you must place
a backslash (\) in front of it. This allows you to use it without its special meaning. In the example
in Slide 4-3, 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 as a different role:
<proxy>
url.regex=www\.bluecoat\.com ALLOW
<proxy>
url.regex=blueco.t ALLOW
The first policy matches a URL, which contains the string www.bluecoat.com; the second poliy
matches any URL, which containt blueco followed by any one character and a t.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: This slide describes two special characters, which you will use often when
writing CPL code. Discuss the two following terms: anchored and unanchored. Anchored
refers to a regex, which is trying to match the pattern in a particular part of the reference string,
either at the beginning of the end. Unanchored is a normal regex; this is the default behavior.
In CPL all regex patterns are unanchored, unless otherwise noted. There are some exceptions
mentioned in the student section of the slide, which you should discuss.
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.
The following policy, for example, is looking for a URL ending with anything but .html, and
denying it.
<proxy>
url.regex=!\.html$ DENY
The policy is of very limited applicability but offers you an idea on how you can create more
powerful CPL code.
Important: Regular expressions in the CPL actions redirect(), rewrite(), and
rewrite() are anchored.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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"
Instructors Note: This slide introduces additional metacharacters, which allow you to mach
characters many times. You will use all of the in writing CPL code. You should have some
additional examples ready to discuss with the students. At this point you have enough
information to start doing some interactive excercises.
The regual expression engine 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Question Mark (?)
The question mark (?) causes its resulting regular expression to match zero or one repetitions of the
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 site use style sheets and other advanced objects, which are in essence
pages not ending with .html or .htm; as result most pages will not display properly.
The second policy denies access any URL which starts with http://, followed by any number of
charactes, and then /training/. You can access http://training.bluecoat.com but not
http://www.bluecoat.com/resources/training/index.html
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: Character sets are not used very often in CPL regex; however it might be
useful to have some extra examples of character sets ready to show on the whiteboard if you
think your class is having trouble with the concept.
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, e.g. [\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 (defined later in this chapter) 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: This slide introduces range qualifiers or repetition specifiers. This slide
may be very useful to create several policies. There are well over 100 registered regional
domains for Google. You cannot create a policy listing all of them but you can point out that
there are only few types of google regional domains:
www.google.com = www.google. plus three characters

www.google.co.uk = www.google. plus five characters (consider the . beteween co and uk)
www.google.it = www.google. plus two characters
www.google.com.au = www.google. plus six characters
So you have www.google. plus a minimum of two to a maximum of six characters.

Discuss this example with your students as another way of creating a better safe search policy
later on.
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, which begins with www.google. and it followed by
anywhere from two to six alphabetical characters. This allows you to cover all the possible
variations of the Google regional domains (www.google.com, www.google.co.uk,
www.google.it, www.google.com.au, etc.).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: Grouping is an extremely useful tool in creating effective CPL policies. You
need to discuss with the students, that a regular expression does not simply match (or not
match) a pattern in the reference string but also memorizes (or stores) the part of the
reference string matched. This concept is discussed in more detail in Slide 4-10. Discuss in
detail the sample policy that appears in the text.
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. (Discussed in Slide 4-10.)
You can use the grouping to create a policy to control the maximum size of an object that you are
trying to donwload. You need to be aware that this policy does not work for all objects and may
not stop transactions where the object is checked. It is nonetheless a good example of how to use
grouping. The OCS 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 KB (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 which is exactly 10,000 bytes, while the second rule
blocks anything which has more than 4 digits in the size. The second rule cover all sizes from 0 to
9,999.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: The ability to create policies based on the Boolean operator OR allows you
to create simpler policies. As matter of fact, the text on this page shows two policies created
previously in the chapter that have been redone using the OR operator. Discuss the examples.
The regex engine allows you to create policies using the OR Boolean operator. The vertical bar (or
pipe) | is the equivalent of the OR. As soon as the first match is made, the other choices are not
examined further in a given pattern. To match a literal |, remember to use the escape character as
in \|.
Note that in the second bullet point in Slide 4-9, 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 wil the extention .HTML or .HTM becomes:
<proxy>
url.regex =!(html|htm)$ DENY
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: This slide introduces the complex topic of back references. It is best to
study some examples ahead of time, because students often have problems with this pattern.
In Perl regex, 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 Blue Coat CPL
implementation, back references have the format $( ); the first match is $(1), the second $(2), etc.
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, note that 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. Everytime a user asks for the site
http://www.bluecoat.com/techlabs/{any page}, you redirect the request to
http://techlabs.bluecoat.com/{any page}
<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
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: This slide is very important. The use of back references allows you to
create several adavanced CPL policies. In particular, you can use a regular expression to
construct similar a one in the slide for two-ways URL rewrite. The back references are also
used in the Google SafeSearch policy in the lab at the end of this chapter. Makes sure that the
students understand this concept very clearly.
By placing part of a regular expression inside round brackets or parentheses, you can group that
part of the regular expression. This allows you to apply a regex operator, that is, a repetition
operator, to the entire group.
Note that only round brackets 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, round brackets also create a back reference.
A back reference stores the part of the string matched by the part of the regular expression inside
the parentheses.
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
in the lower example.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for CPL Policy Using Regular Expressions Lab

Overview
In this lab your objective will be to :
Block a new virus with a random pattern
Block all sites containing certain words (sex, drug, news, mail) in the page name or query
string
Redirect all requests made to http://www.bluecoat.com/training/{other pages} to

http://training.bluecoat.com/{other pages}

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Enabling Safesearch Lab

Overview
Many users of the Google search engine prefer not to have adult sites included in their image
search results. Google SafeSearch is a function that filters out obscene content when you search
for images on Google. The SafeSearch filters check keywords and phrases, URLs, and Open
Directory categories to screen out potentially offensive material.
Googles SafeSearch has three levels:
Use strict filtering (Filters both explicit text and explicit images)
Use moderate filtering (Filters explicit images only default behavior)
Do not filter my search results
Using a Blue Coat SG, a security administrator can configure a policy on the proxy to always
enable the SafeSearch (strict filtering) when a user accesses Google Web site and searches for
images. After you implement this policy, the images that come up in any search for material on
www.google.com are much less offensive.
In this exercise, you enable SafeSearch by adding &safe=on to the Google query string. Note that
the policy includes only Google settings.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F Wireshark
F version 0.99

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F Wireshark
F version 0.99
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 5: Managing Downloads and Apparent Data Types
Instructors Note: The purpose of this section is to explain why Web downloads are
problematic and how the Blue Coat SG addresses these security issues. In discussing this
chapter, you first need to first build awareness of the potential threats. Then discuss how the
ProxySG offers several tools to control downloads over HTTP. Although antivirus scanning is
not discussed in this section, you should start mentioning it. You should also introduce the idea
of bandwidth management as an alternative to the more rigid choice between a full allow or full
deny.
Point out that file exhumation is a very weak detection strategy because files easily can be
renamed. Discuss, as an example, Windows Metafile Format (WMF) files. The WMF file is a
special image type designed by Microsoft in the 1980s. It allows some executable code to be
embedded in the image. If a process opens the WMF file, the code contained in the file is
executed in the security context associated with the user currently logged on the system.
Windows recognizes WMF files even if you rename them. MIME types can be easily tampered
with as well. Explain how most files types have specific header (and sometimes footers) that
identify them uniquely. This feature allows you to create policies based on the actual file
signature. The feature is called Apparent Data Type because there is a remote, but possible,
chance that a file may be incorrectly recognized as the wrong type.
As always, emphasize the concept that policies can be granularly applied to users, groups, IP
addresses and subnets, categories, and any combination of these elements. Pay particular
attention to the concepts of chunking and content encoding. Compression and chunking are
two significant additions to the HTTP/1.1 protocol.
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. Though HTTP is
designed to use Multipurpose Internet Mail Extension (MIME) types, it does not necessarily
transform binary data to text. Base64 encoding is allowed in HTTP but not required. You can
transfer binary data in the data portion on an HTTP response, provided that correct information is
included in the response header and the client supports it.
MIME types are not peculiar to HTTP. They were originally developed to deliver non-text e-mail
attachments but are now used in many other applications as well. The details of MIME types are
defined in RFC 2045 and RFC 2049. MIME types are very important because they can be used to
identify the content type, and block the download, if necessary.
The process of transferring data over HTTP is relatively simple:
1.
The user agent (UA) requests the specific file using one of the allowed methods (most likely
GET).
2.
The origin content server responds (if everything is correct in the request) and specifies:
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Q The type of file being delivered (text, image, application)

Q The sub-type (for images, jpeg, gif, etc.)
Q The encoding of the data (none, gzip, deflate, etc.)
The ProxySG knows the file that you are requesting, based on the URL presented, and reads the
information in the response header as well as in the response data portion. As result, the ProxySG
can determine which type of file you are attempting to download using any of the following
parameters: file extension, declared MIME type, or file header.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
HTTP Threats
Malicious software
Spyware, Malware
Bandwidth
Large downloads can clog the network
Productivity
Most downloads are not business relevant
6OLGH+773GRZQORDGWKUHDWV
Instructors Note: This slide introduces the array of issues inherent in downloads over HTTP
and downloads in general. Use this slide to build awareness in students that they need to
control what enters the network and that prevention is the best tool. Mention that Blue
Coat AV and bandwidth management are useful tools in combination with all the features
provided to manage downloads.
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 more-or-less hidden code, which
tracks any sort of information about a user and can result in reduced machine and network
performances. Download of 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 the following file
types: executables, ActiveX, JavaScript, and other scripts. You also should create a white list of
approved sites; this list usually includes download sites for your antivirus vendors, operating
system vendors, and other suppliers of critical software updates.
The rest of the chapter helps you understand how downloads over HTTP operate and how you
can use the ProxySG to control them.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
HTTP Downloads
6OLGH+773GDWDWUDQVIHU
Instructors Note: This slide repeats some of the concepts that you may have already
discussed in the previous HTTP sessions. Point out that the top diagram shows the download
of an image in compressed format. Even if the client asks for gzip-encoded content, it is not
likely to receive it for that file format; however, when the client asks for a file that is in text
format, the request for compressed content is accepted. In general, HTTP delivers the files
using the original binary format of the file; however, additional encoding, like compression or
chunking, is often applied. Chunking can be applied to all file types, while compression in
general is applied only to text or other formats that are not naturally compressed.
The slide above shows how different files can be transferred over HTTP and how different
encoding formats can apply.
The top diagram shows a UA asking for a file that most likely is an image file. You cannot be sure
what the file really is; at times, malicious sites host harmful files naming them using extension
reserved for other file types. The OCS replies and specifies that the attached binary data should
represent an image in JPEG format. Again, it is important to use the word should, because an OCS
often declares the MIME type of an attached file solely based on that files extension. The UA, in
the original request, asked for gzip-compressed content, if available. In general, an OCS, even if it
supports compression, will not attempt to compress file formats, like JPEG, which already are
inherently compressed. JPEG is a compression-with-loss format; applying gzip to it may have a
null or even negative effect on the resulting file size.
The bottom diagram shows a UA asking for a file that most like is an image file. The OCS
responds and declares the attached file as an HTML page in text format. However, in this scenario,
the OCS has applied gzip compression to the file and has declared it in the response header. The
presence of the content-encoding header signals to the UA that the file received needs to be
decompressed using gzip. The OCS can apply a different type of encoding, as long as the client has
declared, explicitly or implicitly, that it will accept that encoding.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
File Type Detection

File extensions
avi, bmp, jpeg, etc.
MIME types
text/html, image/gif, etc.
Apparent Data Type

Initial bytes in a file
6OLGH)LOHW\SHGHWHFWLRQPHWKRGV
Instructors Note: Now that students understand Web downloads, you can introduce the
ProxySG features that help administrators block them. Ensure that students are aware of the
difference between blocking a file extension and blocking a MIME type.
Now that you know the process behind Web downloads, lets talk about how to block them. 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 files.
MIME 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 will scan these data files to determine if the
special data is present.
You can even 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
File Type Detection Ambiguity
6OLGH)LOHW\SHGHWHFWLRQDPELJXLW\
Instructors Note: This slide is crucial to explain how HTTP downloads can represent a threat
to your organization in many ways. Files with a given extension and a well defined MIME type
are not always what they seem to be. In the slide, you should point out how the MIME type
described in the content-type header does not match the actual file type. The MIME is set
to text, but the file quite obviously is a GIF. You should have a file that students can test with
on your Web server.
It is possible, however 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 MIME
type of a file solely based on the files extension, you can get a total mismatch between the actual
file and its MIME type. Your browser might even download a certain file with a MIME 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. Change the extension from .pdf to .txt.
When you attempt to download the file, most likely the associated MIME type will be
text/plain.
The slide 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 MIME 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 MIME
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 MIME type.
Each blocking scheme has its own advantages, and you may need to experiment to see what
works the best for you in your environment. While the Apparent Data Type feature is 100 percent
accurate, it currently blocks only the following file types1: Windows DLL and executable files,
ActiveX controls (.OCX), and Windows cabinet files (.CAB).
1. You can block virtually any file type, but this requires you to write policies in CPL.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Apparent Data Type
File types recognized based on the actual data

Example for use: Identify drive-by-installs
Executable with inaccurate MIME-type and extension
Supports for
HTTP
HTTPS
WebFTP
6OLGH$SSDUHQW'DWD7\SH
Instructors Note: Use this slide to explain the concept of apparent data type. Use some real
examples. For instance, open a couple of PDF files with either WordPad or a debugger. Show
that the files begin in the same way. All PDF files being with the following header:
%PDF-1.4 or 25 50 44 46 2D 31 2E 34 in hexadecimal. The first 4 bytes are usually
enough.
Apparent data type is a feature of the ProxySG, which matches a file with its type by analyzing the
actual data stream. You should note that the ProxySG uses the file header only to recognize a file
type. Miscategorization is a rare possibility.
Apparent data type support is available, in a pre-configured way, 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 machines are still 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 up.
ActiveX controls (.ocx)
ActiveX controls are also PE format executables that conform to the Microsoft's 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 may not
even realize that spyware has been installed on their machines.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 will download the file and
extract the ActiveX component from inside it and install 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Apparent Data Type Triggers

Apparent Data Type (predefined)
http.response.apparent_data_type = (executable,
cabinet)
Custom defined data Type
http.response.data.4.regex={}"
Allows identification of virtually any file type
6OLGH&3/JHVWXUHV
Instructors Note: This slide describes the CPL gestures associated with this feature.
Discuss the examples listed below.
The http.response.apparent_data_type= tests the apparent type of the HTTP response

data, based on examining the file header. The syntax is as follows:
http.response.apparent_data_type = executable|cabinet
where:
executable is a test for a Windows executable file (.exe)
cabinet is a 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)
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.6.regex.case_sensitive="^.\x00\x09\x00\x00\x03"
end
condition=BC_Response_Data_Pattern_wmf
FORCE_DENY
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: This slide reviews all the options that the ProxySG offers for controlling file
downloads. Do not forget to mention also file download over IM. You can use the
im.file.path.suffix="wmf" gesture.
This slide offers you 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. MIME
type is fairly reliable. It is clear that apparent data type offers the highest level of accuracy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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, at the moment,
the ProxySG supports data type recognition only through 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 files
http.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"
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Managing Downloads and Blocking WMF File

Remote Code Execution Labs
Overview
Files downloaded from the Internet or sent by e-mail can pose a hazard to the enterprise. Files
may contain viruses or other malware. In addition, allowing staff unlimited ability to surf the
Internet during working hours can reduce productivity and expose employees to materials that
they may find offensive.
The Blue Coat SG appliance enables you to block downloads of selected types of information
based upon various criteria such as URL category, file MIME type, file extension and apparent
data type. The Blue Coat SG appliance also enables you to create exceptions the download
limitations you have set.
A Windows Metafile Format (WMF) file vulnerability was discovered on December 27, 2005.
Microsoft released a patch that addressed the issue on January 5, 2006.
The WMF file is a special image type designed by Microsoft in the 1980s. This file format allows
some executable code to be embedded in the image. If a process opens the WMF file, the code
contained in the file is executed in the security context associated with the user currently logged
on the system.
In this lab you will:
Block Windows Meta Format files from HTTP downloads and IM downloads.
Become familiar with Web Access Layer policy in the Visual Policy Manager (VPM).
Use rules within the layer to block various types of data from being downloaded.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 6: Policy Tracing
Instructors Note: This section is a key component for the global troubleshooting approach to
the Blue Coat SG. Discuss the two levels of policy tracing: global and per-policy. When
you discuss the global level, be sure to warn the students of the potential severe impact on the
proxy performance. When you discuss the per-policy approach, point out its limited use; the
trace is generated only if the policy is triggered. You need to spend time on the various
examples and work with the students on the lab.
The ProxySG offers you a variety of tools to troubleshoot whatever issue you are dealing with.
Among these tools, policy tracing is one of the easiest to use and one of the most effective.
Two types of policy tracing are available to you:
Global policy tracing

Important:
Be aware of the potential severe impact on performance that this option may
have on a production ProxySG.
Per-rule policy tracing
The following matrix lists all of the Track and column objects and indicates which policy layer they
apply to.
Admin
Auth
Object
Admin
Access
DNS
Access
SOCKS
Auth
Web
Auth
Web
Access
Web
Content
Event Log
E-mail Log
SNMP Objects
Trace
Combined
Objects
Forwarding
Important: A policy-based trace only generates a trace if the rule to which is associated is
triggered.
Policy trace files are available via the Web browser. You can access them directly or via the
Management Console. From the Management Console, select Statistics > Advanced > Policy > List
of policy URLs. You can also directly point your browser to:
https://[ip address of the proxy]: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.
Note:
After using a trace to troubleshoot, remove the trace to save log space.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Trace
Global Policy Trace
Management Console > Policy > Policy Option

Use for troubleshooting
Selective Policy Trace
VPM > Track > Set > New > Trace

May not be triggered
For more limited troubleshooting
6OLGH$YDLODEOHWUDFHV
Instructors Note: This slide is self-explanatory. Point out that global policy tracing should be
used with caution and only for the minimum amount of time necessary to troubleshoot the
issue. The policy-level trace has a far less severe performance impact.
You can enable global tracing from Management Console. Select Configuration > Policy > Policy
Options, and then click the check box next to Trace all policy execution.
You also can enable global policy tracing from the command-line interface (CLI). From the CLI,
type the following commands:
SGOS>en
Enable Password: *****
SGOS# policy trace all
Use the following command to stop the global tracing:
SGOS# policy trace none
You can enable policy tracing on a per-policy basis. In the Visual Policy Manager, you can set the
track option for a given policy to record the trace information in a custom-defined file (such as
mytrace.html). You have several options for the level of detail that you want in the trace:
No Tracing: The default.
Request Tracing: Generates trace output for the current request. The trace output contains
request parameters (such as URL and client address), the final values of property settings, and
descriptions of all actions taken.
Rule and Request: Generates trace output that displays each rule that was executed.
Verbose Tracing: Generates the same output as Rule and Request, but also lists which rules were
skipped because one or more of their conditions were false, and displays the specific
client.address=10.10.10.1 trace.request(yes) trace.rules(all)
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Trace
Each transaction is evaluated separately

A page calls for many transactions
Policy traced until a match
Statements past a match are not evaluated
Policy re-evaluated at each checkpoint

Trace does not reflect it
6OLGH3ROLF\WUDFHNH\IDFWRUV
Instructors Note: Use this slide to point out why global policy tracing can generate a
significant performance impact on the ProxySG. Set the students expectations correctly: If a
rule is matched in a layer, the subsequent rules are not evaluated, as you should expect.
Each Web page or resource that you download from the Internet is composed of several objects.
For instance, when you open a complex Web page like cnn.com, your browser is likely to
download more than 50 objects.
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 built-in logic of
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 as it may confuse matters.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Trace
6OLGH6DPSOHSROLF\WUDFH
Instructors Note: Spend some time on this slide, or generate a new trace during class and
show it live to the students. Point out the start transaction and end transaction
boundaries. Point out the miss statement and the categorization. Mention that the
categorization is shown as soon as you install a content filter vendor even if there are no
policies for it yet. Lastly, point out that each transaction has a unique ID number.
Slide 6-3 shows you the result of a global policy trace. There are a few important aspects that need
to be pointed out.
In the pane marked with the number 1, you can see how the policy shows a miss. This indicates
that the triggers in the rule just evaluated for the object returned a Boolean value of false. As result
no action for that rule was taken.
In the pane marked with the number 2, you can see that the categorization is done for every object.
The categorization appears in the trace as soon as you install and configure a content filter. The
syntax for the categorization is {category name}@{vendor name}.
The process evaluation for each object is separated by the start transaction and end
transaction delimiters.
Many other details of the transaction are visible, among them:
Client IP address and port
Time of the transaction
Full URI
Information about the user agent, which generated the request
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Trace
6OLGH6DPSOHSROLF\WUDFH
Instructors Note: There are three things to point out in this slide. First, point out that a rule is
triggered. This causes an action (deny) to be taken, which is the second aspect to discuss.
Finally, point out that even if the user is going to http://mail.yahoo.com, there are two
transactions shown. Most modern browsers make two concurrent requests when connecting
to a Web site: one for the requested URI, and one for the favicon.ico, which is the little icon
showing in the link bar of the browser for many sites.
In the trace shown above, a rule is triggered. As mentioned before, you cannot expect the ProxySG
to evaluate and compare any rule following this one, in the same layer. Since the rule has been
triggered, the ProxySG interrupts the processing of that layer and moves to the next one.
This rule denies the connection, so an exception is returned to the user. This is clearly indicated by
the fact that there is a MATCH for a rule, followed by a DENIED.
Note that there are two denied actions even if the user only requested one object. Usually a
browser makes two concurrent requests when first connecting to a Web site: one for the requested
URI, and one for the favicon.ico, which is the little icon showing in the link bar of the browser for
many sites.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Policy Tracing Lab

Overview
The Blue Coat SG offers several troubleshooting and debugging options. In this lab, you use
policy tracing to determine how the ProxySG appliance interprets your policies. You can set up a
global policy-tracing option and a rule-specific trace. You need to do both.
You have just implemented a new set of policies on the ProxySG appliance; however, the result is
not what you expected. Because you suspect that you may have incorrectly defined the rule, you
set up a global policy trace specific to that rule.
In addition, you are operating in a very secure-minded environment. Your ProxySG appliance is
configured to deny all connections unless otherwise specified. You also have set up a policy that
allows access to only one employment-related site: http://www.jobs.com. You need to make sure
that all requests sent to sites that are categorized in Blue Coat Web Filters Job Search category are
redirected to the Jobs website. Finally, you allow the use of News/Media websites.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 7: HTTP Details
Instructors Note: This chapter looks at HTTP in more detail to show how administrators can
use HTTP to redirect clients. You should use this opportunity to review the basic HTTP
concepts included in the BCCPA class. Aside from teaching the concepts included in the
chapter, ensure that you provide practical examples of how administrators use redirection,
authentication, and cookies to accomplish a business goal. This chapter is fundamental to
understanding how ProxySG appliance manages authentication in transparent proxy mode
(where HTTP 407 is not available).
As you learned earlier, 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.
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 use
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, or
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, authentication state, or simply to track the users
visits. As you will see, cookies are not the demon that many have made them out to be, and
actually can be useful to you. The ProxySG appliance uses redirection, cookies, and authentication
details are to provide authentication in transparent proxy deployment mode.
Note:
Portions of the following content are from RFC 2616. Copyright (C) The Internet
Society (1999). All Rights Reserved.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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+7735HVSRQVHV
Instructors Note: This slide introduces browser redirection. You do not have to spend a lot of
time on this slide, but make sure that students understand that all 3xx codes are redirection
codes, and that each code has a special purpose. Additionally, explain that 4xx codes indicate
an issue with authentication.
All HTTP 3xx status codes indicate some type of redirection. These codes are used to specify
alternative actions that the browser can take to complete 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 is usually
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 URI returned in the message.
Because browser redirection behavior did not meet the original RFC requirements, additional 3xx
response codes were added in HTTP/1.1.
All HTTP 4xx status codes indicate that there is an authentication issues. In this chapter, codes 401
and 407 are discussed. If a 401 response is returned, it mean that a client has sent authentication
credentials with the request, but those credentials are incorrect. A 407 response, however, means
that the content being requested requires authentication.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
301 Moved Permanently
6OLGH0RYHG3HUPDQHQWO\
Instructors Note: The 301 response indicates that a connection has been redirected and
that the requested resource has been moved permanently. Modern browsers can read a 301
response message and redirect the request automatically.
The 301 response code indicates that the requested content has been moved permanently. For
instance, you may 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/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
hyperlink 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.
When a user receives a 301 response, it means that the following has happened:
1.
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 requests http://www.somesite.com/page.htm, the client connects directly to

the newer location http://www.someothersite.com/newpage.htm.
Note:
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
302 Found
6OLGH)RXQG
Instructors Note: The 302 Found code is important because it is still widely used.
Concentrate on the fact that the code is intended for automatic redirection of Get and Head
requests only.
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. This response is cacheable if indicated by a Cache-Control or Expires
header field.
The 302 Found code was called Moved Temporarily in HTTP/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/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 hyperlink to the new location so the user
can access the content if browser redirection is not automatic.
In the above slide, the behavior is as follows:
1.
The user sends a request to http://www.somesite.com.
2.
The OCS responds, notifying the client that the URL requested was found on
http://www.someothersite.com/temppage.htm.
3.
When the user requests http://www.somesite.com/page.htm, the client connects cannot

connect to the newer location http://www.someothersite.com/temppage.htm but must
connect to the requested URL first.
Note:
The client cannot directly connect to the new URL location

http://www.someothersite.com/temppage.htm; it must verify if the original URL
still responds with a redirect or if the content is now available there again.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 the redirected

request
Requires the GET method
User agent must issue a GET request regardless of

the original request method
6OLGH7HPSRUDU\5HGLUHFW
Instructors Note: The 307 code is very similar to the 302 code so you must spend some time
explaining the similarities and differences. The key to discussing the 302, 303, 307 codes is to
make sure that students understand that browser behavior was supposed to follow the RFC,
but did not always do so, as was the case with the 302 code. The RFC states that browsers
should only redirect on a 302, if the original method was GET or HEAD. In practice, most
browsers automatically issued a new GET request, regardless of the original method. To
ensure that administrators can obtain the proper behavior, the 303 and 307 codes were
added. The 307 code triggers the behavior that some browsers erroneously applied to the 302
code. The 303 code is meant to replace the older 302 code.
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/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. Since 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 hyperlink to the new location
(particularly because the 307 code is new for HTTP/1.1 and early browsers might understand the
method).
The 307 status code is very similar to the 302 code. Why, you might ask, does the HTTP
specification include two codes that are essentially the same? The reason is that the popular
browsers did not implement the 302 behavior as specified in the HTTP/1.0 RFC; instead, they
behaved in a manner consistent with the new 303 status code. That is, browsers automatically
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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). Since 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
401 Unauthorized
6OLGH8QDXWKRUL]HG
Instructors Note: You do not need to spend a great deal of time on this slide. The 401 code
is used for connections that include authentication credentials that are wrong. If a client
attempts to connect to a secured resource, and include invalid credentials with the request, a
401 response will be returned.
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 www.a.com, to
respond to a 401 challenge from www.b.com.
In the example above, the steps that occur before a 401 response is sent are shown:
1.
2.
User asks for a URL.
a.
The OCS requests authentication from the client.
b.
The User Agent issues the same HTTP request; this time adds the requested
credentials.
User asks for a different URL.

a.
The OCS requests authentication from the client.
b.
The User Agent issues the same HTTP request; this time adds the requested
credentials.
Note:
The credentials used for one OCS cannot be used for another OCS but can be cached if
connecting back to the same URL.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
HTTP 407
6OLGH+773
Instructors Note: This slide introduces the proxy authentication code. The main point to
discuss is that this code is for proxy authentication, and not Web server authentication. These
two levels of authentication can be a complicated subject but you should just make sure that
students understand the general concepts here.
The 407 Proxy Authentication Required code is used to authenticate clients to a proxy. According
to RFC 2616, The ProxySG appliance MUST return a Proxy-Authenticate header field containing
a challenge applicable to the ProxySG appliance 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 ProxySG appliance after receiving a client request that does
not have the proper authorization credentials.
1.
2.
Client asks for a URL; this is the first connection to the ProxySG appliance for that browser
instance.
a.
The ProxySG appliance responds asking for authentication.
b.
Client requests same URL but this time adds the credentials requested.
User asks for a second URL (within the same browser instance). Since it knows of the ProxySG
appliance, which requires authentication; the client issues the request already using the
necessary credentials.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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&RRNLH)XQGDPHQWDOV
Instructors Note: This is a very important slide so be sure to take your time covering the
concepts. Students must understand that cookies were created to make up for the fact that
HTTP does not maintain state. Though most students may understand the concept of state, it
is worth describing again. State is simply remembering the details of a transaction from one
request to another. Maintaining user information for hundreds or thousands of users at the
same time would put an incredible load on the server and is not feasible. Cookies allow
servers to remember users by shifting the burden to the browser, which keeps a unique bit of
information that identifies the user. This information has come to be known as a cookie.
HTTP is a stateless protocol, which means that it does not keep track of information from one
request to the next. For example, when you access protected content, the client must authenticate
to the server for every request the server does not remember that it already authorized you.
Cookies were created to keep track of just 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 user's previous reading affects which
offerings are presented.
Cookies were first introduced by Netscape in 1994 and codified by the IETF 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 may terminate a session.
4.
The session is implicit in the exchange of state information.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Cookie Fundamentals
Instructors Note: This slide illustrates the cookie-setting process. Ensure that students
understand that the Set-Cookie header is just another header added to the HTTP response.
The next slide describes the Set-Cookie header in more detail.
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.
Slide 7-8 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.
A common use of cookies is keeping track of online selections. For example, when you add items
to an online shopping cart, the server is able to keep track of your selections from page to page.
Often, the state information is not contained in the cookie; the cookie includes information that
points to a database entry containing the information.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Cookie Fundamentals
Set-Cookie: PREF=ID=c295f06bd13033fd:
TM=1111377507:
LM=1111377507:
S=bL0B-I8g3qIBK1Cs;
expires=Sun, 17-Jan-2038 19:14:07
GMT;
path=/;
domain=.google.com\r\n
Instructors Note: This slide gives students a better idea of how an actual cookie is set.
Focus on the Set-Cookie header and optional attributes. If you have time, go over the ways
that the domain and path attributes are used, as these can be used to restrict the places a
cookie is used.
Slide 7-9 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 will 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?
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Cookie Security
Protocol Security
Cookie accepted only for 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&RRNLH6HFXULW\
Instructors Note: This slide is interesting because it addresses some of the security
concerns that users have had about cookies. Admittedly, some companies (like DoubleClick)
have used cookies to track users Web activity. However, many of the Web features that
everyone now takes for granted depend on cookies.
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 will have its own list of cookies. (This list
is called a cookie jar.) Thus, if a user visits a Web site using Netscape and then visits it again using
Internet Explorer (IE), the Web server will 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, each user will have his or her own cookies.
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 his or her browser. Most browsers now allow users to delete
cookies, refuse them, or to set explicit expiration times.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for VPM HTTP Redirection and VPM Setting

Cookies Labs
Overview
In this lab you understand how HTTP redirection works. You also understand how a cookie is set.

Software
Version
F FireFox
F version 2.0.0.5
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 8: Using Authentication In Transparent Proxy Mode
Instructors Note: This is definitely one of the most complex chapters that you have to teach
in this course. Spend as much time as you need repeating the details and steps of the origin
cookie redirect authentication. You need to start the class by pointing out that authentication,
in transparent proxy mode, is very challenging. The user agent cannot accept an HTTP 407
response for the Blue Coat SG. The user agent is not aware that it is talking to a proxy to
begin with, so proxy style authentication cannot be used. Furthermore, you cannot ask users
to re-authenticate every time they access a new resource (i.e. Web site) on the Internet.
Refer back to the HTTP chapter. Point out the following key aspects of cookies:
Cookies are designed to create state in a stateless protocol like HTTP.
Cookies can be accepted by the user agent only for the domain from which they come.
Finally, remind the students of the effects of HTTP redirection and the modus operandi of
HTTP 401 response code.
Important: Make a clear distinction between user (a human being) and the user agent (a
piece of software).
This chapter discusses the complex details of authentication for transparent proxy deployments.
You should already be familiar with how the ProxySG authenticates users when it is deployed in
explicit mode. In essence, the HTTP protocol 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). Unfortunately, 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).
The HTTP protocol 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 server to authenticate user agent requests
Because 407 is not an option, the ProxySG can only issue a 401-style authentication challenge;
unfortunately, the 401 authentication is resource-specific. From the user agent point of view, a
successful authentication to a 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 re-issued only for the
www.cnn.com domain. When the user agent makes a subsequent request to
http://www.google.com, if it receives a HTTP 401 response it will 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
a HTTP 401 challenge. Because this type of authentication is resource-specific, the ProxySG
redirects all 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, as you learned in the previous sections, 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 completely different.
The ProxySG uses session-based cookies or, alternatively, persistent cookies, to cache the
authentication information and not challenge the user agent for authentication.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Transparent Proxy Authentication

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

Use HTTP 401 authentication
Cache Authentication Information
Avoid challenging the user agent multiple times
6OLGH&KDOOHQJHVLQWUDQVSDUHQWSUR[\DXWKHQWLFDWLRQ
Instructors Note: Use Slide 8-1 to describe and reiterate what appears in the introduction
section under the instructors note. The fundamental challenge for the ProxySG is to
authenticate the users in a scenario where HTTP 407 is not available, without the user
receiving multiple authentication requests. Show the users what happens if you use Origin
Cookie authentication versus Origin Cookie Redirect.
Slide 8-1 summarizes the concepts outlined in the introduction to this chapter. The ProxySG
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 will reject the request as invalid. The
user experience is that the browser immediately shows the authentication failed exception page.
The URL shown is the one of the requested origin content server, as shown in the screen capture
below.
Figure 8-1: URL of requested OCS
The only alternative is to use the HTTP 401 response, in order to trick the user agent into
supplying the authentication credentials.
Since 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Surrogate
Redirection
401 can authenticate only one resource at the time
Cookie Surrogate
Successful authentication associated to a cookie
IP Surrogate
Success authentication associated to the

IP address of the UA
6OLGH$XWKHQWLFDWLRQVXUURJDWHV
Instructors Note: Slide 8-2 introduces the concept of authentication surrogate. Start by
telling the students that the default authentication surrogate in an explicit proxy deployment is
the TCP session. The ProxySG authenticates the TCP session; as long as that session is
alive, re-authentication is not necessary. In transparent proxy mode, there is no TCP session
with the ProxySG (as far as the user agent is concerned); the only alternatives are cookies
(which are not always possible) or IP addresses (which present several issues, such as NAT,
TTL, accuracy, etc.). Make sure that you cover all of the advantages and disadvantages of
each approach; at a minimum discuss the ones listed in the student section. You should
discuss some customer experience on this topic (either your customers or your students
experience).
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 when if
a user has already been authenticated.
The ProxySG uses the concept of surrogates. The idea is to assign the authentication flag
(authenticated vs. not authenticated) to a surrogate; because TCP session is not a viable one, 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 has already 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 any other URL,
which 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The requirements are pretty self-explanatory. 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 request 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.
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 organization, cookie surrogate is a viable option. Even if you allow
the use of cookies in your company, 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, which do not support cookies and do not have a provision to support
cookies. In this case you need to find some work-around 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 / Terminal Server environments.
Origin cookie redirect has the following disadvantages:
Cookies are not always allowed by company 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 surrogate. In this case, the ProxySG
associates the successful authentication to the IP address of the client from where the request is
coming. IP surrogate is conceptually much easier and lightweight than cookie surrogate. However
the main disadvantages of IP surrogate are:
Authentication credentials are associated to the same IP address for the pre-set TTL time; if
multiple users log on the same IP they cannot be separated.
Requests coming from a NATed IP address are all associated to one user.
It does not support Citrix / Terminal Server 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Cookie Surrogate Authentication
6OLGH&RRNLHVXUURJDWHILUVWDXWKHQWLFDWLRQ
Instructors Note: This slide is usually intimidating. Go over it very slowly. Repeat the steps at
least twice. There are four major steps:
1. The user agent is being redirected and challenged for authentication by the ProxySG.
2. The authentication credentials supplied by the user agent are validated by the
authentication server.
3. The user agent receives the authentication cookies for both the virtual URL and the
destination URL.
4. The ProxySG finally retrieves the content and serves it to the requesting user agent.
After you describe the details of this process, you need to show the Live HTTP Headers trace
in Firefox. Use a relatively simple site like http://www.google.com and an LDAP realm. Remind
the students that NTLM is a challenge/response, multistep authentication process; showing
origin cookie redirect authentication with and NTLM realm is confusing.
You should also show what the different query string parameters contain. You need to have a
base64 converter.
Note: When you are decoding the query string in Step 3, decode only the part after the !
character.
Slide 8-3 shows the sequence of actions that are necessary when a user is first challenged for
authentication in a transparent proxy deployment. Slide 8-4 shows the steps for further user
requests after the first authentication challenge, and Slide 8-5 details what happens then a user
accesses a site that was already visited after the initial authentication.
Note:
Slide 8-3 shows the interaction for an LDAP realm. NTLM authentication, because of
its challenge/response nature, requires more steps.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 the HTTP
protocol.
6.
The ProxySG returns a new redirect request to the user agent. At this point, since 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, ProxySG creates a way to remember that the user
has already authenticated when a new site is being requested. See Slide 8-4 for more details.
7.
The user agent opens the connection to the original URL; note the additional query string that
is included.
8.
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 being requested again.
See Slide 8-5 for more details.
9.
The user agent performs the redirection. Since the cookie is received and accepted, the request
contains the authentication cookie. This cookie notifies the ProxySG that the request has
already been authenticated.
10. Finally, the ProxySG forwards the user agents request to the http://www.bluecoat.com URL,
after it has removed the authorization cookie because it may interfere with the transaction.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
6OLGH&RRNLHVXUURJDWHVXEVHTXHQWUHTXHVWV
Instructors Note: This slide describes what happens when the user requests a new site,
which was not previously visited, after the initial authentication. The process was detailed in
Slide 8-3. The key point of this slide is that Step 4 and Step 5 are missing. Point out that now
in Step 3 the initial GET request to the virtual URL contains the authorization cookie. This is the
reason that Steps 4 and 5 are no longer necessary.
In the Slide 8-4, you can see the interaction between the user agent and the ProxySG when the user
agent has already authenticated to the ProxySG, but it is now requests a different site from the one
used to authenticate. Slide 8-4 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
authorization cookie when making a GET request to the virtual URL, as shown in
the slide.
When a user agent is already authenticated, the ProxySG does not need to issue a HTTP 401
response; as matter of fact, in the diagram above you can clearly see that Step 4 and Step 5 (as
described in Slide 8-3) are missing.
If this is the first time that the user agent is asking for this domain, it cannot present and
authorization cookie for that domain; for this reason, some redirections are still occurring.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
6OLGH&RRNLHVXUURJDWHUHWXUQWRDSUHYLRXVVLWH
Instructors Note: This slide describes the interactions between the ProxySG and an
authenticated user agent when the latter is making a request for a URL that has been already
visited the requested URL. Point out again the definition of authenticated user agent as
described in the previous page.
Slide 8-5 clearly illustrates the simplicity of the authentication mechanism for requests to sites that
the user has already 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 Slide 8-5, there is no communication
between the ProxySG and the authentication server.
In an environment using NTLM authentication with BCAAA, you can actually see less load on the
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 expire. 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/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, Internet Explorer defaults to HTTP/1.0. HTTP/1.0 does not support
persistent connections. As a result, many more authentication requests are sent to the BCAAA.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
IP Surrogate Authentication
6OLGH,3VXUURJDWH
Instructors Note: You need to point out that IP surrogate may lead, even if rarely, to users
being associated with someone elses traffic. However, it is important to be able to support IP
surrogate, as many user agents do not understand cookies. Point out that this is not a feasible
solution for users behind a NATing device.
IP surrogates can be very useful in scenarios where cookies are not available or are simply
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 on and start browsing;
he is challenged for authentication. If user B logs on the same machine 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 may be infrequent, but you should be aware of it.
In Slide 8-6, you can clearly see how the transaction between the ProxySG and the user agent is
some what simpler, even for the first authentication request, than it was for the cookie surrogate
authentication. Delivering cookies is more complex than it may first appear.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: This section lists the different parameters that you can set for transparent
proxy authentication and what the parameter values mean. You should reduce the TTL for the
persistent IP authentication surrogate to 1 minute and show how the system reacts to it and
what the user experiences. Make sure that you access separate and different Web sties each
time you do the test. You should also clear browser cache and cookie jar, as well as the
ProxySG cache.
Slide 8-7 shows the parameters that you can define 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. If you select Cookie, Cookie Type radio buttons 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 0 (zero) for the IP address TTL re-prompts 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 re-challenges 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 any another client from potentially gaining network access by impersonating another
user by supplying his or her credentials. However, once the user credential cache entry's TTL has
expired you can supply a different set of credentials than the ones previously used for
authentication.
In this screen you can also control the value for 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 enables you to be sure that the correct ProxySG is addressed in a cluster
configuration.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
You can configure the same parameters using the CLI.

1.
At the (config) command prompt, enter the following command:

SGOS#(config) security transparent-proxy-auth method {cookie | ip}
Q 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:
SGOS#(config) security transparent-proxy-auth cookie {persistent
|session}
Q If you select persistent cookies, enter the following command to specify the minutes that
the cookie persists:
SGOS#(config) security transparent-proxy-auth time-to-live
persistent-cookie minutes
Q 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:
SGOS#(config) security transparent-proxy-auth time-to-live ip
minute
2.
To specify the virtual URL for cookie-based authentication, enter the following command:
SGOS#(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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Modes
TCP
connection
Surrogate
Origin
Challenge with
redirection
Form Challenge
with redirection
originorigincookie
formcookie
originorigin-cookiecookieredirect
form-cookie-redirect
origin-ip
form-ip
origin-ip-redirect
form-ip-redirect
Origin
Challenge
proxy
origin
Cookie
Surrogate
IP
Surrogate
Form
Challenge
Proxy
Challenge
proxy-ip
Explicit
Proxy
Reverse Proxy
Transparent Proxy
6OLGH$XWKHQWLFDWLRQPRGHV
Instructors Note: Slide 8-8 shows the different authentication modes, grouped by
deployment option, authentication mode, and surrogate type. The options that are in bold text
and underlined are the modes selected when the authentication is set to Auto.
The left column shows the surrogate types. Point out that TCP Connection is the preferred
one, for it guarantees correct user authentication at all times and works easily with virtually
any user agent. In explicit proxy mode, the default option is to authenticate users using TCP
connections; in transparent proxy mode, the default option is to authenticate users using origin
cookie redirect. In reverse proxy deployments, you should always select the particular
authentication option that you intend to use (origin cookie is recommended). It is difficult for
the proxy to exactly determine that it is operating in reverse proxy mode, rather than in forward
proxy mode.
The different selections are available from the VPM, when you set an Authenticate or Force
Authenticate action in the Web Authentication Layer. You should go over this slide and the
show the VPM and the different options available.
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.
Note:
Challenge type is the kind of challenge (for example, proxy or origin-ip-redirect)

issued. Surrogate credentials are credentials 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
will not work; origin challenges are then issued.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 will not work; origin
challenges are then issued.
Origin: The ProxySG acts like an OCS 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 origin server and issues origin server 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 and HTTPS protocols support cookies; other protocols are automatically
downgraded to origin-ip. This mode could also be used in reverse proxy situations if
impersonation is not possible and the origin server 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. Note that the ProxySG does not support
origin-redirects with the CONNECT method.
Form-IP: A form is presented to collect the user's credentials. The form is presented whenever
the user's credential cache entry expires.
Form-Cookie: A form is presented to collect the user's 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 user's 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 on a multi-user system,
this can present a serious security problem.
The default value is auto. The values that appear underlined and in bold text in the Slide 8-8,
represent the authentication mode that the ProxySG selects, based on the deployment, when auto
is selected as authentication mode.
Note:
ProxySG cannot easily distinguish between explicit forward proxy requests and
reverse proxy requests. If your ProxySG is operating in reverse proxy mode, you
should not use auto, but select the authentication mode that you prefer.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Transparent Mode Proxy Authentication Lab

Overview
You should show the details of the transparent authentication mechanism using Firefox live HTTP
headers, Notepad, and a base64 decoder. You can find a base64 decoder at
http://makcoder.sourceforge.net/demo/base64.php. Follow the steps below:
1) Configure your system for transparent proxy.
2) Enable authentication using an LDAP realm (ADS with LDAP ok).
3) Clear browser cookie jar, cache, and clear the ProxySG cache (Management Console >
Maintenance > General > Clear the system cache).
4) Start live http header.
5) Go to http://www.google.com.
6) Enter your authentication credentials; do not use your own secure password because it will
appear in clear text.
7) Copy and paste the trace in the live http headers in Notepad.
8) Analyze one query string at the time and decode it with base64 decoder.
Point out clearly to the students that the password appears in clear text because that is the
expected behavior of basic authentication, as defined in the HTTP RFC. It is not a weakness or
vulnerability of the ProxySG.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F Wireshark
F verion 0.99

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F Wireshark
F version 0.99
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 9: Understanding Kerberos Authentication (Optional)
Instructors Note: The goal of this chapter is to explain Kerberos authentication in general
terms. If the students understand how the authentication works, they can better grasp how to
set up the Blue Coat SG. Kerberos configuration for the ProxySG may seem complex. You
need to use this chapter to make sure that the students understand that the relative difficulty of
enabling Kerberos has to do with how the protocol works and is not a ProxySG issue. You
should be able to show a packet capture of the transactions happening between the different
parties involved in the authentication process. More information is available in the lab. This
chapter discusses the Kerberos authentication as it is implemented in Microsoft Active
Directory, which is not necessarily the same as RFC 1510 or the same as MIT Kerberos v5.
The introduction of RFC 1510 says, Kerberos provides a means of verifying the identities of
principals, (e.g., a workstation user or a network server) on an open (unprotected) network.
Since its inception, 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 NTLM (or LAN
Manager) model. The single biggest difference between the two is that in the Kerberos model,
neither server nor clients are assumed to be trusted a priori. Both the client and the server need to
trust a third entity, which 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 (i.e., a file server or Web server).
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
What is Kerberos?
Three-headed dog guardian of the underworld

in Greek mythology and Dantes Inferno (Cerberus)
Secure and high-performance mutual authentication

protocol designed by M.I.T.
Three main components
Client
Server
Trusted third party
6OLGH.HUEHURVEDFNJURXQG
Instructors Note: This slide introduces the basic concepts in Kerberos. The name of the
mythological three-headed dog is appropriate because there are three components necessary
to implement this authentication protocol. Point out that the Microsoft implementation of
Kerberos may not follow exactly the same parameters as the original MIT version.
You need three components in order to implement Kerberos authentication in your network.
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.
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 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
NTLM vs. Kerberos

NTLM
Kerberos
Servers need to authenticate

users to the DC
Servers authenticate users

using credentials presented
Servers are assumed always

to be trusted and genuine
Neither servers nor clients are

trusted a priori
Need to build point-to-point

trust relation between domains
The trust relations are transitive;

all members are trusted
Proprietary protocol
Standard based on M.I.T

Kerberos version 5
6OLGH'LIIHUHQFHVEHWZHHQ17/0DQG.HUEHURV
Instructors Note: This slide is designed to help student transition from the authentication
model in NTLM to Kerberos. Go over each point and try to explain the differences. For
instance, spend some time reminding the students how, in the NTLM model, authentication
credentials are always validated against a DC: The DC receives many authentication
requests. Kerberos uses a different approach (which will be explained later). Clients can
authenticate servers; this option is not available in NTLM. This provides a higher level of
security and prevents spoofing attacks. Finally, use the idea of transitive trust to explain why in
AD, the trusts are by default two-way (native mode only).
Kerberos represents a final break from the old and relatively insecure NT LAN Manager
authentication protocol. If you have an AD forest in native mode, NT LAN Manger is disabled.
Three of the major improvements in Kerberos authentication are:
Increased security
Kerberos uses session keys that have a short time to live between client and server.
Authentication requests are validated using a timestamp verification to prevent reply attacks.
Kerberos uses a stronger cipher than NTLM.
Fewer authentication requests must go through the KDC (DC)
Clients obtain tickets to present to the server. The server does not need to contact the KDC to
authenticate a client.
Clients can authenticate the server they need to access
Mutual authentication is possible with Kerberos. A client can ask a server (or service) to verify
a timestamp message. The message is encrypted with a key that only the KDC and the server
should know. If the server can decrypt the message and show it to the client, then the server is
what it claims to be.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Basic Concepts
Two parties know a shared session key

Knowledge of the key confirms identity
Deliver the key securely among partners
Kerberos partners share cryptographic key
Requires symmetric keys

Need for long-term key for secure data exchange
Derived from the users password
6OLGH%DVLFFRQFHSWV
Instructors Note: This is where you need to start diving into Kerberos. You can try an
analogy with digital certificates and PKI but you need to be careful: Kerberos is not a PKI! An
important concept in this model is the use of a key to encrypt a message containing another
key (session key). You can associate the long-term key with the public/private key pair, and
the session key then plays a similar role in both models. The client and the server trust each
other based on the fact that they share the same session key, which was generated by the
KDC.
In Kerberos, the client can connect to the server by presenting proper credentials to the server
where it wants to authenticate. These credentials are obtained from the KDC. The client issues a
request to the KDC for authentication to a given service; if the client request is approved, then the
KDC sends a special message back to the client. This message is called a ticket. The ticket consists
of two parts: One is encrypted with a session key shared between the client and the KDC; the other
is encrypted with the servers long-term key, which is known only to the KDC and the server. (The
client cannot read this area of the ticket.)
The client can extract, from the first part of the ticket, the session key for communication with the
server. The session key is generated by the KDC. A copy of the same session key is stored by the
KDC in the second part of the ticket (encrypted with the servers long term key).
Important: The long-term key is a one-way hash of the users password.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Ticket Structure
6OLGH.HUEHURVWLFNHW
Instructors Note: The screen capture above shows the field structure of a Kerberos ticket
and also an Ethereal packet capture. Note that this is the ticket that the client presents to the
server; this is not the ticket that the client received from the KDC. You can easily replicate this
packet capture: this is the authentication ticket that the IE browser sends to the ProxySG in
response to an HTTP 401 message.
The slide above shows clearly how the ticket (in this case the one the client presents to the server)
is divided in two parts. The first part is in clear text. 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. The table below summarizes the description of each field and
its status.
Table 9-1: Main Ticket Fields
Encrypted
Field Name
Description
No
TKT-VNO
This is the protocol version. Kerberos v5 is the one used here.
No
REALM
Contains the name of the realm where the client authenticated. This
is the same as the server realm; a KDC issues tickets only for server
in its own domain (realm).
No
SNAME
Servers name
Yes
FLAGS
1 bit field (32 byte space, only 9 allocated) each flag can be set to
ON (1) or OFF (0)
Yes
KEY
This is the session key shared by the client and the server.
Yes
CREALM
This is the realm where the client is located. This can be different
than the one of the server. (See Slide 9-9.)
Yes
CNAME
Clients name
Yes
AUTHTIME
Timestamp of the clients initial authentication to the KDC
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Key Distribution Simplified
6OLGH6LPSOLILHGNH\GLVWULEXWLRQPRGHO
Instructors Note: This slide does not represent how Kerberos really works. You need to
make it very clear to the students that this slide is a great simplification of the process. The
slide depicts is a logical flow of data, rather than an actual one. The next slide describes the
process more accurately.
This slide simplifies the Kerberos authentication and describes it from a logical rather than
functional standpoint.
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, the 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.
Note:
The reduced need for communication between the client/server and the KDC (DC) is
one of the main advantages of Kerberos over NTLM.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Session Tickets Actual
6OLGH$FWXDONH\GLVWULEXWLRQPRGHO
Instructors Note: This slide represents the model more accurately than the previous slide.
The main difference is that the KDC never sends the ticket with the session key directly to the
server but sends two pieces of information to the client. Point out the difference and proceed
to the next slide.
The previous slide shows the KDC generating two tickets and sending one to the client and the
other to the server. Logically you can assume that is the process; however, in reality, the KDC does
not send any information to the server.
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 in two parts:
Q The client part, in which the session key is encrypted using the clients long-term key
Q The server part, in which the session key is encrypted using the servers long term-key
3.
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 only read the first, or 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.
You can easily see how 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Service (AS)
6OLGH$XWKHQWLFDWLRQ6HUYLFH
Instructors Note: At this point you need to start detailing the fact that there are actually two
types of tickets: a ticket granting ticket (TGT) and a ticket granting service (TGS). Furthermore
you need to clarify the fact that the client and the KDC will use the client long-term key only
once in a selected (configurable) period of time.
Before discussing the details of the role of the Authentication Service (AS), it is necessary to clarify
that the Kerberos process uses two different types of tickets. The client obtains the first ticket when
it first logs on 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 AS assigns a TGT to the client. The client uses the information in the TGT to obtain a TGS. By
now, you should be able to imagine how the process works:
1.
The client connects to the KDC1 and requests a TGT.
2.
The AS responds with a TGT which consists of two parts:
Q A session key encrypted with the clients long-term key

Q A session key encrypted with the KDC long-term key
3.
The client connects to the KDC, using the session key, to request a TGS. In essence you need to
change the phrase encrypted using the clients long-term key on the previous page, with the
phrase encrypted using the session key.
Now that the difference between TGT and TGS is clear, it is time to detail the authentication steps
and explore some more of the unique security features of Kerberos authentication.
George wants to authenticate and obtain access to a certain service; this is how the process flows:
1.
George logs on by entering his username and password.
2.
The Kerberos client on his machine generates the long-term key, which is a one-way hash
function applied to the password.
1. The AS is one of the roles that the KDC assumes in the Kerberos model.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
3.
The request for a TGS is sent to the KDC. It contains:
Q Username (George in this case)

Q Service name for which the TGS is being requested
Q Logon timestamp encrypted with the clients long-term key
4.
The KDC receives the request and looks up Georges long-term key.
5.
The KDC decrypts timestamp.
6.
The timestamp is verified and must be within a certain tolerance value or the request will be
discarded a tentative reply attack.
7.
The KDC sends George the TGT, which includes the session key for George to talk the KDC,
and the TGT encrypted with the KDC long term key (which contains the same session key).
Note:
Georges long-term session key is used only during the initial request to the KDC.
Once George receives the TGT, it will use the session key for any further
communication with the KDC.
Note:
It is Georges responsibility to manage the session keys both with the KDC and the
server. Neither the server nor the KDC keep any memory of the session key.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Ticket-Granting Service
6OLGH7*67LFNHW*UDQWLQJ6HUYLFH
Instructors Note: Use this slide to clarify once and for all that the KDC has two
subcomponents to it:
The AS, which is the Authentication Service (issues the TGT)
The TGS, which generates tickets to access the service that the client requested.
In this slide, the client has already authenticated using the AS and now is requesting access to
a file server. The TGS generates the proper ticket and sends it to the client.
The client needs to have a valid ticket to access a certain resource on the Internet. In this case you
can assume that the client wants to access a file server. The client has authenticated already and it
received the TGT from the AS component of the KDC.
Three steps are necessary for the client to access the file server:
1.
The client sends a request to the TGS component of the KDC. The request contains the TGT
that the client received from the AS. In essence, the request sent by the client is encrypted
using the session key obtained from the AS at the logon time.
2.
The TGS component sends a session key back to the client separated in two components:
Q A session key encrypted with the session key shared between the client and the KDC
Q A session key encrypted with the file servers long-term key
3.
The client connects to the file server presenting the ticket it obtained from the TGS. Because
the ticket is encrypted with the file servers long-term key, which only that server and the
KDC know, the client request is accepted as genuine (of course assuming that the file server
can correctly decrypt the ticket).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Multiple Domains
6OLGH5HIHUUDOWLFNHWV
Instructors Note: This slide allows you to introduce and explain the concept that trust
relationships in AD are transitive. (If Domain A trusts Domain B, and Domain B trusts Domain
C, then A and C trust each other as well.) The explanation should be rather simple at this
point. The key concept is in the inter-domain key, which is created when the trust relation is
originally created. This is very similar to a session key between a client and a server. Using
this angle, it should be rather easy to explain this concept.
Users in one domain can access resources in another domain, as long as there is a path of trusts
between the two. In the scenario illustrated above, the client in Domain A wants to access a file
server in Domain B. You can extend the scenario to something more complex as the one shown in
the figure below.
Figure 9-1: Path of trusts
A client in the london.emea.bluecoat.com domain can access any resource in the other domains,
all the way to apac.bluecoat.com domain, which is the most remote.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 that you
have encountered so far.
When a trust relationship is created, a session key is created and shared between each domain
pair. For instance, in the diagram above, there is a session key between london.emea.bluecoat.com
and emea.bluecoat.com, another one between emea.bluecoat.com and bluecoat.com, and finally a
third one between bluecoat.com and apac.bluecoat.com.
In the example illustrated in the slide:
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.
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:
Q A session key encrypted with the session key shared between the client and the KDC in
Domain B
Q A session key encrypted with the file servers session key, which it shares with the KDC in
Domain B
5.
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.
Note:
If there are N intermediate domains between the client and the server, the process
operates virtually in the same way. Steps 3 and 4 are repeated N-1 times.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Service Principal Names (SPN)

SPN identifies a service
Once the service is identified you can authenticate to it
Must be unique in a forest
One SPN is associated with only one account
You need to match a SPN with an Active Directory

account (you can use LocalSystem account)
6OLGH6316HUYLFH3ULQFLSDO1DPHV
Instructors Note: The concept of SPN is extremely important in understanding how to

configure and set up the ProxySG to support Kerberos authentication. Spend some time on
this.
The Service Principal Name (SPN) represents a service that is available for Kerberos
authentication. Only services listed as SPN are available for users/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 SPN in a domain (forest). You can execute the command as shown below
and obtain a list of the options available.
c:\Program Files\Resource Kit>setspn [Enter]

Usage: setspn [switches data] computername
Where "computername" can be the name or domain\name
Switches:
-R = reset HOST ServicePrincipalName

Usage:
setspn -R computername
-A = add arbitrary SPN

Usage:
setspn -A SPN computername
-D = delete arbitrary SPN

Usage:
setspn -D SPN computername
-L = list registered SPNs

Usage:
setspn [-L] computername
For instance, if you have setup a new Web server and you want to use Kerberos authentication,
you need to add it as SPN to the domain where you registered it.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 10: Using Kerberos Authentication
Instructors Note: This chapter focuses on configuring the Blue Coat SG and Blue Coat
Authorization and Authentication Agent (BCAAA) to support Kerberos authentication. Before
you get into the details of the Blue Coat implementation, review the fundamental details of
Kerberos authentication separately from Blue Coat. Verify that the students are familiar with:
The concept of Service Principal Name (SPN) and why you need to create an SPN
The difference between TGT and TGS
Direct authentication between parties in Kerberos, which does not require KDC intervention
If your students are familiar with these concepts, this chapter will be an easy one. Remind the
students that, at any time, the Windows authentication subsystem may decide to downgrade
to NTLM.
The previous chapter discussed the details of Kerberos authentication apart from the ProxySG. In
this chapter, you will explore the system requirements and configuration necessary to support
Kerberos authentication with the ProxySG.
There are several constraints, independent from the ProxySG, that come into play when you
decide to use Kerberos authentication. Kerberos authentication requires:
That the ProxySG be deployed in transparent proxy mode
That Internet Explorer version 6 is the user agent (UA)
The configuration of the Blue Coat Authorization and Authentication Agent (BCAAA) and the
Integrated Windows Authentication (IWA) requires you to follow some rigorous steps.
Unfortunately, the Windows authentication subsystem may decide to downgrade from Kerberos
to NTLM without warning. The chapter gives you some hints on how to verify that the UA and
the ProxySG have successfully negotiated and carried out Kerberos authentication.
If you want to have one or more than one BCAAA machine, you need to make a planning
decision; configuration steps vary depending on the choice you make. Because an SPN can be
associated only with one AD account, running more then once 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 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 AD
server.
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, you receive a
configuration error.
Important: You cannot enable only Kerberos support in an IWA realm. An NTLM challenge
will always be offered as a potential alternative to Kerberos.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
General Information
Requirements
SGOS 4.2.x or higher

BCAAA-100 or higher
Internet Explorer 6.x or higher
Transparent proxy deployment
Authentication Modes
Origin-*-redirect (full support)

Origin-* (limited support)
6OLGH6\VWHPUHTXLUHPHQWV
Instructors Note: This is an important slide. You need to clarify the system requirements to
implement Kerberos. Be sure to tell students that IE 7.0 has not been tested and is, at the
moment, not supported. Also quickly remind students of the steps involved in the transparent
authentication and what origin-cookie-redirect means.
Kerberos authentication was introduced in SGOS version 4.2.1.1; earlier versions of SGOS only
support NTLM authentication. The BCAAA for version 4.2.x is not backward compatible, and
earlier versions of BCAAA cannot work with SGOS 4.2.x. The realm name is IWA; Kerberos is one
of the available options.
The two most important requirements are:
The ProxySG must be deployed in transparent mode (bridging, WCCP, Layer 4 switch, default
gateway).
The UA must be Internet Explorer 6.x.
The authentication mode can be set to either origin-cookie-redirect or origin-ip-redirect; limited

support is available for origin-* modes. These modes are more difficult and are only supported in
some situations. 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, the BCAAA can
presumably know the secret (since the ProxySG is impersonating the host with its permission).
However the, the ProxySG cannot impersonate an arbitrary host.
The SGOS will automatically downgrade the authenticate.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 may
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 the BCAAA does not
know the server's secret and disables Kerberos (for that transaction at least).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
General Information
Virtual URL
Define a suitable host name

Update DNS and WINS to resolve it to the Blue Coat SG
Installation of BCAAA
Register the machine as SPN
Realm Configuration
Create IWA realm (includes Kerberos)

Edit upgraded NTLM realms to add Kerberos support
6OLGH,QVWDOODWLRQVWHSV
Instructors Note: Remind the students what an SPN is and why you need to create an SPN
for the virtual URL on the BCAAA machine. You need to have Domain Admin permissions in
order to create the SPN. Upgraded NTLM realms do not have Kerberos authentication
enabled.
Before you do anything else, you need to define the virtual URL for the IWA realm. The virtual
URL must be a simple hostname or a fully qualified domain name that follows the rules on the
first page of this chapter. It must also resolve to the IP address of the ProxySG. Once you have
selected a suitable name for the virtual URL and you have created the necessary entries in your
DNS and WINS servers.
Once you have defined the virtual URL, you can register the SPN for that URL and associate it
with the BCAAA machine (or the account under which BCAAA agent is running; see page 160
and page 161 for more information on this topic).
Finally, you can create and configure the IWA for Kerberos support. If you created the realm as an
IWA realm, Kerberos is enabled by default. If you upgrade an existing NTLM realm, Kerberos is
disabled and you need to turn it on manually.
You can verify the Kerberos settings through the Management Console. Select Configuration >
Authentication > IWA > IWA General and then choose the appropriate realm name from the list.
Figure 10-1: Verifying Kerberos settings
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Single BCAAA
6OLGH6LQJOH%OXH&RDW$XWKRUL]DWLRQDQG$XWKHQWLFDWLRQ$JHQW
Instructors Note: This is the simplest way of deploying BCAAA to support Kerberos
authentication. You only need to execute the correct setspn command. You can use all of the
default settings during the BCAAA installation and you do not need to perform any
post-installation steps.
If you plan to have only one BCAAA machine, then the SPN can be registered with the NetBIOS
name of the machine 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 (KDC) 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 you need to execute the command:
setspn -A HTTP/FQDN-of-host <name>, where <name> is the name of the machine (e.g.,
setspn -A HTTP/sg.bluecoat.com bcaaahost)
Note that the handling of the shared secret is done by Windows when the machine joins the
domain; there is no explicit knowledge of the shared secret by SGOS or by BCAAA.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Multiple BCAAAs
6OLGH0XOWLSOH%OXH&RDW$XWKRUL]DWLRQDQG$XWKHQWLFDWLRQ$JHQWV
Instructors Note: You can easily use two different BCAAAs, one as the primary agent and
the other as the secondary agent. Because the SPN can be associated only with one account,
you cannot run the BCAAA under the Local System account. You need to create an AD
account and run the service on all the BCAAA machines under this account. The lab will cover
the additional setup steps that are necessary to implement Kerberos authentication.
You can have more than one machine running BCAAA. You can, in fact, have a primary and a
secondary BCAAA server.
In this scenario, you need to create a service account for the BCAAA service 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 machines. 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 regular user account on the Active Directory server for the purpose of using it by the
BCAAA service.
2.
Give it a password.
3.
Install BCAAA as normal.
4.
Open the properties panel for the BCAAA service, and select the Log-on tab. Change the
account to the one you created in Step 1, and enter the password. When you hit OK, it may
warn you that the account has been given logon as service privileges.
5.
Verify in Local Security Policy's User Rights Assignment folder, that the above-mentioned
user account has been added to the list of the Log on as a service policy.
6.
The user must have modify/write privileges in the BCAAA folder.
7.
If group-based authorization is being done, then:
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Q Ensure that the user impersonation privilege is set for the SERVICE group. This URL gives
more information on how this is to be done:
http://support.microsoft.com/default.aspx?scid=kb;en-us;831218.
Q Ensure that the Active Directory computer account running BCAAA has the Trust
computer for delegation configuration property enabled.
8.
For all users that are authenticating to the ProxySG using IWA realms, their user accounts in
the Active Directory must have the permission to log onto the machine on which the BCAAA
server is running. This is a setting on the user's account properties. In the account tab is a
button called Log On To. Clicking on that specifies the domain computers can log onto.
The default is All computers. However, if your network setup is to restrict users to only log
onto specific computers in the user's list, then each of those users will need to also have the
name of the host running BCAAA added to this list.
9.
Run setspn -A HTTP/FQDN-of-host <name>, where <name> is the name of the account
created in step 1 (e.g., setspn -A HTTP/sg.bluecoat.com bluecoat\bcaaa)
All these machines now share the same secret with the KDC, and can decrypt service tickets
intended for the service described by the SPN.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Steps Kerberos
6OLGH$XWKHQWLFDWLRQVWHSV.HUEHURV
Instructors Note: This slide offers a high-level overview of the authentication steps that go
on between the ProxySG and the client when a successful Kerberos based authentication is
taking place. There are three important things that you need to point out to the students:
1) The 401 response must have the NEGOTIATE option. (NTLM and BASIC may also be
present.)
2) There is only one 401 response sent by the client. If you see two, then the system has
downgraded to NTLM. (See page 164 for more details.)
3) The NEGOTIATE reply from the client contains the GSS_API value.
Kerberos authentication requires transparent authentication. In order to successfully authenticate

users in this scenario, the ProxySG redirects all requests to a virtual URL. The client is under the
impression that it is authenticating into the virtual URL and not into a proxy server. (401
authentication is used and not 407.)
If the server (in actuality the ProxySG) supports Kerberos authentication, the 401 response shows
the option NEGOTIATE. Only if your UA receives this header, Kerberos authentication may take
place. The NEGOTIATE header is necessary but not sufficient condition for the process to
complete successfully.
Your UA should reply with the NEGOTIATE value set in the authentication field. If the
authentication subsystem on the client end has accepted the Kerberos authentication, it uses the
GSS_API option in the authorization request that sends to the virtual URL. This is a necessary and
sufficient condition for Kerberos authentication to complete successfully (provided that the
credentials are valid).
The 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
easily see that only one 401 response is sent back to the client by the ProxySG (virtual URL). If you
can see two 401 responses, then the authentication has been downgraded to NTLM.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Steps NTLM
6OLGH$XWKHQWLFDWLRQVWHSV17/0
Instructors Note: This slide offers a high-level overview of the authentication steps that go
on between the ProxySG and the client when the system has downgraded from Kerberos to
NTLM. There are three important things that you need to point out to the students:
1) The 401 response still has the NEGOTIATE option. (NTLM and BASIC may also be
present.)
2) There are two 401 responses sent by the client.
3) The NEGOTIATE reply from the client contains the NTLMSSP_AUTH value.
For any number of reasons, even if the UA receives a 401 response from the ProxySG, which
contains the NEGOTIATE header, the UA can decide to downgrade to NTLM. As mentioned in
the introduction, the IWA does not support Kerberos as the only option. If you select Kerberos,
NTLM is always offered as an alternative.
The sole presence of the NEGOTIATE header does not mean that Kerberos will be used. It simply
means that it can be used.
When a system has downgraded to NTLM, you can observe:
There are two 401 responses sent by the client.
The NEGOTIATE reply from the client contains the NTLMSSP_AUTH value.
The reasons that this happens are diverse and not limited solely to the configuration of the
ProxySG and its various components. It is clear that if you set up the SPN or the virtual URL
incorrectly, then Kerberos authentication cannot take place.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Steps
Authentication Challenge
HTTP 401 (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 a SPN

Blue Coat SG can only impersonate the virtual URL
6OLGH$XWKHQWLFDWLRQVWHSV5HYLHZ
Instructors Note: This is an overview of how the entire process happens. You should work
with the students on this and have them explain to you the key points in this slide. Make sure
that the fundamental concepts about ticket generation, ProxySG deployment, and UA support
are clear and understood.
This slide reviews the sequence of actions that take place during a Kerberos-based authentication.
The process starts when the ProxySG issues a 401 authentication request impersonating the virtual
URL. The client believes that the response is coming from the virtual URL.
The client, using the TGT obtained at logon time, contacts the TGS 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 machine
(or user account) where the BCAAA is running.
The ticket that the client receives from the KDC is encrypted with the session password shared
between the KDC and the BCAAA. The client then sends the ticket to the ProxySG, which cannot
read it. The ProxySG passes the ticket to the BCAAA; the 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: The BCAAA does not need to communicate with the KDC to authenticate the
users credentials.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Kerberos Lab Notes

Overview
Kerberos authentication requires a properly outfitted network environment and careful planning.
You need to have
An Internal DNS server.
An AD.
Students PCs as members of the AD forest (single sign-on only).
A ProxySG configured to be the default gateway on each student PC. (Bridging mode is
acceptable as well; each students PC is connected directly to a ProxySG, which then connects
to the network.)
Windows Resource kit available at

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp.
An SPN properly configured. (You need to be able to add and remove the SPN registration at
every training session.)
Figure 10-2: Kerberos lab setup
The commands that you need to execute, under a Domain Administrator account, are:
Register the SPN
setspn -A HTTP/<FQDN of virtual URL> <bcaaa machine Netbios name>
Remove the SPN
setspn -D HTTP/<FQDN of virtual URL> <bcaaa machine Netbios name>
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Software
Version
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 11: Substitution Realm
Instructors Note: Blue Coat customers frequently want a username to identify the source of
requests; however, they do not want or cannot force all users or applications to respond
appropriately to authentication challenges. This new authentication realm provides a solution.
Important: Policy Substitution realm is not an authentication option; it is username resolution
attempt. Be careful to set expectations correctly.
A Policy Substitution realm provides a mechanism for identifying and authorizing users based on
information available in the request that a client makes to the Blue Coat SG. The amount and
type of information available may change depending on particular proxy deployment (explicit vs.
transparent) and overall network settings (Network Address Translation [NAT], NetBIOS setting,
DNS settings, etc.).
The realm is configured to construct user identity information by using policy substitutions; the
user identity is determined with some of the elements present in the request to the ProxySG, with
the addition of other lookup and query actions.
If authorization data (such as group membership) is needed, the realm can be configured with the
name of an associated authorization realm (LDAP or Local). If an authorization realm is
configured, the fully qualified username is sent to the authorization realms authority to collect
authorization data.
You can use Policy Substitution realms in many situations. For example, a Policy Substitution
realm can be configured to identify the user:
Based on the results of a NetBIOS over TCP/IP query to the client computer
Based on the results of a reverse DNS lookup of the client computer's IP address
Based on the contents of a header in the request. This might be used when a downstream
device is authenticating the user
The Policy Substitution realm is used typically for best-effort user discovery, mainly for logging
and subsequent reporting purposes, without the need to authenticate the user.
The following is an example of how to use substitutions with Policy Substitution realms. Assume
that:
The user susie.smith is logged in to a Windows client computer at IP address 10.25.36.47.
The Windows Messenger service is enabled on the client computer.
The client computer is in the domain AUTHTEAM.
The customer has an LDAP directory in which group information is stored. The DN for a
user's group information is as follows:
cn=username,cn=users,dc=computer_domain,dc=company,dc=com where username is the

name of the user, and computer_domain is the domain to which the user's computer belongs
A login script that runs on the client computer updates a DNS server so that a reverse DNS
lookup for 10.25.36.47 results in "susie.smith.authteam.location.company.com."
Under these circumstances, the following username and full username attributes might be used:
Username: $(netbios.messenger-username)@$(client.address)
Q This results in SUSIE.SMITH@10.25.36.47
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Full username: cn=$(netbios.messenger-username),cn=users,

dc=$(netbios.computer-domain),dc=company,dc=com
Q This results in cn=SUSIE.SMITH,cn=users, dc=AUTHTEAM,dc=company,dc=com
Username: $(netbios.computer-domain)\$(netbios.messenger-username)
Q This results in AUTHTEAM\SUSIE.SMITH).
Username: $(client.host:label(6)).$(client.host:label(5))
Q This results in SUSIE.SMITH.
Any combination of policy substitutions available from the client request can be combined into
username and fully qualified username.
Important: Username information provided by Substitution realms is not guaranteed. This
is a best-effort approach to username identification. This is not an authentication
process.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Substitution Realm Objective

Provide username detection without user
prompting
Monitor by username
Cant force all users and applications to respond

appropriately to authentication challenges
Provide the ability for core proxies to trust edge

proxy authentication
6OLGH6FRSHRIWKH3ROLF\6XEVWLWXWLRQUHDOP
Instructors Note: Make the objective of this realm very clear once again. The ProxySG is
attempting to identify a user; it is not really challenging a user (or a user agent) for
authentication. This feature is for reporting purpose only; it minimizes the number of log
entries where there is no username information.
You may need to use the Substitution realm when it is inconvenient or impractical to challenge a
user or user agents for authentication.
The main objective of this realm is reporting. This realm has a very high probability of returning a
username in association with a client request. However, the username cannot be guaranteed.
This realm can be associated with an authentication realm to retrieve group information. The
ProxySG can lookup the calculated username in LDAP and Local realms to determine the users
group membership.
Note:
Policy Substitution realms do not require an authorization realm. If no authorization

realm is configured, the user is not a member of any group.
The following slides illustrate different scenarios where you can use the Policy Substitution realm.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Substitution Realm Overview
6OLGH6XEVWLWXWLRQ5HDOPIXQGDPHQWDOV
Instructors Note: This is the introductory slide. Describe what information is available to the
ProxySG to resolve a username without issuing a challenge (407 or 401 HTTP error).
The ProxySG can identify users by sending back an HTTP 407 error (explicit proxy mode) message
or an HTTP 401 error (transparent proxy mode) message. It also can use X.509 certificate
authentication, but this is beyond the scope of this chapter.
The ProxySG may use information naturally present in a client request in a best-effort attempt to
identify the username of the person making that request.
Every request contains the source IP address of the client (unless it is behind a device which
performs NAT), some request headers, and authentication credentials as required by other
applications.
The ProxySG can use this to query an LDAP directory to retrieve more data about the user;
typically you may want to query the LDAP directory for a group.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Deployment Authentication
6OLGH(GJHWRFRUHDXWKHQWLFDWLRQ
Instructors Note: This is an interesting feature. You do not always need to provide the
upstream proxy (core) with user information on a session initiated downstream (edge). In
general, as a best practice, you should log and authenticate users at the edge proxy level.
However, you should not log or challenge for authentication all the connections that the core
proxy receives from the edge proxy. This improves performance and keeps logs consistent.
However, if user information is made available from the edge to the core, this is the best
approach.
The client makes an initial request to the edge proxy. At this point, the edge ProxySG challenges
the user agent for authentication. The client sends request with the proper credentials; if the
credentials are valid, the edge ProxySG places the authenticated username into the upstream
request to the core ProxySG. This information is added in a special header called edge-user.
The core ProxySG can authenticate any request from the edge proxy against a Policy Substitution
realm by reading the addition header information and treat that as the username.
Finally, the fully qualified username is used to check authorization in the LDAP directory, and the
relevant core proxy policy for that user (or group) is applied.
Note:
You can use this realm to create both user-based and group-based policies. You must
associate the Substitution realm with an authentication realm (LDAP or Local) before
you can use group information.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Deployment NetBIOS Based
6OLGH1HW%,26EDVHGVXEVWLWXWLRQUHDOP
Instructors Note: Make sure that you point out all of the limitations of this approach. The
main limitation is that users behind a firewall cannot be resolved if the device performs NAT.
Furthermore, NetBIOS can be disabled. Some companies are implementing this configuration
across the board. Finally, point out that you need to configure a Time to Live (TTL) value for
the result of the authentication. You cannot query NetBIOS for all requests from the same
client because it would result in a significant increase in network traffic. However, every time
you rely on TTL, you reduce the accuracy of the username information. (Compare it IP
substitution authentication.)
NetBIOS can provide some detailed information about a user logged on to a Windows system. The
information is made available unless you have disabled the NetBIOS protocol on your
workstations.
When the client initiates a request, the ProxySG sends a NetBIOS name request to retrieve
information about that IP address. For instance, if the clients IP address is 10.25.36.47, the result of
the query is similar to using the command:
C:>nbtstat -a 10.25.36.47
The Substitution realm can also use the computer name along with the domain name (which was
retrieved via NetBIOS) to create a fully qualified username. For instance, using substitutions, you
can create an LDAP user:
cn=$(netbios.messenger-username),cn=users,dc=$(netbios.computer-domain),
dc=company,dc=com)
The ProxySG queries the LDAP server using the string shown above (with the correct values filled
in) and attempts to obtain the groups and attributes of this user.
Based on both the username information produced by NetBIOS and by the LDAP search, the
proper policy is applied to the request.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Deployment DNS Based
6OLGH5'16EDVHGVXEVWLWXWLRQUHDOP
Instructors Note: Unless the DNS and the DHCP servers are configured to keep each other
up to date, it is unlikely that a company already uses client scripts or would add these scripts
to enable this feature. This is simply good to have. Talk about but do not push it; NetBIOS is, at
least in general, a better alternative.
You can use the Reverse DNS (RDNS)-based Substitution realm if you can always and correctly
map the DHCP-assigned IP addresses with the appropriate hostname. Some DHCP and DNS
servers can be configured to work in conjunction and keep each other updated; unfortunately, this
is not always the case.
When the DNS and DHCP server do not talk to each other, you need a login script that runs on the
client computer. This script updates the DNS server every time the DHCP issues a new address for
that client machine. This ensures that the RDNS lookup for the IP address is accurate and returns
something like susie.smith.authteam.location.company.com.
If the RDNS lookup returns a usable value, the Policy Substitution realm uses (in this example) the
fourth and fifth portions of the client hostname to create the LDAP look-up string as shown below:
cn=$(client.host:label(5)).$(client.host:label(4)),cn=users,dc=edgecorp,
dc=com)
Once again, the ProxySG has sufficient information to determine group membership for the
calculated user.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Important Notes
Best-effort approach
Username resolution cannot be guaranteed

Do not create sensitive policies based on this realm
Gather back-up information before taking disciplinary
actions
Careful when using it in a sequence
May allow users to bypass authentication
6OLGH%HVWSUDFWLFHV
Instructors Note: This realm relieves a real pain point for the customer; however, you need
to discuss with your audience the limitation of the solution. The slide is called Important
Notes, but it could be called Limitations. Its suggestions are designed to minimize the
impact and side effects of the limitations inherent in this approach. Please point out that this is
the best and most technically accurate approach possible to username resolution without
issuing an authentication challenge.
If your main concern is to implement single sign-on, you can place the Substitution realm in a
sequence as first realm or use it alone. This realm has a very high probability of returning a
username.
Finally, especially if you plan disciplinary actions based on the information obtained by the
Substitution realm, collect as much information (evidence) as you can to support the data you get
from the realm. Additional information includes, but is not by all means limited to:
LDAP or Active Directory logs
DHCP Logs
Browser history logs for that user
Cookie jars for that user
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Authentication Configuration Substitution

Realm Lab
Overview
You want to implement a single sign-on environment, but not all of the users can use NTLM. You
have an Active Directory (AD) forest that you can query via LDAP. You do not want the users to
be prompted for any sort of authentication.
By using the Policy Substitution realm, you can use information in the AD to identify and
authorize users. You have Messenger Service enabled on your Windows workstation so that
NetBIOS is likely to return the username of the person currently logged on to a machine

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for CPL Substitutions Lab

Overview
The function known as advanced forwarding enables implementation of a proxy hierarchy with
Blue Coat SG appliances. Advanced forwarding allows implementation of these key features:
Forwarding to an upstream ProxySG appliance based on domain, URL, or IP address
Load balancing of multiple upstream ProxySG appliances
Layer 3, Layer 4 and Layer 7 health checks of the upstream ProxySG appliances.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F PuTTY
F Release 0.60
F Wireshark
F version 0.99

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F PuTTY
F Release 0.60
F Wireshark
F version 0.99
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 12: Windows SSO
Instructors Note: Point out clearly to the students that the Windows Single Sign-on (SSO)
realm does not issue a 407 or a 401 to authenticate users. In actuality, the realm does not
authenticate the users; it simply tries to associate an IP address to a user name. The
technique used here is similar to what Websense and SurfControl use.
The Windows Single Sign-On (SSO) realm allows you to create and manipulate realm properties,
such as the query type and the number of seconds that credential cache entries from this realm are
valid. However, it also contains the authorization username and the name of the realm that will do
authorization for the Windows SSO realm. The authorization username is a string containing
substitutions that describe how to construct the username for authorization lookups. This can
either be an LDAP fully qualified domain name (FQDN) when the authorization realm is an
LDAP realm or a simple name when local realms are being used for authorization.
Note:
Windows SSO realms never challenge for credentials. If the authorization username
cannot be determined from the configured substitutions, authorization in the
Windows SSO realm fails.
Keep in mind that Windows SSO realms do not require an authorization realm. If no authorization
realm is configured, the user is not considered a member of any group. The effect this has on the
user depends on the authorization policy. If the policy does not make any decisions based on
groups, you do not need to specify an authorization realm. Also, if your policy is such that it
works as desired when all Windows SSO realm users are not in any group, you do not have to
specify an authorization realm.
In a Windows SSO realm, the client is never challenged for authentication. Instead, the Blue Coat
Authentication and Authorization Agent (BCAAA) collects information about the current logged
on user from the domain controller and/or by querying the client machine. Then the IP address of
an incoming client request is mapped to a user identity in the domain. If authorization
information is also needed, then another realm (LDAP or local) must be created.
Important: The Windows SSO realm works reliably only in environments where one IP
address maps to one user. If an IP address cannot be mapped to a single user,
authentication fails. If your environment uses a NAT system, which uses one set
of IP addresses for intranet traffic and a different set for Internet traffic, you
should use a different realm for authentication.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Windows SSO
Simpler method to authenticate users

Provides complete transparency
Users do not need to re-authenticate
Similar to Policy Substitution realm
The clients do not receive HTTP/401 or HTTP/407
6OLGH:LQGRZV662RYHUYLHZ
Instructors Note: Windows SSO is available starting in SGOS 4.2.2; this feature allows user
detection without ever challenging users for authentication credentials. Make sure that your
students realize that Windows SSO is a way to recognize (or detect) usernames; it is not true
authentication.
Many Blue Coat SG users look for a simpler method to authenticate users. You may want users to
be able to log on once to their workstations and then not have to worry about authenticating
again. Currently the IWA realm offers single sign-on if the user is logged on a Windows client and
the machine is part of the same domain for which IWA is configured. However, this does not
provide complete transparency because ProxySG still issues a 401 or a 407 HTTP response to the
client, which can result in the UA prompting the user for authentication credentials.
The new Windows SSO realm allows you to set up fully transparent username resolution. Like the
IWA realm, Windows SSO uses BCAAA to authenticate with the Windows network. The ProxySG
maps the IP address of an incoming request to a user identity on the domain.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Realm Modes
Domain Controller Querying
The domain controller will be queried to identify

users
Direct Client Querying
The client can be queried directly in order to

determine the user currently logged on
Both
Domain query is used first
6OLGH5HDOPPRGHV
Instructors Note: There are two ways in which Windows SSO can resolve a username.
Domain controller querying can be performed by any authenticated user in the domain that
includes the LocalSystem user on the BCAAA machine. By polling the domain controller
frequently, it is possible to determine which users have logged on from which clients. Direct
Client Querying is blocked by the Windows XP SP2 firewall. Logon data can be retrieved on
demand. The BCAAA does not have to poll for the data, or persist the data.
To authenticate a user, the Windows SSO realm uses two methods, either separately or together:
Domain Controller Querying: The domain controller is queried to identify which users are
connecting to, or authenticating with, the domain controller. This can be used to infer the
identity of the user at a particular workstation. Domain controller querying enumerates the
network connections of a given server. Client machines create a network connection to the
domain controller when logging on. By polling the domain controller, it is possible to
determine which users have logged in from which clients.
Client Querying: The client workstation is queried to determine who the client workstation
thinks is logged on. The benefit of Direct Client Querying is that the logon data can be
retrieved on demand. BCAAA does not have to poll for the data, or persist the data. It can also
be used to identify a logon that did not involve a domain controller.
When Domain Controller Querying and Client Querying are both selected, the Domain Controller
Query result is used if it exists and is still within the valid time-to-live as configured in the sso.ini
file. If the Domain Controller Query result is older than the configured time-to-live, the client
workstation is queried.
Note:
In explicit proxy mode, the BCAAA checks on every transaction for the user
associated with a given IP address. To avoid querying the client for every transaction,
you can use IP or cookie surrogate credentials.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Deployment Scenario
6OLGH'HSOR\PHQWVFHQDULRV
Instructors Note: Use this slide to describe some of the advantages and disadvantages of
the Windows SSO realm. Also use it to build the list of deployment requirements, which are
detailed in Slide 12-5. The circle around the client on the left of this slide represents a personal
firewall. The line is not solid because it assumes that the firewall is disabled or at least that the
necessary ports for Windows authentication and NetBIOS queries are open.
The deployment options define whether the BCAAA retrieves user information from the domain
controller or the client. Both scenarios have advantages and disadvantages.
Domain controller querying uses the NetSessionEnum Windows API function and constantly
polls the domain controller to retrieve information about currently logged users. Some issues to
consider for this option are:
It requires frequent polling of each domain controller in order to capture all logon events.
Polling needs to occur at least every ten seconds because logon events can be as short as
fifteen seconds.
Users do not have to authenticate through the domain controller. There are two common cases
that avoid the domain controller: cached domain accounts and local accounts.
Direct client querying reads the registry for username information; this provides the most correct
answer to who is logged on to a workstation. Reading the registry can be done by users
authenticated in the domain without special privileges. The main drawbacks are:
It is slower than NetWkstaUserEnum (Domain Query).
Personal firewalls are a challenge (need to open some ports).
Important: Remember that this realm provides username detection and not authentication.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authorization Realm
CPL Substitution
Description
$(user.domain)
The Windows domain of the

authenticated user
$(user.name)
The relative username of the

authenticated user.
Connect to other realm
Look-up group information

Optional step
6OLGH*URXSVORRNXSV
Instructors Note: Windows SSO allows you to look up group information for a user. The
information is referenced in one of the existing other realms. Point our clearly that this is an
optional setting. You do not have to configure authorization for the realm. You can use the CPL
substitution to build an NT-like or LDAP username.
You can construct the username in a Windows SSO realm using the CPL substitutions listed in the
slide above. For instance you can have the username constructed as:
$(user.domain)\$(user.name)
The syntax above generates username similar to BLUECOAT\BOB.KENT.
To construct a username, keep in mind that the authorization username attributes is a string that
contains substitutions. When authorization is required for the transaction, the character string is
processed by the substitution mechanism, using the current transaction as input. The resulting
string becomes the users authorization name for the current transaction
Windows SSO realms do not require an authorization realm. If the policy does not make any
decisions based on groups, you do not need to specify an authorization realm.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Deployment Notes
6OLGH'HSOR\PHQWQRWHV
Instructors Note: This is a very important slide. You should have already led your students to
come to the conclusions shown here when presenting Slide 12-3. Reiterate that these
limitations apply to the client querying method. Basically, personal firewalls and corporate
(network) firewalls represent a challenge to the success rate of the Windows SSO realm.
The Windows SSO realm uses BCAAA to query domain controllers and/or computers in the
domain. This querying can be blocked by the Windows XP/2003 firewall. If the firewall is active
on a computer that the Windows SSO realm needs to query, then a firewall exception must be
added to the domain policy for that computer.
The Group Policy Management Console can be used to adjust the firewall exceptions for a
domain. It can be downloaded from Microsoft if it is not already available. TCP port 445 must be
enabled on the client for access from the machines running BCAAA. TCP port 445 is used by
SMB/NetBIOS over TCP. On the client, you need to enable one of the following settings:
Allow remote administration exception
Allow file and printer sharing exception
Define port exceptions and add TCP port 445
Also, Windows SSO does not ingrate with NAT because it requires one IP address to map only one
user. In a NAT environment, all clients will appear as one user.
Network firewalls also present a challenge to Windows SSO username detection. While it is easy
to open personal firewalls to exceptions, it can be harder to do so on corporate firewalls for
obvious security reasons.
The Windows SSO realm works reliably in environments where one IP address maps to one user.
There is no workaround for this. When using domain controller querying, the assumption is that
the previous user has logged out if a new user is seen for the same IP address. When using direct
client querying, it is possible to identify multiple users logged onto the same workstation. One
common case for this would be when using Windows Terminal Services. The only option in this
case would be to use a Sequence Realm and authenticate with a different realm if there is more
than one user per IP.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Neither domain controller querying or direct client querying will work correctly with NAT. In that
case, the administrator should identify the NAT addresses and use a different realm for
authentication.
There is no logout event that can be tracked. Once the User Management changes are available, it
would be possible to allow users to log themselves out but since they are doing SSO, this would
seem wrong and may cause more confusion.
Note:
Windows SSO works best when all users are on the same subnet as BCAAA and there
are no personal firewalls on the clients.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Understanding sso.ini File
Before domain controller querying or client querying can be used, the sso.ini file, located in the
same directory as the BCAAA service, must be modified. The installation wizard for the BCAAA
creates the sso.ini file1.
To enable the method of authentication querying you choose, you must modify the sso.ini file
by adding domain controllers you want to query and user accounts you want to ignore.
The sso.ini file is located in Program Files> Blue Coat Systems> BCAAA.
If you are only using one method of querying, you only need configure the specific settings for
that method. If you plan to use both methods to query, you must configure all the settings.
Note:
The changes to the sso.ini file will have no effect until the BCAAA service is
restarted.
To configure the sso.ini file for domain controller querying, you need to follow the steps detailed
below:
1.
Open the file in a text editor.
2.
In the section DCQSetup, un-comment the line: DCQEnabled=1.
3.
In the section DCQDomainControllers, list the domain controllers you want to query or the IP
address ranges of interest.
By default all domain controllers that are in the forest or are trusted are queried. In large
organizations, domain controllers that are not of interest for the ProxySG installation might be
queried. The sso.ini file can be used to list the domain controllers of interest or IP address
ranges of interest.
4.
In the section SSOServiceUsers, list the domain names of users who can access the domain
controller on behalf of the service and mask the identity of the logged-on user.
Listing these users here forces the BCAAA service to ignore them for authentication purposes.
5.
Save the sso.ini file.
To configure the sso.ini file for client querying, you need to follow the steps detailed below:
1.
Open the file in a text editor.
2.
Review the TTL times in the section ClientQuerySetup to be sure they are appropriate for your
network environment.
3.
Update the section SSOServiceUsers to ignore domain users used for services.
4.
Save the sso.ini file.
Note:
Before you use the Windows SSO realm, you must change the BCAAA service to run
as a domain user, and, if using XP clients, update the domain policy to allow the client
query to pass through the firewall.
1. You must have installed BCAAA version 4.2.2.x or higher. Earlier releases do not create the sso.ini file.
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 13: Advanced Authentication
Instructors Note: This chapter is designed to both dive into the details on how ProxySG
handles the authentication process and as a primer for the Guest Authentication feature
(which is discussed in a separate chapter). The initial part of the chapter is relatively detailed;
in particular you can teach the first three slides definitely at two different levels. You can
quickly scan through them or you can attempt to discuss the minute details; it largely depends
on your class.
Focus on the remaining slides as the concepts illustrate are key to understanding the Guest
Authentication chapter.
Essentially, this chapter explains how ProxySG collects, retains, process, and shows user
information. There are several nuisances about username resolution and group membership
analysis; this chapter is designed to allow the students to understand what they can expect
from user authentication and why.
The complexity pertaining to authentication is that ProxySG is a multi protocol device. A single
user can be using a web browser, have an ftp download going, chatting through IM, and
streaming a video all from the same desktop. The chapter guides the student to understand
how the proxy deals with the different scenarios.
Bear in mind that, although very detailed, the information in this chapter is a simplification of
the actual mechanism, which ProxySG uses to manage authentication.
The main focus of this chapter is to provide the details necessary to understand how ProxySG
determines which users are currently logged in and how an administrator can manage these users.
You can run a query find out which users are currently logged into a ProxySG. The information
details which user(s) are logged in from an IP address, or given a user, which IP addresses she is
using. You cannot just view user information but it is possible to logout a user-through a direct
action or through inactivity.
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 in WMP and
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? ProxySG supports both cases through
policy.
Another power feature of ProxySG, which allows for better management of credentials and user
authentication, is the possibility for administrators to have control over how often the user is
authenticated and to decide when to force the user to type in their username and password rather
than just accept the browsers cached credentials.
Some of the unique features and functionalities of SGOS are:
Better control over credentials

Administrators can require more frequent authentication if the end-user is accessing critical
resources. These features allows the administrator finer control over how often the end-user is
authenticated. The administrator has the option to ignore the cached browser credentials and
force the user to re-enter their credentials.This is very important when you need to control
access to very sensitive resources, like internal server hosting private documents and other
similar situations.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
End-user Logout capability

The use of IP surrogate can cause, in very rare and extreme situations a user to be mistaken for
another. For example, if another person used that computer before the credential cache entry
expired for the previous user, the second user would be treated as the original user. 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
Since it is possible to determine when a user is logged in, it is possible to manage the number
of logins allowed.
Authorization Data Refresh

ProxySG allows the authorization data to be invalidated separately from authentication data.
This allows the authorization data to be refreshed without re authenticating the user.
At the end of this chapter you should really be able to understand how the authentication and the
authorization processes work with a ProxySG appliance.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication and Authorization

Authentication
Determining the users identity. Includes obtaining

credentials and submitting them to authentication
server as need
Authorization
Determining which groups and attributes the identified

user has. Only determines those that are specified in
policy
6OLGH$XWKHQWLFDWLRQDQGDXWKRUL]DWLRQ
Instructors Note: This slide introduces the difference between authentication and
authorization since the ProxySG can manage the two separately, which allows the proxy to
support many realms and different complex authentication and authorization environment. To
simplify the concept, you can state that:
Authentication is the process of determining who you are and
Authorization is the process of determining what you can do.
When you submit your credentials (username and password) for validation, depending on the
authentication realm used in your organization, the process of validating your identity and the
process of determining what you are authorized to do can be two separate processes.
Some realms, like LDAP based ones, allow an organization to build a very complexed and
distributed environment for user authentication and authorization. The two processes can not just
be logically separate but also can be performed at different times and on different systems.
On the other hand, some realms, like IWA do not allow authorization and authentication to take
place separately; they have to happen at the same time.
ProxySG supports a wide, and growing, variety of realms; it is therefore very important that at a
logical level authorization and authentication are managed separately. This allows scalability and
increased functionality in both users management and realms support.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication and Authorization
6OLGH$XWKHQWLFDWLRQDQGSROLF\FRQWURO
Instructors Note: Point out that this slide is designed to represent the most generic scenario
and it is not likely to represent the actual scenario for the majority of the students.
Make sure that you explain clearly:
- The authentication and authorization servers are wrapped into a dash-lined rectangle as they
can be (and they are in most cases) just one physical server
- The credential validation and authorization request query most likely happen at the same
time (IWA realm for instance) but they can be split in some other realms
- The ProxySG requests the group-membership information to the realm only if you have
group-based policies.
As mentioned in Slide 13-1, 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 of the implementation of authentication and authorization
structures, perform the two processes at the same time and on the same server.
It is necessary for ProxySG to manage the two, at least logically, as two completely separate and
independent events. Regardless of the actual scenario, all of this happens pretty much behind the
scenes and it is completely transparent to the end-user.
The slide shows the VPM and a policy where the source trigger is a user group. This is done to
point out how ProxySG only retrieves group membership information when there is a policy
requiring such information.Unless you have the need to verify group membership for a user,
ProxySG does not retieve this information.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication Model
6OLGH$XWKHQWLFDWLRQ0RGHO
Instructors Note: This slide may appear intimidating at first, however its content is relatively
easy. Make sure, as it is always the case in this detailed diagram, to point out that the slide
represents a very high level simplification of the process and many details have been omitted
as they are proprietary to Blue Coat.
The most important point in the slide is that credentials are cached and that there are two
workers who are in charge of completing the authentication and authorization process.
The AAA worker is not the BCAAA; it is however the component within SGOS which will
communicate with the BCAAA if and when necessary.
Note: Authorization steps a ignored to keep the slide simple. However it is the AAA worker
which will perform the authorization as well as the authentication.
Important: At step 2 it is not the PW which looks for credentials in the cache but the AAA. The
PW simply asks the AAA for credentials validation; it is the AAA which manages the cache.
Questions: When does the ProxySG send a 401 and when a 407 to request users
credentials?
Answer: 401 is used in origin-*-* or form-*-* authentication mode. This is most likely an
transparent or reverse proxy deployment.
407 is used only in proxy mode authentication. This must be an explicit proxy deployment.
The ProxySG uses an elegantly complex authentication process which allows the operating system
to de-couple authentication and authorization, while supporting virtually any type of realm and
credentials.
In order to maximize performances, limit interaction with the authentication services, and to
enhance the user experience, the process can be logically and functionally split in 5 steps detailed
below.
1.
The client requests for an object through the cache. The policy worker (PW) initializes a new
Session and associates the user Guest to the session while it is waiting for the client to submit
the requested credentials. If this request is a new Transaction within a Session, then PW may
or may not initialize a new request for authentication. This depends on the specific PW
requirements.
The PW may use an HTTP 401 or HTTP 407 to ask for credential depending on the specific
settings in the policy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
In HTTP (Explicit) proxy the PW issues an HTTP 407 Proxy Authentication Required
and adds specific realm information like: www-proxy-authenticate: NTLM<CRLF>
www-proxy-authenticate: BASIC realm="BC_Training". This is also known as
authentication negotiation process. IE client always selects NTLM in such case, as it provides
better security. Netscape and Mozilla (FireFox) clients select Basic Authentication challenge.
For transparent proxy authentication as well as reverse proxy authentication, PW issues an
HTTP 401 Unauthorized challenge as indicated above with appropriate NTLM/BASIC
Auth challenges.
The client (browser) pops up the user for credentials (optional, for instance IWA with NTLM
or Kerberos credentials will not) and the appropriate credentials are sent in Authorization
header.
Note:
Note: For Basic Auth and transparent Authentication schemes, the authentication
credentials are included in every request. In this case, there is no need to issue an
authentication challenge to the client.
2.
The PW calls the AAA worker which first looks for the user object in one of its local caches i.e.,
credential cache.In the case of transparent auth, the CFAuth cookie is validated first to
determine the user name and realm and then these credentials are used against the credential
cache.
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; it depends if it is
requested in the policy or not.
The external authentication sends back the authentication response.
Note:
NTLM authentication is a challenge-response mechanism with three round-trips

between the client and BCAAA agent.
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 PW.
5.
The PW passes the authentication information (failure) to client or allows the ProxySG to
return the requested content (which could be a denied or exception page).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
User Login Definition
6OLGH'HILQLWLRQRIXVHU
Instructors Note: The content of this slide is key as it allows you to clearly describe what it is
a user as far as ProxySG is concerned. The definition of a user is important primarily so that
you can understand the licensing implications. Primarily, a user is mapped to one IP address
and not to the number of session it has open; however, depending on the credential surrogate
that you use for the authentication, you can have more than one user logged on a single IP.
The slide describes what can be a relatively common scenario, especially for certain users who
have access to multiple machines like IT people.
Bob is logged on the 172.16.90.130 and 172.16.90.202 workstations. Mary logged on from the
172.16.90.124 PC. Both Mary and Bob access a combination of HTTP and HTTPS resources via a
ProxySG.
You can say that there are 2 user IDs logged into the proxy and three devices. The ProxySG
consider a user the unique 2-tuple made of Username and IP address. So the user in the system
are:
1.
(172.16.90.124; Mary)
2.
(172.16.90.130; Bob)
3.
(172.16.90.202; Bob)
The following slides describe some other situations where the surrogate credentials are used to
make a more significant difference in determining the number of users logged into the proxy.
In case of Slide 13-4, there are no device between the user and proxy which may alter or
masquerade the original source IP; in this scenario the number of user logged in is pretty much
always 3 regardless of the surrogate credentials used.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Surrogate Credentials
6OLGH6XUURJDWHFUHGHQWLDOV
Instructors Note: The student should have brushed along the concept of surrogate
credentials in various parts of this or other Blue Coat courses; however a definition of
surrogate credentials was never clearly discussed. Define surrogate credentials as the piece
of information used to map a transaction to a user.
Unless you are in the very specific case of explicitly proxy environment, there is no reference to the
user credentials in an HTTP request. Additionally, you should remember how the HTTP protocol
is stateless and connectionless. In essence, once a request and response pair has taken place, there
is nothing surviving about that transaction in the next one.
After the authentication process there is really 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 even and the corresponding user ID to some object or
property, generally called surrogate.
You can elect to use three types of surrogates:
Connection: the authentication results is associated to the TCP connection between the client
and the proxy. This can only be used in explicit proxy environment; it requires using HTTP
407 in order to challenge the user for this type of surrogate.When the connection terminates,
authentication information is lost and the user needs to re-authenticate.
IP Address: the authentication result is associated to the source IP address of the client
request. You need to define a time to live (TTL) for this type of surrogate. Shorter TTL means
that the user may be authenticated more often but there is less of a chance of incorrectly
identify users. Longer TTL means that the user is authenticated less often but there can be an
higher chance of incorrectly identify users.
Cookie: the authentication result is associated to a cookie. You can have session cookies or
persistent ones by setting a TTL. Either case cookies are relatively secure as each user profile,
even on a shared machines, must have individual cookie jars. Once the user is authenticated,
the proxy sends back a cookie. As long as the user agent present a valid cookie to the proxy,
the user is not prompted for authentication.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
You can use any of the three supported forms of surrogate credentials in explicit proxy
environments; for transparent proxy environments you are limited to IP address or cookie
surrogates.
Additionally, you need to consider that you can use IP address or connections surrogate
credentials with virtually any user agent, not just web browsers. You may use cookie surrogates
only with compatible user agents; typically this restricts the use of this type of surrogate to web
brokers.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
User Data Refresh
6OLGH5HIUHVKXVHULQIRUPDWLRQ
Instructors Note: The concepts here a very simple, even if the students note contain a lot of
information, as there is some redundant information about the concepts and limitations behind
surrogate credentials. You can refreshing user data with the following refresh-time options on
the SG appliance:
- Credential refresh time: This option specifies how long a cached username and password
is trusted (do not require rev a lid at ion).
- Surrogate refresh time: This option specifies how long surrogate credentials are trusted in a
particular realm.
- Authorization refresh time: This option specifies how long authorization data, such as
groups and attributes, are trusted
While the 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 there is concern
about the actual identity of the user on a long-lived IP surrogate.
Credentials Refresh Time
You can set the credential refresh time with realms that can cache the username and password on
the SG appliance. 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 since they are
stored already on the appliance.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
You can use a cached username and password to verify a users credentials without having to
verify the credentials with the offbox authentication server. Essentially, this reduces the load on
the authentication server. For authentication modes that do not use surrogate credentials (that is,
proxy or origin modes), this can greatly reduce the traffic to the authentication server. The
credential refresh time value determines how long a cached username and password is 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.
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
authentications modes; and the 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 (Local, LDAP, Windows SSO, Novell SSO, Certificate, XML, and Policy Substitution) that
can do authorization and authentication separately 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Inactivity Timer
6OLGH,QDFWLYLW\WLPHU
The idea is to visibly notifying that the user has been logged out. Form based authentication
makes the process pretty obvious under all circumstances (any surrogate credentials) as the
browser cannot cache the credentials submitted in a form.
Instructors Note:
However, if you are not using forms, the user agent can resend the cached credentials without
any user intervention. Only if the credentials are invalid, then the user agent shows the
pop-up window to the client. The solution is to use session based cookies and invalidate the
cookie in a two steps process to make it look like the previous cached credentials were not
valid. This solution work with Firefox and IE and may also work with other advanced
browsers like Opera.
IE has a further complication. One the next challenge it helpfully fills in the last username and
password for the user. If user A has logged out, they will not want user B to be able to log back
in with their credentials. Fortunately, there is an IE specific Java Script function which will
clear all cached credentials and avoid this issue. When the SG has determined that the browser
is presenting old credentials it will respond with a new Log out exception page. This page
includes the special IE Java Script to clear the credentials and displays an exception message
which effectively notifies the user that the session has been logged out. This page is
automatically refreshed, which forces the new challenge.
One of the difficult issues with the concept of log out 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 their 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
In order to visibly challenge the user for authentication when you are not using form-based
authentication, you need to use cookie surrogate. You cannot use IP address nor you can use
session based surrogates. Using cookies, you can visibly challenge the users, 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 ProxySG encounters a session cookie for a new user, this means
that the user was previously authenticated this user 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 at they have been expired, the cookie is
modified and the client receives 401
3.
The client resends the cached credentials, this time they do not match what the ProxySG has
so it can send back a 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 are accepted.
5.
ProxySG validates the credentials with server configured in the realm.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Inactivity Timer - Connections
6OLGH,QDFWLYLW\WLPHUZLWKFRQQHFWLRQVXUURJDWH
Instructors Note: You can go over this slide very quickly. The idea is to show how it is not
possible to log out a user in a way that it is visible to the user. The browser responds to the
HTTP 401 with cached credentials.
This slide shows the scenarios where the user is explicitly proxied and you are not using
form-based authentication mode.
After receive an HTTP 407 response from the proxy, an explicitly proxied user agent will always
add the user credentials in the every subsequent request. Additionally, most browser do cache the
user credentials for as long as the browser process is running.
When the ProxySG expires the user (logoff), 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 result, even if the user was logged off, unless the browser
session was terminated (user killed all running processes for that user agent), the user does not
have to re-enter the authentication credential.
In this scenario, logging off user is mainly used to keep the license with the necessary limits.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Conditions
6OLGH3ROLF\FRQGLWLRQV
Instructors Note: This slide shows a scenario where the users and the proxy are separated
by a firewall, which performs NAT. Users are authenticated using IP address as surrogates.
This is a scenario that should not happen in the first place as it is bad design to use IP
addresses surrogates; you should consider always only session or cookie surrogates when
there are natting devices between the users and the ProxySG.
There are two main things you need to convey in the slide:
1) The three properties and three conditions to manage user logouts.
2) The reason why IP address surrogate credentials is not a good fit for this type of
environments.
The ProxySG has three different properties 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 with 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 user number.
user.login.time
This condition matches the number of seconds since the current login started, and you can use
it to limit the length of a login session.
In the scenario represented in the slide, the administrators have made a very poor selection of
surrogate credentials. Since there is a firewall with NAT between then users and the proxy, IP
address surrogate is the worst possible decision as it does not allow the ProxySG to discern
between users. All transactions are associated to the first users who was authenticated.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
To fully understand this scenario, you need to remember that the ProxySG identify a user as the
2-tuple (username, IP address) as discussed on page 195. The sequence of events explains the issue
in details and with clarity.
1.
Bob, who is logged on 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.
ProxySG associate the surrogate credential IP address 10.0.1.100 to the user Bob.
3.
Within the time frame of the TTL for the surrogate credential, Mary logs in from the IP address
172.16.90.123. Unfortunately her IP address appears as 10.0.1.100 to the proxy because of the
NAT taking place on the firewall.
4.
While you may want or expect the ProxySG to be able to associate Mary as new user, since the
IP address 10.0.1.100 is a valid surrogate credential, her traffic will be associated to the user
Bob.
For both Bob and Mary login:
user.login.count=1
client.address.login.count=1.
client.address.login.count=1
user.login.count=1
which means according to the ProxySG , only Bob is logged on and he appears logged on once.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Policy Conditions - Cookies
6OLGH3ROLF\FRQGLWLRQVZLWKFRRNLHVXUURJDWH
Instructors Note: This slide shows why using cookie surrogates is a much better option
when there is a NAT device between the users and the ProxySG. Since the cookies are not
impacted by NAT, the proxy can discern between two users on the same IP. This is also true
for session surrogate, which of course means you are in an explicit proxy environment.
As mentioned earlier in this chapter, ProxySG allows you to use cookie as surrogate credentials.
Cookies are not impacted by the presence of a device performing NAT and cannot be shared
across user profiles making them both a flexible and secure option for surrogates.
The scenario in Slide 13-10 is the same as Slide 13-9; however in this case the administrator of the
proxy has correctly decided to use cookie surrogates.
To fully understand this scenario, you need to remember that the ProxySG identify a user as the
2-tuple (username, IP address) as discussed on page 195. The sequence of events explains the issue
in details and with clarity.
1.
Bob, who is logged on 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.
His 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 the IP address 172.16.90.123. Her IP address 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 proxy
4.
Mary receives the authentication cookie after the proxy successfully validated her credentials.
ProxySG can distinguish between the users Bob and Mary, even if they appear as coming from the
same IP address. In that case, each of their user.login.counts would be 1, but the
client.address.login.count for 10.0.1.100 would be 2.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Advanced Authentication Lab

Overview
This labs walks you through a packet capture performed on the ProxySG. The goals is to show the
Authentication and Authorization steps, which ProxySG performs when there are Group or
Attribute based policies.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F Wireshark
F version 0.99

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F Wireshark
F version 0.99
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 14: Guest Authentication
Instructors Note: This chapter discusses the ability of ProxySG appliance to allow access to
unauthenticated or unauthorized (or both) users even when there are authentication policies in
place. The chapter walks the students through a detailed understanding of the features and
functionalities that the ProxySG appliance makes available to the administrator. It also
describe the technical details behind them.
In essence the main concept behind guest authentication is to allow the administrator to see
and manage both authentication and authorization errors.
Authentication can succeed even if authorization fails in realms that support split
authentication and authorization (i.e. can specify a separate authorization realm) or those that
are valid authorization realms themselves (e.g. LDAP, Local realms). Realms that do not
support split authentication and authorization (e.g. IWA, SiteMinder, COREid) fail
authentication if authorization fails for any reason. Authorization cannot succeed if
authentication has failed. In those cases, authorization will not be attempted.
ProxySG appliance allows you to deal with:
- Permitting authentication errors
- Permitting authorization errors
- Attempting the next realm in a sequence after a permitted error
- Authenticating as a guest user
- Adding default groups to a user
A realm is specified to authenticate the guest against but it does not actually authenticate the
user against the backend 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.
Important: This chapter requires that the students have mastered the concept in the
Advanced Authentication chapter.
For some companies, user authentication and authorization is desirable but not necessarily
required for users to access resources. Administrators for these companies would like a way to
specify that authentication and authorization should be attempted but that some errors should be
permitted such that the users 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 may want the ability to
allow users transactions to continue after an external server failure while at the same time,
terminating the transactions of users that 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 logging in from public workstations whom do not have
intranet accounts.
This chapter describes how ProxySG appliance 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 setup 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, which 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 you to
assign a username to a user who would have otherwise been considered unauthenticated.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Note:
You can use guest authentication with or without default groups. If you use default
groups, you can assign guest users to groups for tracking and statistics purposes.
In the case of 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.
Since 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 in which guest access is permitted. Guest users are typically
allowed in circumstances where no authentication is needed.
Determine authentication policy. Will the realms attempt to authenticate users firsthand
fallback to guest authentication or 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 will
therefore re-offer the cached credentials on a subsequent challenge even though
they may not be valid.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: The authentication and authorization processes can fail for any number of
reasons. There are close to one hundred different documented errors that the authentication
sub-system can process. SGOS makes these errors visible to the administrator as families of
issues or individual issues. Administrators can create very granular rules to handle these
failures. In case of an error, you can decide to take one of three actions:
- Return the error to the client in form of failed authentication / authorization
- Allow the user to proceed unauthenticated
- Allow the user to proceed as guest.
The details of how this process works are described in Slide 14-3 and Slide 14-4.
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.
Q If the error is not on the list, the transaction is terminated.

Q 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 it 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.
Q If the error is not on the list, the transaction is terminated.

Q If the error is on the list, the transaction is allowed to proceed and the user is marked as
not having authorization data.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Q If a user is successfully authenticated but does not have authorization data, the
authenticated=yes condition evaluates it as true and the user has valid authentication
credentials.
Q The user.authorization_error=any is evaluate 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 match, but policy using
group or attribute conditions do not.
Before creating policy to permit errors, you must:
Identify the type of access the transactions should be permitted.
Identify under which circumstances transactions can proceed even if authentication or

authorization fails.
Identify which errors correspond to those circumstances.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 authenticate against the realm

User appears as authenticated and authorized in the
specified realm
6OLGH*XHVW$XWKHQWLFDWLRQ
Instructors Note: Guest authentication allows the administrator to create a policy which
tolerate certain authentication errors and associates the user guest to those transactions. You
need to point out to the students:
- The user guest is a fictitious user, meaning it does not exist in any realm. Do not confuse this
guest account with the built-in (and by default disabled) Guest user in Active Directory
- You can also make the user guest appear to the policy engine as part of a real group in your
realm. Again you do not need to create a user in the realm or take any other action there.
- You need to associate the user guest to a realm; however the user is not authenticated
against this realm. It will appear to the policy engine as authenticated in the realm, which is
logically very different.
Make sure to point out to the students that guest authentication cannot be used in the Admin
Layers and that they should carefully consider which errors to tolerate and which not to.
Guest authentication provides the ability to identify a user as a guest user without having an
actual guest account on a backend authentication server and without having to use the policy
substitution realm <guest> user. A realm is specified to authenticate the guest against but it does
not actually authenticate the user against the backend 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 will attempt the authenticate first.
If the regular authentication fails with a tolerated error though then the transaction will
authenticate as the guest user.
Guest authentication can also be used by itself without any regular authenticate 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Since 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 guest or close and reopen the 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
authenticated
You can also use default groups with any realm, and they can be used when authorization
succeeds, fails or wasn't attempted at all. Default groups allow you to assign users to groups and
use those groups in reporting and subsequent authorization decisions.
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 are assigned as
default. You can specify a single or multiple groups here. In most cases, only a single group will be
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 different groups.
Policy available for default groups includes:
group
authorize.add_group
You are not limited to these conditions and properties in creating policy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Tolerating Errors
6OLGH7ROHUDWLQJHUURUV
Instructors Note: This slide describes the detailed sequence of events when you have a
policy to tolerate errors. As you should have already mentioned in Slide 14-1, in essence you
can configure ProxySG appliance to do one of three things when it encounter and
authorization or authentication error:
1) Return the error to the client
2) Allow the transaction to proceed as user Guest
3) Allow the transaction to proceed as unauthenticated
Depending on the error and the destination one of the three options is more appropriate than
the others.
Important: Tolerating errors and guest authentication are separate actions, however guest
authentication generally depends on tolerating errors.
You may have the need to encourage all users to authenticate using valid credentials anytime it is
possible; however you may also want the users to have access to many (if not all) the resources on
the internet if the authentication and authorization process fails.
The slide details, in four simplified steps, how you can configure your ProxySG appliance to
handle these kind of errors. It is important that you realize that the options detailed in the slide
(return error, proceed as guest, or proceed unauthenticated) can be determined based on a variety
of triggers.
1.
The user initiates transaction with a ProxySG appliance, which 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 slide simple). The user submit the credentials.
2.
ProxySG appliance may or may not connect to the remote authentication server (cached
credentials or authentication simply not really required for that transaction).
3.
ProxySG appliance process the authentication and authorization response from the
authentication sub-system and passes it to the policy engine.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
4.
Based on having configured the ProxySG appliance to tolerate errors or not (and which errors
are tolerated compared to the ones resulting from the authentication of the current
transaction) the user may:
a.
Receive an error notifying the unsuccessful authentication or authorization.
b.
Be allowed to proceed either as unauthenticated user or a guest user.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Persistent Connections
6OLGH7ROHUDWLQJHUURUVZLWKSHUVLVWHQWFRQQHFWLRQV
Instructors Note: This flowchart intends to describe how to manage a new transaction with
in the context of an existing connection between the user agent and ProxySG appliance. The
bottom right part of the flow chart is identical to the flow char in Slide 14-3. The main idea that
you need to deliver in this slide is that when the ProxySG appliance processes a transaction,
which is part of an existing connections, it looks for an user login object. This is where the
guest account plays a vital role.
Important: If a user has failed authentication, it does not have a surrogate credential and the
subsequent transactions will challenge and attempt to reauthenticate the user.
You can have several different transactions happening within the same connection between your
user agent (ex: your web browser) and the ProxySG appliance.
For every transaction, the first step the authentication process takes is to verify if there is already a
user login object for that connection. This basically means verifying the existence of valid
surrogate credentials for that transaction. If the object already exists, then the user is allowed to
proceed to through the policy processing as that user.
When an existing user login object is not found, then SGOS attempts to verify the users
credentials, initiating the authentication process. If the user submits valid credentials, the user is
allowed to proceed through the policy processing as that user. If valid credentials were not
submitted (or did not verify correctly), then based on the policy tolerating the specific
authentication or authorization issue the transaction can be allowed to proceed.
If you allow the transaction to proceed unauthenticated, then you may end up going through this
process at the next transaction. When you allow the transaction to proceed unauthenticated, the
ProxySG appliance does not have a valid user login object for that connection.
If you allow the connection to proceed as guest, then you will not have to go through this entire
process again. For the remainder of the connection, the user login object will have the value of
guest, will be member of the specified realm in the guest authentication rule you created, and will
be member of the groups you defined in the policy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Managing Password Expiration
6OLGH0DQDJLQJSDVVZRUGH[SLUDWLRQ
Instructors Note: This is a practical example on how to use tolerate errors for more than just
allowing a user to proceed through policy as guest. Using a combination of techniques you
can use your ProxySG appliance to do more than just authenticate users.
This slide demonstrates how to use the ability of SGOS to allow administrator to control
authentication errors for 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 ProxySG appliance to enable users to change their password when it is
expired. A proxy, which does not have all of the advanced features of ProxySG appliance will
simply denied access to a user whose password is expired.
By allowing the administrators to granularly control and manage authentication and
authorization errors, you can simply the users experience when browsing.
You can allow the user to change their password in three easy steps:
1.
The user connects to the ProxySG appliance; receives an authentication challenge; and the
user responds by sending the appropriate credentials.
2.
ProxySG appliance validates the credentials with the authentication server; the server
responds with an error informing the ProxySG appliance that the password has expired.
3.
Rather then simply returning an generic authentication failure error to the user, the ProxySG
appliance redirect 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
manage the expired password.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Canceling Login
6OLGH&DQFHOLQJORJLQSURPSW
Instructors Note: While this is another example on how to use the ability the ProxySG
appliance to tolerate authentication errors, you should use it to better explain how the
ProxySG appliance can notify the user of authentication errors.
Immediately after the user initiates a connection with the proxy, ProxySG appliance responds
with an HTTP 401 (or 407 as applicable). There is data in the HTTP response from the proxy,
which contains a properly formatted HTML page. If the user resets the connection, cancels the
connection, or take other similar actions, the content of the HTML page is displayed to the
user. If the authentication fails after the user has sent credentials, a different notification
(detailing the exact error) is sent back to the client.
You are already very familiar with the concepts behind authentication; 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 will
first prompt the user to submit credentials and then send them to the proxy.
The initial HTTP response from the ProxySG appliance 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 where to enter the user name
and the password. The user sees the HTML page only if it 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 in the slide.
If you want to control what happens after the user cancels the login, you need to modify the
HTML page, which the ProxySG appliance sends with the HTTP 401 and HTTP 407. For instance,
if you want the users who do not have an account (they are likely to cancel the login prompt) to
proceed as guest, you need to embed a link in the first HTML page the ProxySG appliance 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 appliance, you need to have a policy bypassing authentication for the virtual
URL associated to that link and authenticate the user making the request to that virtual URL as
guest.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Sample Policy
Redirect a user to a password change page

after a password expiry
6OLGH6DPSOHSROLF\
Instructors Note: This slide basically shows how to implement the policy, which you
conceptually described in Slide 14-5. While you could implement this policy in VPM, using
CPL makes it more clear and more elegant. You can use this as a basis for an on the fly lab.
Make sure that you have setup an environment where you can change expired passwords
from a web page and that you can easily expire users.
The policy, which was conceptually described in Slide 14-5, is implemented in this slide using
CPL. There are three main components to the policy:
1.
A <proxy> layer (or Web Authentication Layer). You configure ProxySG appliance 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://pwdmgmserver/password_change
Based on this sample policies you can create many other useful ones by controlling the necessary
errors to offer your user the best possible experience when browsing.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Best Practices
Carefully determine permitted errors
Advanced URL and access log fields to determine

common errors
https://[proxy-ip]:8082/Auth/Error
6OLGH%HVWSUDFWLVHV
Instructors Note: Tolerating errors is a powerful, yet potentially dangerous tool, if used
incorrectly or irresponsibly. An administrator should want to control very carefully which
authentication and authorization errors to permit. This slide allows you to describe one of a
few advanced URLs, which can be used to better define which errors to permit but also to
better understand possible authentication issues in your organization not necessarily related
to ProxySG appliance.
The ability of allowing ProxySG appliance to tolerate authentication and authorization errors is a
very powerful feature; however, when use 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 is useful for single sign on (SSO) realms that are not supposed to challenge but it
can cause an 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 displayed in the slide or the access log fields
x-sc-authentication-error and x-sc-authorization-error can be used to help
determine which errors are actually being encountered in various circumstances.
When you look at the information available under the advanced shown above, you should focus
on the Group Membership values. In this case you have a relatively large number of errors
compared to the total authentication attempts. It is likely you may have some issue not related to
the implementation and deployment of ProxySG appliance. It would be a good practise in this
case to allow for instance the entire group of errors under
general_authentication_failure.
Determine when guest access is permitted. If guests always login from a specific subnet then you
can likely just authenticate them as guest without challenging for credentials using the subnet as
source trigger.
If guest is to be used as a fallback only, then ensure that policy is written such that both the
authenticate and authenticate.guest actions are matched
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Troubleshooting
User never challenged
Permit Any Errors is the selected option

Verify policy for realms other then SSO
Incorrect users or groups permitted
Refer to the Advanced URLs

Use x-sc-authentication-error and
x-sc-authorization-error in access logging
6OLGH7URXEOHVKRRWLQJ
Instructors Note: The troubleshooting techniques discussed here are relatively basic;
however they allow an administrator to solve the most common issues. Again reinforce how
using the group All is a terribly bad idea.
Explain that no-op is the equivalent of do nothing or no action; this term appears in the
student section of this page.
Also mention to the students that Individual errors must be specified in CPL because of
specific design to make the GUI simpler to manage.
The advanced URL 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 (can use the user.authentication_error and
user.authorization_error conditions).
ProxySG appliance 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 in the advanced URL
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 will be a no-op if the user is

already successfully authenticated
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Guest Authentication Lab

Overview
This lab uses a complete and advanced policy to fully manage authentication (and authorization)
errors and allows access to un-authenticated users. You have an LDAP realm and you want all
users with valid authentication credentials to be authorized to access the Internet via LDAP
authentication. However, you allow users, who do not have valid credentials, to access limited
resources on the Internet.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F SSH Server
F Open SSH version 4.0

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
F PuTTY
F Release 0.60
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 15:SSL Proxy
Instructors Note: SSL proxy is a very powerful feature, virtually unique to Blue Coat. The
SSL proxy feature opens the door to many possibilities for enhancing security and closing
back doors used to circumvent company policies. Some students may feel uncomfortable with
this functionality. You need to present the information in an appropriate manner. It is up to
students and their organizations to decide whether (and how) to apply SSL proxy functionality.
HTTPS, which is simply HTTP over SSL, was designed to offer secure communication between a
client and a server. HTTPS has helped boost online shopping sales. Unfortunately, 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 OCS, 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 terminates forward proxy connections, inspects SSL traffic, determines if 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 may have privacy concerns about using this feature. To alleviate those concerns, you should
combine your SSL proxy deployment with Blue Coat WebFilter (BCWF) software and a local
database. For example, you can use BCWF 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 traffics from the suspicious sites.
This chapter contains a brief introduction to the fundamental concepts behind SSL. You can find
more detailed information in an appendix at the end of this book.
You should become familiar with the following definitions:
Tunnel/Tunneling: Forwarding bytes back and forth between client and server at the Blue
Coat SG
Intercept/Interception: Decrypting SSL connections at the ProxySG
Certificate Validation: Doing various checks on an SSL certificate. These checks include
verification of the issuer signature, dates, and revocation status
CA: Certificate Authority
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
SSL Fundamentals
Secure Sockets Layer (SSL) provides a

encrypted tunnel through which other protocols
can pass
SSL uses public-key cryptography to exchange

a symmetric key
HTTPS is HTTP over SSL
6OLGH66/IXQGDPHQWDOV
Instructors Note: This slide is a summary. If you decided to skip the previous slide, pause for
a moment and make sure that your students are familiar with these concepts.
HTTPS is the same protocol as HTTP. However, HTTPS is delivered over an SSL tunnel. Persons or
parties who do not possess the correct session key cannot view any part of the TCP payload. SSL 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 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 15: SSL Proxy
Certificate Authority
6OLGH&HUWLILFDWH$XWKRULW\&$
Instructors Note: Ask some questions to gauge the familiarity of your audience with this
subject. If everybody is comfortable with the material, you may want to skip this first section of
the chapter. Ask the students what a CA is. If you get a satisfactory answer, then move on. If
not, make sure the concepts are clear before proceeding.
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 (CA), 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.
To explain in detail , in slide 3-2 :
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.
Client requests a secure (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 keypairs 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 (PKI).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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. Windows
Server allows you to create a private CA or create 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 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
SSL Fundamentals
Initial connection in plain text

Asymmetric (long) key used for key exchange
Symmetric (short) key used for data transfer
6OLGH.H\H[FKDQJH
Instructors Note: This is an important slide. Students must understand how information is
encrypted by the client and server. Ensure that students know that servers send a public key
to the client for use in encryption, and that the server then uses its private key for decryption.
This method is called asymmetric encryption. It is only performed for key exchange and
negotiation. Once a symmetric encryption method has been negotiated, actual data transfer is
symmetrically encrypted using the negotiated method.
Slide 15-3 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
SSL Proxy
AV scanning
Content filtering
Control server certificate verification
Apply security policies to all Web traffic

HTTP, HTTPS, IM, etc.
6OLGH3RVVLELOLWLHVRI66/SUR[\
Instructors Note: This slide introduces a few of the possible ways that network
administrators can use the SSL proxy. However, do not discuss how Blue Coat implements the
SSL proxy yet. Use the slide that follows.
The SSL proxy functionality 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, 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
back doors 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, 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. Previously,
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 Blue Coat 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 hostname 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
System Architecture
1. Client sends SSL CLIENT HELLO to Blue Coat SG.

2. Blue Coat SG sends CLIENT HELLO to server.
3. Server sends SERVER CERTIFICATE to Blue Coat SG.

4. Blue Coat SG sends its own certificate to client.
6OLGH66/SUR[\VHWXS
Instructors Note: When discussing the SSL proxy feature, try not to use the word attack or
hacking, or a similar term, to refer to the role of the ProxySG. You can say that ProxySG is, by
design, the policeman in any of your networks user conversations.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Basic Implementation
6OLGH%DVLF66/SUR[\LPSOHPHQWDWLRQ
Instructors Note: This is an important slide because it enables you to graphically illustrate
the concepts discussed earlier. Make sure that students understand how the ProxySG acts as
both the client and server in SSL transactions.
Slide 15-6 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 illegal content, encrypts the data using the clients
symmetric key, and delivers it to the client.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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\
Instructors Note: This slide shows the default behavior for the SSL proxy. You can use this
slide to discuss user-sensitive data and privacy so that students are aware of the privacy
concerns that can arise with SSL proxy use.
The default behavior is not to intercept SSL traffic. To allow SSL content to be examined, select the
Intercept as HTTPS radio button in the Add SSL Forward Proxy Object dialog box. 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 (for example, BCWF) to create rules to exclude financial, 401k, and other user-sensitive
sites from interception.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: Show the content of this slide interactively. There are two new layers;
create a policy in each one of them.
The Visual Policy Manager (VPM) features two SSL-related layers.
The SSL Intercept Layer has the following columns: Source, Destination, Action Track, and
Comment.
The SSL 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 like SSL version, ciphers, etc.
Note:
These layers do not have the Time column because it has no meaningful usage here.
The SSL Intercept Layer does not have a service either (as it is applicable to SSL only).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Lab Notes for SSL Proxy

Overview
Students will configure their ProxySG to intercept HTTPS traffic.
IP Addressing Scheme
Equipment
Students SG
Role
IP Address
Proxy
172.16.90.2x

Software/Hardware
Version/Model
Firefox
Version 2.0.0.5
Internet Explorer
Version 6.0 or above
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build

Software/Hardware
Version/Model
Firefox
Version 2.0.0.5
Internet Explorer
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build
Desired Results
Students will know that their HTTPS connection has been intercepted when they see the certificate
error message.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 16:Bandwidth Management
Instructors Note: This chapter describes how the Bandwidth Management (BWM) feature
works both from the point of view and the user and the actual architectural implementation.
Slides from 12-1 to 12-7 are relatively simple and descriptive; the last slides in the chapter go
into lots of details. As in instructor you can decide to skip them. You will be reminded again in
the notes for those slides that you can skip them.
Introduce the conversation about BWM as a tool that allows organization to prioritize business
critical traffic without necessarily blocking all non-business related or recreational resources
on the Internet.
BWM assumes particular important at the remote locations, when you usually have more
limited bandwidth and you want to make sure than the most of it is used to access applications
and data at the HQ and not for personal use.
You should also set the expectation at the correct level for this feature. Mostly point out that
ProxySG does not change TCP window size nor artificially delays specifically TCP ACK
packets. The BWM engine in ProxySG uses the concepts behind the Hierarchical Token
Bucket (HTB).
This approach, while it does not guarantee that the limits for bandwidth are respected down to
the byte (a small margin of error is inherited in this process), it is by many considered to be
one of the most elegant and effective.
BWM using HTB relies on four fundamental concepts: priority, maximum, minimum, and
parent-children relationships.
Additionally this chapter compares BWM with Admission Control for multimedia streaming
applications.
Bandwidth Management (BWM) allows you to classify, control and, if required, limit the amount
of bandwidth used by different classes of network traffic flowing into or out of the ProxySG and
destined for single or multiple devices.
Bandwidth management provides the following benefits:
Guarantees that certain traffic classes receive a specified minimum amount of available
bandwidth. (See note below.)
Limits certain traffic classes to a specified maximum amount of bandwidth.
Prioritizes certain traffic classes to determine which classes have priority over other classes for
available bandwidth.
Bandwidth Management relies on user-defined bandwidth classes and policy rules to manage the
available bandwidth coming into or out of the ProxySG appliance. There are four characteristics of
bandwidth classes: minimum bandwidth, maximum bandwidth, priority, and parent designation
(used to configure class hierarchies).
Minimum bandwidth works by guaranteeing a predefined amount of bandwidth (if available on
the network) to the class. Similarly, maximum bandwidth limits the amount of bandwidth that a
particular class may use. Classes can also be prioritized so that certain traffic receives bandwidth
before others. To implement minimums or prioritization, a class hierarchy must be created with a
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
maximum bandwidth allocation. This allows the appliance to determine how much bandwidth is
too much for a low or medium priority bandwidth class. Creating class hierarchies provides the
most flexibility for Bandwidth Management. Class hierarchies allow administrators to apply
classes at a granular level, taking various criteria into consideration to determine the final
bandwidth allocation allowed.
To determine which class to assign to a particular connection, the ProxySG appliance evaluates the
configured policy to determine if any of the connection attributes match the policy rules assigned
to bandwidth classes. Blue Coat Policy has a rich set of triggers that can be evaluated to classify
traffic flows this comprehensive set of triggers include, but is not limited to, user, group,
destination, protocol, subnet, content-filter category, or DSCP value. By creating classes and
assigning specific types of traffic to them, you can effectively control how the available bandwidth
is used.
An administrator managing a branch office wants to ensure that no more than half of the total
bandwidth available is used for HTTP or FTP traffic to guarantee that other business-critical
applications continue to function. However, when the CEO visits this branch office, she should
have priority over other employees when using this allocated bandwidth. To accomplish this, the
administrator:
Creates a bandwidth class Branch Office and configures the maximum bandwidth to an
amount equal to half of the total available bandwidth.
Creates a policy rule for the Branch Office class, assigning all HTTP and FTP traffic to this
bandwidth class.
Creates two additional bandwidth classes Employees and CEO and sets the appropriate
priorities.
Creates policy rules identifying the CEO and everyone else; these rules assign such traffic to
either the Employees or CEO bandwidth class.
Makes the Branch Office class the parent class of both the Employees and CEO classes.
The administrator now has a bandwidth hierarchy. Bandwidth is limited by the configuration of
the parent class, and the two child classes are prioritized to determine how they share any unused
bandwidth. Because no minimums have been set, the highest priority class has the first
opportunity to use all of the available bandwidth; whatever is left then goes to the next priority
class.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 16: Bandwidth Management
Bandwidth Management (BWM)

Protect performance of key applications
Prevent bandwidth-greedy applications from

impacting other programs
Provide bandwidth for applications that require a persession amount of bandwidth
Balance important, bandwidth-intensive

applications
6OLGH%DQGZLGWKPDQDJHPHQWEHQHILWV
Instructors Note: This is an introductory slide. Remind the students that BWM allows you to
create policies that maximize business critical traffic performance, while having to necessarily
block all other traffic.
In a world where clients, servers, and data all come in different types, treating all network
connections as a single traffic flow does not give administrators the flexibility to ensure that
business-critical applications perform as required. Imagine finding out that the CEO could not
access critical reports because an employee spent his lunch break watching streaming videos.
Using Bandwidth Management, administrators can control network traffic flow so that the
appropriate users, groups, or applications receive the proper network resources.
Bandwidth Management is often used to guarantee access to business-critical applications or Web

sites. For other, more obscure traffic on the network, Bandwidth Management can be used in
conjunction with content-filtering to make bandwidth management decisions based on the type of
sites being accessed. Specifically:
BWM prevents resource-greedy applications such as peer-to-peer and streaming video

from impacting other, more important programs, such as e-mail and client-server
applications.
BWM allows administrators to provide for applications that require a per-session amount of
bandwidth. For instance, multimedia applications may require a certain amount of bandwidth
in order to enable all their features.
BWM enables administrators to balance important bandwidth-intensive protocols and

applications, such as HTTP and instant messaging (IM).
Without BWM, network administrators may be forced to block IM and streaming audio and video.
However, implementing BWM, administrators can allow controlled access to these
less-than-critical but still useful tools.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM Hierarchies and Priorities
6OLGH%DQGZLGWKKLHUDUFKLHVDQGSULRULWLHV
Instructors Note: This is easily the most important slide in the chapter as it graphically
shows how ProxySG manages and organized bandwidth classes. The root class is often
implied, meaning that most implementation will only have C1, C2, and C3 as in this example.
However it is a good idea to create a root class and assign to it the actual parameters for your
Internet pipe.
Point out the three following key elements:

1) The priority (from 0 to 7) is only meaningful among siblings. For instance C1a does not have
higher priority (7) than C2 as they are not siblings.
2) The sum of the minimums of all children cannot exceed the min of the parent class
3) The maximum value for the maximum of all the children cannot be higher than the
maximum of the parent.
Unless you create a root bandwidth class, point 2 and 3 are not enforced on the parents (in
this case C1, C2, and C3).
Important: Point out that C1, C2, and C3 are just reference names. You should use meaningful
names. Additionally you can have as many BWM classes as you like at each level
The first step in managing bandwidth is to create bandwidth classes. Each bandwidth class
represents a particular type of network traffic. You create classes either through the Management
Console or the command-line interface (CLI).
Once you have created a bandwidth class, you can write policy through the Visual Policy Manager
(VPM) or CLI. You can guarantee that a class receives a minimum amount of available bandwidth.
You also can limit the amount of bandwidth for the class.
In addition, you can set priorities for different classes for available bandwidth, depending on your
organizations business requirements and network resources.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Note:
In most cases, if you plan to manage the bandwidth of streaming media protocols
such as Windows Media, Real Media, or QuickTime Blue Coat recommends
that you use the ProxySGs streaming features instead of its bandwidth-management
features. You cannot use both at the same time.
Creating a bandwidth class allows you to allocate a portion of available bandwidth to a particular
type of traffic. Putting that class into a bandwidth hierarchy allows you to set priorities for
available bandwidth among multiple classes.
To build a hierarchy, you create one bandwidth class as the parent and then create other
bandwidth classes as the children. Child classes can have children of their own.
The parent node must have the available bandwidth to satisfy the child minimums. If multiple
hierarchies compete for the same available bandwidth, the ProxySG cannot guarantee the
minimums defined for each class.
You can set priorities to give some bandwidth classes precedence over other bandwidth classes.
However, priorities can be set only for sibling classes child classes with the same parent. You
also can set priorities for hierarchies if they have the same parent class.
In order to set priorities, you must set a maximum somewhere in the hierarchy. When a maximum
is set for a class, queues of packets form, waiting to be sent. This gives the ProxySG the
opportunity to apply priority settings. However, if no limit is set, packets are sent as soon as they
arrive, and the ProxySG cannot set priorities.
If there is excess bandwidth, the class with the highest priority gets the first opportunity to use it.
When the highest-priority class uses all the bandwidth it needs or is allowed, the next-highest
class has its turn. If two classes in the same hierarchy have the same priority, they share the excess
bandwidth in proportion to their maximum settings.
In the example shown in Slide 16-2, the company has an E1 pipe to the Internet, which allows a
maximum bandwidth of about 2 Mb/s. The administrator has created three bandwidth classes:
C1, C2, and C3. The sum of the maximum allowed for the three classes is 1.2 Mb/sec.; the
remaining 800Kb/s can be used for the other traffic flowing through the ProxySG at any time.
Indirectly the administrator has defined the maximum available for the traffic which does not fall
into any of the three existing bandwidth classes. Then sum of the minimums available to the three
classes is 662Kb/s. If there is sufficient traffic going through the ProxySG to occupy at least the
minimum per each of the three classes, the maximum bandwidth available for all other traffic will
be 2Mb/s minus 662 Kb/s (about 1.3 Mb/s).
The excess bandwidth, if any, is distributed to the parent classes (C1, C2, and C3) according to
their priority. Each class manages its own excess bandwidth with its children using the relative
priorities among the them. The priority is a parameter meaningful only between siblings. For
instance C3 has the highest priority as a parent class; its definition of priority 1 is not relevant to
the priority definition for C2a, which is 1 as well.
To better understand how the bandwidth is shared among siblings based on priority, you need to
learn about Hierarchical Token Bucket theory (HTB), discuss later in this chapter.
Important: BWM does not reserve bandwidth or guarantee that available bandwidth can
sustain any of the bandwidth minimums configured on the ProxySG. The feature
can only control the traffic flowing through the proxy and prioritize some of the
flows according to configured policy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM Traffic Flow
6OLGH7UDIILFIORZDQGEDQGZLGWKPDQDJHPHQW
Instructors Note: There are 4 types of bandwidth that you can control with ProxySG. You
can control all of them, none of them, or sum of them. Typically, for forward proxy customers,
server inbound is the main priority. For the reverse proxy customers, both client inbound and
client outbound are important. Try to engage the students in a conversation.
Question: What is the one flow that you want to control and why? Discuss the answers.
Important: Most student have a hard time understanding how a forward proxy can control
server inbound. The slides at the end of the chapter help you answering this, but for now just
mention how delaying requests help ProxySG control the amount of data it receives in
response.
ProxySG allows you to control bandwidth in any direction. Using a relatively simple queueing
algorithm, ProxySG can manage inbound and outbound bandwidth without having to modify
critical parameters like the size of the TCP window for a connection, or artificially delay specific
TCP ACK packets. The queueing approach provides broader BWM scheme that covers both TCP
and UDP and also support BWM for inbound and outbound traffic.
To manage the bandwidth classes you create, you need to write policy rules to classify traffic
flows. Flows are defined as a set of packets belonging to the same TCP/UDP connection that
terminates at, originates at, or flows through the ProxySG.
A single request from a client involves two separate connections: one from the client to the
ProxySG and the other from the ProxySG to the origin content server. Within each of these
connections, traffic flows in two directions; therefore, traffic can be classified into one of four
types:
Client inbound: traffic flowing into the ProxySG from a client making a request to a server
Server outbound: traffic flowing out of the ProxySG to a server to transmit the request
Server inbound: traffic flowing back into the ProxySG from a server in response to a client
request
Client outbound: traffic flowing back out of the ProxySG to a client to transmit the response
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Each policy rule can apply to only one traffic flow type. However, you can use the same
bandwidth management class in different policy rules so that one class can manage bandwidth for
several types of flows according to different criteria.
If multiple policy rules match a flow and try to classify it into multiple bandwidth classes, the
most recent classification done by policy applies.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM Bandwidth Maximums
6OLGH%DQGZLGWKPD[LPXPVHWWLQJ
Instructors Note: Definitely this is the easiest slide to discuss. It is also describing what the
students will be doing in the first lab. The idea behind maximums is very simple: more users
connect to share the same bandwidth class, less bandwidth each user receives. This is not a
problem for most application (maybe for the user it is).
Question: Which protocols are sensitive to time delays and why?

Answer: Protocols based on audio and/or video (VoIP, MMS, etc). This is because the brain
needs to see images at a minimum speed and hear sounds with a maximum allowed delay in
order to understand them.
Setting a maximum for a bandwidth class puts a limit on how much bandwidth is available to that
class. It does not matter how much bandwidth actually is available; a class can never receive more
bandwidth than its maximum.
To keep a bandwidth class from using more than its maximum allotment, the ProxySG queues
packets associated with that class until the bandwidth used is no greater than the specified
maximum.
Maximum settings unlike minimum and priority settings can reduce the flow for a class. The
drawing on the left in Slide 16-4 shows an over-subscribed network. When bandwidth classes are
oversubscribed, traffic continues, but at a slower rate, as shown by the drawing on the right.
However, in extreme cases, connections may fail. Also, with the maximum setting, unused
available bandwidth can go to waste.
Unused bandwidth can go to waste with the maximum-bandwidth setting, while the
minimum-bandwidth settings and priority levels always distributes any unused bandwidth as
long as classes request it. However, priority levels are not meaningful without a maximum
somewhere in the hierarchy. If a hierarchy has no maximums, any class in the hierarchy can
request and receive any amount of bandwidth regardless of its priority level.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Important: The maximum of the maximum for all root level classes, cannot exceed the actual
available bandwidth. Since the ProxySG is not really aware of your actual pipe to
the Internet, you need to ensure consistency at least for the root level. ProxySG
enforces this constraints on the children classes.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM Admission Control v. BWM
6OLGH$GPLVVLRQFRQWUROYEDQGZLGWKPDQDJHPHQW
Instructors Note: The question you asked for Slide 12-4 makes sense here. Since MMS
applications are time-delay sensitive, ProxySG offers, in addition to BWM, admission control.
The key difference is that in Admission control, each client is not allowed to go below the
minimum requested. If new users request bandwidth they are denied until other current users
disconnect. You should use Admission Control for business critical application, BWM for
recreational use of MMS.
Important: There is no Admission control for the VoIP protocols.
You can control streaming bandwidth using two different methods: you can use the streaming
features called Admission Control, or you can use the bandwidth management features described
so far. You should not, however, use both methods to control streaming bandwidth. The way that
each method controls bandwidth differs.
Limiting streaming bandwidth using the streaming features works this way: if a new stream
comes in that pushes above the specified bandwidth limit, that new stream is denied. This allows
existing streams to continue to get the same level of quality they currently receive.
Limiting streaming bandwidth using the bandwidth management features works this way: all
streaming traffic for which you have configured a bandwidth limit shares that limit. If a new
stream comes in that pushes above the specified bandwidth limit, that stream is allowed, and the
amount of bandwidth available for existing streams is reduced. This causes streaming players to
drop to a lower bandwidth version of the stream. If a lower bandwidth version of the stream is not
available, players that are not receiving enough bandwidth can behave in an unpredictable
fashion. In other words, if the amount of bandwidth is insufficient to service all of the streams,
some or all of the media players experience a reduction in stream quality.
You should choose admission control instead of bandwidth management when the quality of
streaming data is important, such as during a teleconference. Admission control preserves the
quality of the data by limiting the number of connections while bandwidth management shares
bandwidth to grant additional client requests.
For most circumstances, Blue Coat recommends that you use the streaming features to control
streaming bandwidth rather than the bandwidth management features.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM - Minimums
6OLGH0LQLPXPEDQGZLGWKVHWWLQJZLWK3UR[\6*QRWLQEULGJLQJPRGH
Instructors Note: Use this slide to start a conversation with the class. The idea of the slide is
to represent the following:
- The users over HTTP generate at the moment over 1000 Kb/s of traffic
- The other users, not going through the proxy, generate over 700 Kb/s of traffic
- The HTTP bandwidth class has a minimum of 1000 Kb/s
- The maximum pipe to the Internet is 1500 Kb/s
Question: Can ProxySG satisfy the requirement of minimum bandwidth?

Answer: No. Since there is more traffic than the Internet pipe can handle and ProxySG only
has control on the HTTP portion, the traffic will be slowed for all sections. The ProxySG cannot
therefore guarantee the minimum
Question: Where can you re-position the proxy so that minimum settings can be enforced?
Answer: In bridging mode between the core switch and the firewall (Move to the next slide)
Setting a minimum for a bandwidth class guarantees that the class receives at least that amount of
bandwidth, provided that the bandwidth is available. If the available bandwidth is not enough to
cover the minimum, there is no guarantee that classes will receive their minimum bandwidth.
The ProxySG can control only the traffic that flows through it. So if you want to set minimums, it is
a good idea to set your ProxySG in bridging mode.
The drawing in Slide 16-6 shows a ProxySG configured to give a minimum of 1,000 kilobits of
available bandwidth to HTTP traffic flowing through it. Other traffic on the network takes another
700 kilobits of bandwidth. However, because the ProxySG is not acting as a network bridge, it has
no control over the other, non-HTTP traffic.
Because the network has only 1,500 kilobits of bandwidth available, it cannot accommodate both
the HTTP bandwidth class minimum of 1,000 kilobits and the 700 kilobits of other traffic. So both
HTTP traffic and other traffic slow to a total of no more than 1,500 kilobits.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
If an internal/leaf node has a minimum defined, the class hierarchy guarantees that this minimum
is guaranteed to the class when there is bandwidth available for the class hierarchy. If there are
multiple hierarchies defined which compete for the same available bandwidth or if the available
bandwidth for a class hierarchy is less then the minimum, BWM cannot guarantee the minimums
defined at each node. So then administrator should be careful not to create class hierarchies, which
share the same network bandwidth if he wants to guarantee minimums.
Important: The sum of the minimums for all root level classes, cannot exceed the actual
available bandwidth. Since the ProxySG is not really aware of your actual pipe to
the Internet, you need to ensure consistency at least for the root level. ProxySG
enforces this constraints on the children classes.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM Minimums
6OLGH0LQLPXPEDQGZLGWKVHWWLQJZLWK3UR[\6*LQEULGJLQJPRGH
Instructors Note: There is not much to cover on this slide as it shows the result for the
discussion you already had on Slide 12-6. Reiterate how now the proxy can see all traffic and
even if it is no intercepting it all, it can enforce the minimums on the intercepted traffic.
As discussed in the previous slide, ProxySG can only control the traffic that it processes. If there
are streams of data, which can access the outside world using a path, which does not include the
proxy, then it is obvious that ProxySG cannot affect that bandwidth. Even worse, the bandwidth
that cannot be controlled by the proxy, can void the ProxySG attempts of satisfying the minimum
requirements that you set forth in the definition of a bandwidth class.
By strategically deploying ProxySG in the network where it has the opportunity to observe all the
traffic flowing out of your network, it can satisfy the minimum requirements that you defined.
The ProxySG ships with a pre-defined class hierarchy. The maximum and minimum values for
this bandwidth is set to unlimited, which means that by default there is bandwidth management
for any type of traffic, just classification. You have to change this default hierarchy by adding,
deleting, or modifying classes or at the minimum assign minimum and maximum values, to suit
his Bandwidth Management needs.
Using the example describe in Slide 16-2, at the root level, ProxySG has four buckets, one for each
of the three defined classes C1, C2, and C3 and a fourth one for all other traffic. While ProxySG
does not process (proxy) the traffic which does not match any of the proxy services, it can still
detect and control its flow. All uncategorized traffic and bypassed traffic is allocated to the fourth
bandwidth bucket. At this point ProxySG can control the flow for all traffic and can guarantee the
minimum setting for C1, C2, and C3 even if there is other extraneous traffic flowing though the
proxy.
In the end, if you want the minimum bandwidth settings to be meaningful, you have to deploy
ProxySG in bridging mode. This is Blue Coat recommended deployment; additionally you can
configure you ProxySG to be the default gateway. This deployment option, while practical is not
recommended.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM - Architecture
6OLGH%:0DUFKLWHFWXUH
Instructors Note: This is an optional slide. You do not have to go into the details, but if you
want, point out the following key aspects:
1) All inbound and outbound traffic goes through the BWM Queuing algorithm (this helps
answer the questions for Slide 12-7)
2) The policy engine reads the data from the BWM classifier which then passes it back to the
queue.
The administrator uses the Management Console or the CLI to create and configure bandwidth
classes. The administrator also places the classes into a bandwidth class hierarchy and allocates
the maximum, minimum bandwidth and priority for the classes.
Once the bandwidth allotment is done, the administrator uses the Visual Policy Manager which is
accessible through the Management Console or composes Content Policy Language to create
policies for managing the traffic flow for the classes. Each policy rule can only apply to one of four
traffic flow types Client inbound, Client outbound, Server inbound and Server outbound.
The Web Access layer in the Policy engine needs to have knowledge of the BWM classes the
administrator creates so that its BWM policy rules can be evaluated and verified at compile time
for correctness. The BWM component of the ProxySG works between the Network Interface and
the IP layer of the OSI module. When a client makes a HTTP request, the ProxySGs classifier
identifies the traffic and provides actual bandwidth services. The classifier prioritizes the packet, it
places it into a queue. The BWM queuing module uses the classifier to figure out the correct queue
to use for a particular flow. BWM Queuing Module uses the Hierarchical Token Bucket (HTB)
algorithm to classify the packets into various queues.
Analyzing the slide in more details, you can notice how:
1.
The BWM Queuing primarily interacts with the network layers (IP) to control the bandwidth
utilized by the traffic flowing through the SG.
2.
The BWM Classifier allows the Application Proxies to specify the class that a particular
connection belongs to. The queuing module uses the classifier to figure out the correct queue
to use for a particular flow.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
3.
The administrator uses GUI or CLI to build and modify Bandwidth Management class
hierarchies.
4.
The Policy Layer will need to have knowledge of the Bandwidth Management classes that are
created by the administrator so that its bandwidth management policy rules can be evaluated
and verified at compile time for correctness.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
BWM Tagging Packets
6OLGH%:0SDFNHWGHOLYHU\
Instructors Note: This is an optional slide. The most important role for the BWM engine is to
properly classify the packets based on the classes created. You can use virtually any of the
triggers available in the Web Access Layer to assign bandwidth. You can allocate bandwidth
by user, protocol, category, host, etc. The policy puts the packets in the different classes, then
the queuing engine decide which packet to extract from which class in order to satisfy the
BWM classes requirements.
The ProxySG tags data in order to implement bandwidth management policy. Data is tagged
according to its protocol at the application layer. The BWM Classifier enqueues or separates
packets into the appropriate bandwidth management class according to their application tags. In
the slide, the BWM Classifier sorts packets 1-4. For example, if Class 1 is HTTP, Class 2 is FTP, and
Class 3 isP2P, then the Classifier sorts packets and drops them into respective classes. HTTP
packets 1 & 3 into Class 1, FTP packet 2 in Class 2 and P2P packet 4 in Class 3.
Packets are then put in virtual queues. Each queue is processed using a first-in first-out approach
(FIFO). The Hierarchical Token Bucket (HTB) algorithm in the BWM Queuing module determines
the order in which the packets are sent according to the bandwidth class, policy and the available
bandwidth. Then the packets are de-queued or delivered based on the decision.The rate at which
packets are pulled from each queue is based on the policies. Once the packet is extracted from the
queue, it is inserted into the network.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Hierarchical Token Bucket (HTB)

Classifies packet into various queues
Uses concepts of tokens and buckets
Minimum and maximum bandwidth allocations
Uses priority to distribute excessive bandwidth

Lower priority queues to temporarily borrow currently
unused bandwidth from queues with higher priority
6OLGH+LHUDUFKLFDOWRNHQEXFNHWWKHRU\
Instructors Note: This is an optional slide. The HTB theory is widely used in the Linux and
Unix kernels to manage process priority but it can be used also to manage network traffic. At
the basis of the HTB you have the concept of priority and the ability for children to borrow
bandwidth from the parents based on their relative priority.
Each bandwidth class is seen essentially like a bucket. The bucket is filled with tokens. Only if
there are tokens in the bucket, then the system can extract packets from the queue
representing that BWM class.
The Hierarchical Token Bucket (HTB) theory of traffic shaping helps classify packets into various
queues using criteria set by the system administrator. HTB uses the concepts of tokens and
buckets along with class based bandwidth allocation and filters to allow complex and granular
control over traffic.
In order to control the rate of de-queueing, BWM Queuing generates tokens at a desired rate and
will only dequeue packets or bytes if a token is available. Otherwise packets are deferred.
Delaying packets in this way introduces latency. A bucket contains a number of tokens. The
bucket is filled with tokens according to the rate. Bucket size limits number of instantaneously
available tokens. If the tokens are not used, the bucket fills up. If tokens are used the bucket will
not fill up. So, the rate at which the packets are de-queued depends on the availability of tokens
and the size of the bucket.
Sometimes certain classes with a higher bandwidth allocation will have surplus tokens and there
will be other classes that are starved for tokens. HTBs borrowing mechanism solves this problem.
HTB allows lower priority queues to temporarily borrow currently unused bandwidth from
queues with higher priority.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
HTB Borrowing
6OLGH+7%%RUURZLQJFRQFHSW
Instructors Note: This is an optional slide. It is actually pretty simple graphical

representation of the HTB and its ability to borrow token from parents to children.
It also shows you the same tree structure that the ProxySG uses to manage the relationship
between bandwidth classes.
Queues are first organized in a tree with root, inner root and leaf. Each classification inherits
bandwidth restrictions from its parent node. Children classes borrow tokens from their parents
once they have exceeded their rate (minimum bandwidth for a given leaf class). A child class will
continue to attempt to borrow until it reaches the ceiling (the maximum bandwidth for the child
class). Then the child class will queue packet for transmission until more tokens are available.
In order for the borrowing model to work, each class must have an accurate count of the number
of tokens used by itself and all its children. Any token used in a child or leaf class is charged to
each parent class until the root class is reached. Any child class which wishes to borrow a token
will request a token from its parent class, which if it is also over its rate will request to borrow from
its parent class until either a token is located or the root class is reached. So the borrowing of
tokens flows toward the leaf classes and the charging of the usage of tokens flows towards the root
class. Shaping of traffic only occurs in leaf classes. HTB does not delay packets in inner classes.
The bandwidth management subsystem implements a Hierarchical Token Bucket (HTB) algorithm
to share the bandwidth in the class hierarchy. For the HTB algorithm to work correctly, the
bandwidth management subsystem implements certain rules and restrictions for creating a valid
bandwidth management class hierarchy:
Each flow can only belong one bandwidth management class.
Once a flow is classified to belong to a bandwidth class, that class is penalized for all packets
that belong to that flow.
The sum of the minimum bandwidths of all the children of a given parent node should not
exceed the maximum bandwidth defined for the parent or any of his ancestors.
Max on child cannot exceed max on parent.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Bandwidth Management Labs

Overview
Bandwidth management allows you to control the amount of bandwidth used by different classes
of network traffic flowing into or out of the Blue Coat SG appliance. By managing bandwidth
you can:
Guarantee that certain classes of traffic receive a minimum amount of available bandwidth.
Limit certain classes of traffic to a maximum amount of bandwidth.
Determine which classes of traffic have priority over other classes.
Protect the performance of key applications.
Note:
The ProxySG appliance does not reserve bandwidth or otherwise guarantee that
available bandwidth can sustain any of the bandwidth limits configured on it. The
ProxySG appliance only shapes various traffic flows passing through it and prioritizes
some flows according to configured policy.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 17:Managing Streaming Media
Instructors Note: The goal to this chapter is show at a very high level what are the features
and functionalities, which are available in SGOS to better manage streaming media. The two
main concepts that the user needs to understand are: 1. Delivery methods used for multimedia
streaming (MMS) 2. Protocol hand-off from HTTP to MMS In particular point out that ProxySG
can manage MMS over TCP and UDP. At this point you can ask the following:
Question: Besides Streaming, which other UDP based protocol ProxySG can intercept?
Answer: DNS over UDP. Spend some time discussing the difference between a live stream
(when the data is broadcasted live and it not available afterwards) and video-on-demand
(VOD), when the stream comes from a file and can be started by different people at different
times.
Based on the knowledge level in you class you may also discuss briefly the fundamental
concepts behind multicasting. You can use the following paragraph for some basic concepts
about it. IP multicast is designed to allow one source to talk to many destinations over an IP
network. Multicast is used to reach a large and unknown number of recipient minimizing the
amount of traffic that the source generates. Multicast relies on the existing network
infrastructure by efficiently requiring the source to send a packet only onceand allowing other
intermediate devices like switch and routers, to propagate the packets to the various users.
ProxySG supports Microsoft Windows Media, Real Networks RealPlayer, and Apple
QuickTime; however, the various players might experience unexpected behavior dependent
upon certain SGOS configurations and features. Feature sections list such interactivities, as
necessary. For a list of the most current versions of each supported client, Release Notes for
the release you are using in class
At its most basic, streaming media is a form of content delivery. Streaming media is used to
deliver many types of content such as Internet radio, video clips, public address, etc. With
streaming media, video and audio content are delivered over the Internet. This makes it possible
for a client to 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 ProxySG appliance provides the following features:
Streaming media files can be live or prerecorded.
Employs flexible delivery methods: unicast, multicast, HTTP, TCP, and UDP.
Ability to seek, fast-forward, reverse, and pause (video-on-demand only).
Ability to play entire file and control media playback, even before it is downloaded.
Adjust media delivery to available bandwidth, including multi-bit-rate and thinning support.
Using the ProxySG appliance for streaming delivery minimizes bandwidth use by allowing the
ProxySG appliance to handle the broadcast and allows for policy enforcement over streaming use.
The delivery method depends on if the content is live or video-on-demand.
Additionally, there are many ways that the ProxySG appliance 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
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 use of ProxySG appliance 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 appliance supports the following streaming media players:
Microsoft Windows Media
RealNetworks RealPlayer
Apple QuickTime
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 17: Managing Streaming Media
Managing Streaming Media

Content Types
Live Streams
Video-on-demand
Caching
Content pre-population
Authentication
Partial and complete object caching
6OLGH0DQDJLQJ6WUHDPLQJ0HGLD
Instructors Note: The slide reassumes the concepts that you are going to discuss in the
chapter. Use this slide to cover some of the information that you have in the instructor notes at
the beginning of this chapter. Particularly point out that for MMS, ProxySG does partial and
complete object caching (VOD only).
In the context of the ProxySG appliance, there are two types of streaming media content:
Live Stream: A live stream is a stream of media content that is occurring live. This can include
speeches, sporting event, or concerts. This streams are watched in real time, as they are
happening. Since the live stream happens in real time, it is not cache on the ProxySG
appliance.
Video-on-demand: This type of streaming media content can be accessed at anytime.

Additionally, it can paused, rewound, and fast-forwarded at the control of the viewer. Since
this streaming media content is stored on a media server, it can be cached on the ProxySG
appliance.
The ProxySG appliances ability to cache streaming media content can be used to optimize
bandwidth usage when requesting video and audio materials. With caching, the client potentially
never has to connect to the OCS to access the requested material.
Content pre-population: The ProxySG appliance 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 cache on the ProxySG appliance, but required
authentication on its OCS, will also require authentication if it is coming from the ProxySG
appliance.
Partial and complete caching: Content can be cached completely or partially on the ProxySG
appliance. Completely cached content makes it possible for the client to access the content
they want without ever having to connect to the OCS. When accessing partially cached
content, the client will receive the cached data from the ProxySG appliance and whatever data
is missing will come from the OCS.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Processing Streaming Content
6OLGH3URFHVVLQJ6WUHDPLQJ&RQWHQW
Instructors Note: Use this slide to discuss in details the differences between a live stream
and an VOD. In Slide 17-2, the two users on the bottom are watching the live stream. Since
live streams start and end at the same times for all users, ProxySG can take advantage of
multicasting and download the stream from the source once and then split it internally on the
LAN, with considerable bandwidth saving. You can show the multicasting settings from the
Management Console > Configuration > Proxy Settings > Streaming Proxies.
The two users on the top of the slide are watching VOD; since it is practically impossible that
both users start the stream at the same time, multicasting would not help; however, the
ProxySG still downloads the information only once and then delivers it to all users via unicast.
Again, this behavior results in significant bandwidth savings on the external link and much
improved performances for the users (content served locally).
The ProxySG appliance 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 appliance can serve many clients through one unicast connection by
receiving the content from the origin 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 prerecorded content. A common
example is a company president making a speech to all employees.
Video-on-Demand: An SG appliance can store frequently requested data and distribute it

upon client requests. Because the SG appliance is closer to the client than 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 SG appliance 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 or news broadcasts.
The ProxySG appliance can take a unicast stream from the OCS and deliver it as a multicast
broadcast. The ProxySG appliance takes a one-to-one connection and splits it into a one-to-many
stream. This allows for saved bandwidth on the server side.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The ProxySG appliance can support a multitude of multicasting forms such as

multicast-to-unicast, unicast-to-multicast (shown above), and multicast-to-multicast.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Large Scale Streaming Delivery
6OLGH/DUJH6FDOH6WUHDPLQJ'HOLYHU\
Instructors Note: This slide shows how you can utilize the many streaming feature offered
by ProxySG not just on a single network but also on your entire WAN. In this case all the 8
different users in the 3 different networks are watching file from the streaming server. These
can be VOD or live streams. Regardless of the type of stream, there are only two unicast
streams leaving the network to the left of the slide; one per each LAN on the right side of the
slide.
Question: How many unicast streams will you have in case of VOD across the WAN, without
the two ProxySG on the right hand side of the slide?
Answer: Six streams.
The slide above is showing how the ProxySG appliance can be used to successfully distribute
streaming media content over a WAN while saving bandwidth.
In this deployment, thanks to the use of ProxySG appliances, there only needs to be one
connections to the origin Media Server. The first ProxySG appliance is able to take the streaming
date from the Media Server and redistribute it as is necessary. The two clients at the connected to
the first ProxySG appliance can access the data through it, instead of directly connecting to the
Media Server.
The two remote locations can also access the streaming media content from the Media Server
through their own ProxySG appliances. The first ProxySG appliance 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 appliance can
stream the content to their individual networks.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Limiting Bandwidth
6OLGH/LPLWLQJ%DQGZLGWK
Instructors Note: )ProxySG allows you to control the maximum amount of bandwidth utilized
by streaming media using two techniques: Admission control and bandwidth management.
Even if you have not yet discussed the latter in the course (or you will not), simple mention that
in bandwidth management, the amount of bandwidth assigned to MMS is fixed but any user
can join the pool.
More users join the pool, less bandwidth each user has. Since MMS is very sensitive to time
delays, after a certain threshold of users, the stream will degrade to a point where users
cannot see or hear (or both) much Admission control limits both the maximum amount of
bandwidth used by the MMS protocols but also does not allow new users to join once the limit
is reached. Admission control is designed to limit the bandwidth consumed by MMS traffic,
without jeopardizing the performane for the already connected users. .
The ProxySG appliance is able to control the amount of bandwidth on both the server side and
client side. This should 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 will enable you to
reduce the amount of bandwidth used for streaming media, leaving it available for other, perhaps
more important, business uses.
Streaming media bandwidth limitations are achieved by configuring the ProxySG appliance 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 appliance, as well as for each streaming media player
(Windows Media, RealPlayer, 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.
After it has been configured, the ProxySG appliance limits streaming access to the specified
limitations. If a client tries to make a request after a limit has been reached, the client receives an
error message.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Note:
If a maximum bandwidth limitation has been specified for the ProxySG appliance, the
following behavior can occur. If a Real Media client, followed by a Windows Media
client, requests streams through the same ProxySG appliance and total bandwidth
exceeds the maximum allowance, the Real Media client enters the rebuffering state.
The Windows Media client continues to stream.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Caching
6OLGH&DFKLQJ
Instructors Note: This is a relatively simple slide. It points out two main concepts: 1.
ProxySG can partially cache VOD files 2. ProxySG cannot cache live streams (which would
make no sense by definition of live stream) Client A requests a fully cached VOD file; this file is
served from the proxy without any significant traffic exchanged with the streaming server.
Client B requests a partially cached VOD file; while the ProxySG serves the part of the file
available in cache, it retrieves, caches, and delivers to the client B the remaining part of the
file.
The ProxySG appliance 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 a live streams.
Once video-on-demand data has been cached on the ProxySG appliance, the clients no longer
have to connect to the OCS to access the data. The video is now stored on the ProxySG appliance
and bandwidth is saved on the server side, since there is no traffic. In the example above, Client A
is requesting streaming data that has been cached on the ProxySG appliance. Since the data was
cached, there is no need to connect to the OCS.
Additionally, the ProxySG appliance can have partially cached video-on-demand. In this instance,
the client will connect to the ProxySG appliance and begin streaming the data from there. Once the
client reached the point where partial data ends, the client will begin to receive data from the OCS;
the stream will continue 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 appliance. Note that Client
B only has to connect to the ProxySG appliance 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
since the ProxySG appliance cannot cache live data.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Cache Content Pre-population
6OLGH&DFKH&RQWHQW3UHSRSXODWLRQ
Instructors Note: Not all VOD is created equal. Some server will always stream the file to the
end user not allowing a download and then play. Others, like the ones served over HTTP,
allow the user to download the file and then play it. While ProxySG can be configured to
pre-populate the cache, the time it takes to download an object depends on how the server
delivers the object. It can be either download time or video play time. You can discuss here the
content commands:
# show content url {url}

to verify the status on an URL in the object store
#(config) content distribute {url}

to pre-fetch a URL and load it in the object store.
The ProxySG appliance can be pre-populated with streaming media content. This allows the
administrator to make the content immediately available. This can be done at anytime, but if done
during off-peak hours, the bandwidth can be reserved for regular business activities.
In the example above, the ProxySG appliance 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 appliances cache is equivalent to the time it would take
to download the file from the OCS. However, if the administrator is populating the ProxySG
appliance by streaming the video from a media server, the population time will be 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 will no longer need to connect to the OCS to retrieve videos that are
already on the ProxySG appliance.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Authentication
6OLGH$XWKHQWLFDWLRQ
Instructors Note: This is a relatively simple slide; do not spend too much time on it. Simply
re-iterate that the ProxySG is a very secure appliance and content which requires
authentication on the OCS, even if cached locally, is not served unless the user has
authenticated in the OCS. This is applicable to both fully and partially cached VOD files.
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 appliance can use its ability to cache streaming media content in conjunction with
authentication. As previously stated, the ProxySG appliance 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 appliance 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 appliance, the client will be 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 appliance. 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 will
be asked to authenticate before the streaming media content can be accessed. Authentication rules
can be applied to fully cached content and partially cached content.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Streaming Handoff
6OLGH6WUHDPLQJ+DQGRII
Instructors Note: This is an important slide as you cannot discuss the concept of protocol
hand-off enough times. ProxySG can process MMS traffic in three ways:
1. Native MMS
2. MMS over HTTP. Point out that is not native MMS over port 80 but MMS protocol wrapped
in proper HTTP protocol
3. MMS over SOCKS. Point out that is not native MMS over port 1080 but MMS protocol
wrapped in proper SOCKS protocol ProxySG has three specific protocol workers to handle
MMS, HTTP, and SOCKS.
The MMS worker has specific features and functionalities to manage the streaming traffic as
you have discussed so far. When you have hand-off enabled, the MMS traffic over HTTP or
over SOCKS is first processed by either the HTTP or SOCKS worker, unwrapped, and then
presented to the MMS worker who apply the full set of features. Protocol hand-off requires a
valid MMS license (available free of charge)
Important: The slide should read SOCKS worker over the SOCKS service and NOT HTTP
worker.
Streaming handoff is a process that allows the ProxySG appliance to appropriately MMS traffic, no
matter what protocol the content is being delivered by. For example, in the slide above, there is
streaming media traffic coming over port 1755, the native MMS protocol, therefore no handoff is
required.
However, in common deployments, port 80 is the only port allowing traffic through the firewall.
Unfortunately, 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 give 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 HTTP protocol.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Managing Streaming Media Lab

Overview
In this lab, you configure ProxySG appliance to intercept streaming media traffic. You will cap the
maximum gateway bandwidth for the streaming media traffic and then verify the configuration
from the Statistics tab.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 18:Forwarding
Instructors Note: This chapter describes what forwarding is, how it can be used to achieve
practical benefits, and how students can create viable forwarding directives. In particular, you
need to discuss how to use forwarding for proxy chaining and for reverse proxy.
The key concept in forwarding is that the ProxySG simply changes the destination IP address
in the request it receives.
The main use of forwarding should be proxy chaining; you should suggest using two-way URL
(TWURL) rewrite when implementing reverse proxy. Introduce the idea that TWURL rewrite is
more robust as it modifies all parameters of the transaction and not just the destination IP
address.
Discuss the load balancing options available for forwarding in detail. In particular, host-affinity,
as it may be necessary to use this feature in certain circumstances (try to have some customer
examples ready.)
Toward the end of the chapter you should ask your students at which checkpoint (CI, SO, SI,
CO) do you think forwarding rules are processed?. The correct answer is SO; the ProxySG
needs to know the IP address it has to contact before it connects to the OCS
Forwarding is the ability to send Web requests to other appliances before sending the request to an
origin 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,
including additional Blue Coat SG appliances. The combination of forwarding and the
ProxySG policy engine allows extremely flexible configuration and traffic management.
Forwarding can be summarized as follows: It is a method for sending requests (for the 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 some load-balancing options. You can also
determine how the ProxySG should act in case the upstream host is unavailable. When you create
a forwarding rule, the ProxySG automatically configures health checks to the upstream host; if the
host fails the health check, the ProxySG drops the request and returns an error to the user. This
behavior is called fail closed and it is the default behavior.
You can modify the default behavior to send the request to the original OCS, ignoring the
forwarding rule. This behavior is called fail open. For instance, 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 the London location
has Internet access) when the Amsterdam ProxySG in 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 the IP addresses of the group are gathered together and the group's
method is applied across the entire set of IP addresses. When a hash is used, you can apply the
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 will go 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. Take, for
example, 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 users state is lost.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 18: Forwarding
Forwarding Proxy Chaining
6OLGH7\SLFDOIRUZDUGLQJVFHQDULR
Instructors Note: This slide is important because it illustrates the basic concepts of
forwarding. You should emphasize the reasons why forwarding is used because this is not
clear from looking at the slide. Be prepared to describe a typical deployment and why it is
configured the way it is.
Forwarding is sending traffic to a destination other than that specified by DNS resolution. Traffic
is sent upstream to another proxy, as shown in Slide 18-1. Forwarding is often used in proxy
hierarchies in which lower-level proxies must use another proxy for Internet access. Forwarding
can also be used for load-balancing, caching optimization, or redundancy.
Slide 18-1 illustrates a typical forwarding scenario, in which a local ProxySG receives a request
and forwards it to a second ProxySG for content retrieval (or authentication, etc.). 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 origin server
because of the likelihood that the requested content resides in one of the upstream caches.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Forwarding Reverse Proxy
6OLGH%DVLFUHYHUVHSUR[\
Instructors Note: This slide shows a very basic reverse-proxy deployment. You should have
already mentioned to your students that this is a very basic reverse proxy deployment, as
TWURL may be necessary in many situations. Nonetheless, this is a good example that
shows how to use forwarding.
Ask why a split DNS is not an option and discuss the answers (think of when there is not host
header in the clients request)
In the deployment shown in Slide 18-2, the ProxySG receives all requests for a specific Web server.
It is common to deploy ProxySG in front of the server to protect your production Web server and
increase 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. Forwarding is, in general, a
better solution.
Alternatively, you can use forwarding to send a request, destined for a specific host, to another
host. For example, if your organization has a domain name that is similar to other domain names,
you can forward those requests to the proper domain. The domain www.bluecoat.com is owned
by Blue Coat Systems, for example, but the domain www.bluecoat.nl is not.
To make sure that users see your content, you can create forwarding rules to forward all requests
for www.bluecoat.nl to www.bluecoat.com. In fact, you will do exactly that in the accompanying
lab.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Forwarding Host Types
6OLGH)RUZDUGLQJKRVWUHTXHVWW\SHV
Instructors Note: Because you have already covered this concept when you discussed
explicit proxying, students should already understand why the host type is important. Even so,
you should not skip this slide.
The request style determines the format of the HTTP request 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, the proxy-style request must used. The 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Forwarding Options
6OLGH)RUZDUGLQJKRVWGHILQLWLRQ
Instructors Note: This slide is important because the analogy enables students to easily
grasp the required components for a forwarding host definition. You should also make sure
that students understand what directives are and how they are used to create forwarding
configurations.
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 re-resolved periodically. The DNS re-resolve is needed because the 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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, along
with their default ports are selected. This directive is only available for proxy hosts.
You can also 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. As you will see
in the next slide, 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[=yes|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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Forwarding Host Options

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
Instructors Note: While you do not need to spend a lot of time on this slide, you should
ensure that students understand the various types of load-balancing and how they are used.
Host affinity can be confusing so it is helpful to be ready with an example.
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 host's
load-balancing method (round-robin, least connections, or none) is applied to those IP
addresses.
For groups, two load balancing choices are available:
Q Apply a load-balancing method to a group. All the IP addresses of all group members are
gathered together, and the group's method is applied across that entire set of IP addresses.
Q 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! will always go to one
host and the Google search engine will always go 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Forwarding Health Checks
6OLGH)RUZDUGLQJKHDOWKFKHFNSURSHUWLHV
Instructors Note: Many students are probably already familiar with health checks (or
heartbeats as they are sometimes called). After ensuring that students understand what a
health check is, discuss the specifics of the Blue Coat implementation. Its important to note
that administrators do not have to configure health checks; they are automatically created.
The ProxySG can perform health checks on a forwarding host or external server that is providing a
service. The supported server types are HTTP, HTTPS, ICAP, Websense (off-box), SOCKS
gateways, and Layer 3 and Layer 4 forwarding hosts.
Based on the health check type, the ProxySG periodically verifies the health status, and thus the
availability, of the host. When the ProxySG performs a health check on one or more hosts, it
determines whether the host is up and available to fill a content request. A positive health check
indicates a functional end-to-end connection and that the host is healthy and able to return a
response. The time interval between checks is configurable.
If the initial health check is unsuccessful, the ProxySG retries, using the number of attempts set in
the health check failure count.
When there are multiple forwarding hosts, health checks are vital to ProxySG efficiency. The
ProxySG forwards requests to healthy hosts and not to unavailable hosts, resulting in faster
content fill requests. With a single forwarding host, health checking is also important to determine
whether the host is available.
Note:
When a forwarding host or SOCKS gateway is created, it is automatically registered

for health checks. Similarly, when a forwarding host or SOCKS gateway is deleted, it
is removed from the health check registry.
Instructors Note: Discuss the differences between the health-check actions and why you
might want to configure one type over another.
When configuring the forwarding health check, you can select from the following types of checks:
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
HTTP
HTTPS
Layer 3 (ICMP)
Layer 4 (TCP connection)
You can view a list of health check statistics by accessing the following URL:
https://<ProxySG_IP:8082/HC/Statistics>
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Creating a Forwarding Rule Lab

Overview
The site www.bluecoat.nl is a registered Web site but is not the property of Blue Coat Systems1. You
want to create a policy to show the actual content of www.google.com when users attempt to
access www.bluecoat.nl.
You can achieve this goal by creating either a forwarding rule or a redirect rule. This lab shows
both solutions.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
1. This information is correct and accurate at the time this lab is written.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 19: Reverse Proxy Implementation
Instructors Note: This chapter builds upon the reverse proxy concepts that students learned
previously. You should review the benefits of a reverse proxy and then provide students with
the configuration best practices outlined in the following pages. While the information is not
technically challenging, it is important that your students gain an understanding of the
information.
As you learned earlier, 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 the back-end
Web servers.
Reverse proxying with the Blue Coat SG provides the following advantages:
The ProxySG terminates the session with the client (even for SSL connections) and establishes
another session with the Web server, thereby 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 DOS (Denial of Service), protecting the Web servers from these types
of attacks.
The server identity can be hidden by the ProxySG.
Increased performance with caching provides an improved Web experience.
The ProxySGs flexible advanced-forwarding architecture, 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, see the TWURL
chapter in this book.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Reverse Proxy Deployments
6OLGH7\SHVRIUHYHUVHSUR[\GHSOR\PHQWV
Instructors Note: This slide shows the two basic ways that a reverse proxy can be deployed.
You can have the clients connect directly to the ProxySG or you can place the proxy in the
DMZ. You should also discuss the option in which the traffic in the DMZ is routed to the
ProxySG using a Layer 4 switch. The client can resolve the host name of the server to three
possible IP address: the external IP address of the proxy (bottom diagram), the external IP
address of the firewall mapped to the IP address of the proxy in the DMZ (top diagram), or the
external IP address of the firewall mapped to the IP address of the Web server (top diagram,
where the Layer 2 switch is substituted with a Layer 4 switch).
You can place your ProxySG, for reverse proxy, in several places on the network. One option is not
necessarily better than the other: You need to evaluate which solution makes you most
comfortable and achieves the best balance between performance and security.
The top diagram in the slide 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 your Web server resolves to an
IP address, which the firewall then maps to the actual IP address of your 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 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 your
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Forwarding for Reverse Proxy
Allow the proxy to services requests for

front-ended Web servers
Forwarding hosts must be defined as server

style
Protocol support must be specific (defaultschemes not allowed)
Protocol conversions (HTTPS<-->HTTP) are

automatic
6OLGH5HYHUVHSUR[\FRQVLGHUDWLRQV
Instructors Note: Spend some time explaining each of the points in the slide. It is important
that students understand why these configurations are recommended.
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 companies
choose to implement a device-oriented redirection scheme.
To relay requests from the proxy to the correct Web server, you must 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
6OLGH)RUZDUGLQJUXOHVDQGH[SOLFLWUHYHUVHSUR[\LQJ
Instructors Note: This slide illustrates the typical explicit reverse proxy request flow. The
important concept here is that all requests contain the proxy IP address. Therefore, the proxy
must have a way to determine where to forward the request. This is where forwarding rules
come in.
Slide 19-3 shows a client requesting content from an explicit 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
6OLGH7UDIILFIORZDQGEDQGZLGWKPDQDJHPHQW
Instructors Note: This slide illustrates the typical SSL reverse proxy request flow. Stress the
benefits of performing SSL only between the client and the proxy. Because the server
communicates only with the proxy, the proxy uses standard HTTP.
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, the ProxySG appliances offload the origin
server from the delivery of secure objects and the managing and processing of SSL sessions.
Slide 19-4 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 5080 percent. This allows a Web site to serve more content and process more transactions
through the existing server infrastructure. The ProxySG appliances can negotiate 1040 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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
Instructors Note: This slide is very important. Do not skip it. If students incorrectly configure
their proxies, they might deploy open proxies. Stress the dangers of open proxies and
describe the configuration recommendations for blocking access to all but trusted clients and
hosts.
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 will
connect 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).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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[\
Instructors Note: This slide presents final configuration recommendations for deploying a
reverse proxy. You might want to spend some time elaborating on the portal proxy profile so
that students are not concerned that they are violating standard HTTP behavior.
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, HTTP proxy does a conditional GET to the OCS, 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 hereby 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 (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, HTTP proxy ignores the
following Cache-Control: conditions from the client request:
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Q
Q
Q
Q
Q
"max-stale" [ "=" delta-seconds ]

"max-age" "=" delta-seconds
"min-fresh" "=" delta-seconds

"must-revalidate"
"proxy-revalidate"
Substitute GET for IE (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,
HTTP proxy treats it as a PNC header if it is a type-N object. You can control this behavior of
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.1 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.
1. Type-T: The OCS specifies explicit expiration time.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Reverse Proxy HTTPS to HTTP Proxy Lab

Overview
You need to configure your ProxySG appliance to be the resolved host for
https://www.bluecoat.com. ProxySG appliance will handle the SSL connection with the clients
and connect to the back-end Web server over HTTP.

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 20: Two-Way URL Rewrite
Instructors Note: In this chapter, you will need to use examples to clearly explain how
TWURL functions. Make sure that the students understand that TWURL is not required. (You
should have done a lab already where reverse proxy worked properly without the TWURL.) If
you can guarantee that the Web site is well-designed in every section, TWURL is not
necessary. You should strongly advise your students to use TWURL anytime they implement a
reverse proxy solution.
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 SG 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.
In the slides that follow, you can see 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.
In one slide, you can 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. In the following slide you 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 a priori. However, you should always use it, unless you are absolutely
confident 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Two-Way URL Rewrite The Problem

Forwarding rules change the destination IP
Links are not modified
Headers are not modified
Badly designed Web sites may 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/
Instructors Note: This slide prepares the foundation for why you need to implement TWURL.
It basically explains visually what appears in the introduction to the chapter in the student
section.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Two-Way URL Rewrite The Solution
The Blue Coat SG receives a request from a client

for a Web page that is inside a server portal
It rewrites the requested URL from client form to server
form
It sends the rewritten request to the server
When the server sends back a response
The Blue Coat SG rewrites URLs inside the response

from server form back to client form
6OLGH7:85/WKHVROXWLRQ
Instructors Note: This is again an introductory slide on how to fix the issues concerning
poorly written HTML code or inconsistent URL references in the content served.
The idea behind TWURL is accuracy and consistency of the content served to the client. In the
small figure below, you can see an example of how TWURL 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 both 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.
Figure 20-1: How TWURL fixes poor HTML code
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Two-Way URL Rewrite TWURL
Need to change the host header and the possible links
6OLGH+HDGHUVPRGLILFDWLRQ
Instructors Note: Slide 20-3 and Slide 20-4 graphically illustrate the problem, which TWURL
solves. Slide 20-3 shows a pretty unrealistic situation; however, it is a first look into the issue.
Start explaining how virtual hosts work (from the standpoint of the Web server), because it
may help the student understand Slide 20-4, which follows.
In this example the ProxySG is configured to forward the requests for www.test.com to the site
www.example.com. There is no TWURL configured on the ProxySG.
You can see from the slide that the HOST header in the client request refers to www.test.com;
because there is not a TWURL 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 the Web requests and deliver the correct
content.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
6OLGH7:85/ZLWKYLUWXDOKRVWV
Instructors Note: Slide 20-4 shows a more realistic situation than the one in Slide 20-3. The
host www.siteB.com resolves to the external IP address of the ProxySG; then the forwarding
rule sends the request to the internal site, whose hostname is actually internalsiteB. Point out
clearly that the default Web site associated to the IP address 172.16.90.100 is internalsiteA.
You also need to remind the students that when a Web server receives a request for a site that
does not exist, it should serve the default Web site. In this case, even if the client requests
www.siteB.com, it will receive the content from the internalsiteA, which is not what it wanted.
Additional Note: Ask the students which content the client will receive in a situation like this
(no TWURL).
The situation shown in Slide 20-4 is more realistic than the situation in Slide 20-3. A client wants to
retrieve content from www.siteB.com; this site is actually front-ended by a ProxySG. The proxy
does not have any TWURL 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 being 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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/
Instructors Note: Slide 20-5 shows the content received by a client that is connecting to the
site through a reverse proxy without any TWURL policy. Point out that to the user agent, the
source appears to be www.bluecoat.nl (look in the top portion of the window); however, the
links refer to www.bluecoat.com.
In Slide 20-5 you can clearly see what happens when you apply a forwarding rule to the incoming
requests without adding a TWURL policy. Of course, you need to use TWURL 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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/
Instructors Note: Slide 20-6 shows the content received by a client that is connecting to the
site through a reverse proxy with TWURL policy. Point out that to the user agent, the source
appears to be www.bluecoat.nl (look in the top portion of the window); consistent with the GET
request, the links refer to www.bluecoat.nl.
In Slide 20-6 you can clearly see what happens when you apply a forwarding rule to the incoming
requests when you have a TWURL policy. Of course, you need to use TWURL 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
TWURL Syntax
CPL Syntax:
<proxy>
action.action_name(yes)
define action action_name

transform transformer_id
end
define url_rewrite transformer_id

[caseless]
rewrite_url_substring "client_url_substring" "server_url_substring"
rewrite_url_prefix "client_url_substring" "server_url_substring"
end
6OLGH7:85/&3/V\QWD[
Instructors Note: Describe the syntax very quickly. You can return to this slide after you are
done with the CPL chapter. Spend no more than five minutes detailing the sequence of
commands.
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 can also rewrite
arbitrary JavaScript. This transformer takes effect only if it is also invoked by a transform action in
a define action definition block, and that block is in turn called from an action( ) property.
For each URL found within an HTTP response, a url_rewrite transformer 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 such 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 transformer. The
invoked transformer takes effect only if the transform action is used in a define action definition
block, and that block is in turn enabled by an action( ) property.
Note:
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
TWURL and Policy Checkpoints
6OLGH7:85/DQGFKHFNSRLQWV
Instructors Note: This slide shows where ProxySG executes each specific statement
needed to implement TWURL. You need to discuss how it is possible to determine the
checkpoints, even without inside knowledge:
- The rewrite of the request must happen before SO (when the client connects) but also before
possible cache hits to avoid serving the cached content for the original URL and not the
rewritten one; therefore rewrite URL prefix happens at CI
- The rewrite of the response must happen after SI but also after possible caching hits,
therefore can only happen at CO.
Important: ProxySG handle the execution of the required actions at the correct checkpoint
without any user intervention. Make it clear to the students that they do not have to worry
about ensure proper execution of action at specific checkpoints.
Slide 20-8 shows the code necessary to create, using TWURL, a rule that allows the clients to
request the site www.bluecoat.nl while actually receving the content from the site
www.bluecoat.com.
The diagram shows the code necessary to implement TWURL next to the checkpoint where
ProxySG exectutes the requested actions. As mentioned before there are several more checkpoint
than the one discussed in this course; the actions necessary to implement TWURL are executed on
the specified checkpoint or on checkpoint close enough to the one discussed in the slide.
You can clearly see from the slide and from the syntaxt on Slide 20-7, there are two sections in the
code: One performs the headers and content modification, the other the actual modification of the
request, so that ProxySG connects to the rewritten URL and not to the one originally requested by
the client.
Often the syntax of TWURL is confusing because you have one action which has a component that
is applied to a request and one to the response. You need to keep in mind that request and
response are two components of the same transaction, so the action is applied to the entire
transaction.
The complete code is shown below.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
<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
Heres how this policy works:
1.
The <Proxy> layer performs two-way url rewrite on the request if the request matches a
client url for the server portal. If ProxySG receives an HTTP request for the host
www.bluecoat.nl then it executes the action portal. This action has to components:
rewrite action which effectively instructs ProxySG to fecth a different URL than the
one requested
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 definition, 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 can also
rewrite arbitrary JavaScript. This transformer takes effect only if it is also invoked by a
transform action in a define action definition block, and that block is in turn called from an
action( )property.
Important: You do not need to have a forwarding rule if you implement the TWURL with
the CPL code shown above.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Two Way URL Rewrite Lab

Overview
A server portal provides controlled access to a Web server or collection of Web servers. When a
ProxySG appliance is configured as a server portal, it performs two-way URL rewrite between a
set of external client URLs and a set of internal server URLs.
When the ProxySG appliance receives a request from an external client for an internal Web page, it
rewrites the requested URL, changing it from client form to server form, and then sends the
rewritten request to the internal server. When the server returns a response, the ProxySG
appliance rewrites the URL, changing it from server form back into client form.
In this lab, you configure the ProxySG appliance to perform TWURL for a pair of URLs that have
similar appearance by writing a new policy. You also edit the host file on your PC to act as an
external client so you can test the new policy

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build

Software
Version
F FireFox
F version 2.0.0.5
F Internet Explorer
F SGOS
F 5.2.1.3; build 30166
F Windows XP
F SP2 build
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 21:Failover
Instructors Note: The Blue Coat SG allows you to create failover scenarios in a variety
of ways. In this chapter, describe both basic and advanced configurations. If you have any
specific implementation examples, discuss them here. Even if the slides do not cover the
topic, spend some time reminding the students that load-balancing using PAC files, DNS
round robin, WCCP, or Layer 4 switches represents the most effective solution. By definition,
failover implies a solution where not all of the devices are active at the same time. You can,
however, create a combination of load-balancing and failover, using the information discussed
in Slide 21-3.
When implementing failover, or even load balancing, remember that ProxySG appliances do
not automatically share policies. You must either manually configure the devices that
participate in the failover to have the same policies or use Blue Coat Director. Alternatively,
you might discuss how to transfer policy files across multiple devices; however, there are
several risks involved, as you might not properly transfer all of the required information.
Using failover, ProxySG offers the capability to implement a redundant configuration. Failover
allows a second ProxySG appliance to take over if a first appliance fails, providing redundancy to
the network through a master/backup relationship. In normal operations, the master (the machine
whose IP address matches the group name) owns the address. The master sends keepalive
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 Blue Coat 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, Blue Coat migrates these IP
addresses among a group of machines. The Blue Coat failover solution, 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 called 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 the Virtual Router Redundancy Protocol (VRRP).
You can also create failover configuration, when the ProxySG are deployed in bridging mode.
There are two options available to you to create failover in bridging mode:
Parallel Failover
Two or more ProxySG are placed between two Layer 2 switches, with one interface attached to
each of the switches.
Serial Failover
Two or more ProxySG 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 21: Failover
Failover Basics and Configuration

Blue Coat SG provides failover similar to
Nokias VRRP
Two or more proxies are configured with a

virtual IP address
The master unit makes periodic multicast

announcements
If two announcements are missed, the standby
assumes the shared virtual IP
6OLGH)DLORYHUIXQGDPHQWDOV
Instructors Note: Spend some time talking about VIPs. More information is provided later in
the chapter but it is important that students understand that concept of VIP so they can
understand how failover works. Once students understand how failover works, you can
explain configuration. When you discuss failover configuration options, you can use them to
reinforce failover concepts that you have previously covered. Inform students that lengthening
the advertisement interval results in slower takeover. That is, while you can decrease the
number of packets sent across the network by lengthening the advertisement time, you also
lengthen the time it takes for the backup to take over when the master has failed.
The Blue Coat 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 backups.
A virtual router identifier (VRID) is not used.
Virtual MAC addresses are not used.
MD5 is used for authentication at the application level.
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 the ARPs. The master sends keepalive 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 of 224.xxx.xxx.xxx. 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.
Relative Priority: Weight of that system in failover group. Relative Priority refers to a range from
1-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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Basic Configuration
6OLGH%DVLFIDLORYHUGHSOR\PHQW
Instructors Note: Use this slide to go over the concepts you talked about on the previous
page. Make sure that students understand that this is an explicit proxy deployment with a
Layer 2 switch. All requests are sent to the shared VIP. You can implement failover for
transparent deployments as well. Discuss the fact that the policies are not automatically
synchronized. You need to make sure that the policies are the same on each proxy. Mention
Director.
Slide 21-2 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 as explicit proxies.
The master ProxySG receives the client requests and periodically sends multicast keepalive
messages to the network. In essence, the master ProxySG answers to all ARP requests to the VIP.
The backup unit, is connected to the network but does answer to any ARP requests. While the
master is active, you can access the backup unit only through the backup IP address directly.
As mentioned before, the master sends out a multicast periodically (you might have issues with
certain switchesthis creates an environment where both units are trying to be the master). If the
master does not send two consecutive multicast keepalive announcements, the backup takes over
for the master and services client requests. When the backup takes over, it starts replying to the
ARP requests for the VIP. Additionally the backup sends gratuitous ARP messages, which notify
that the IP has now moved over to this device.
Whenever you configure VIP, you must have all of the ProxySG running the same exact set of
policies. Because a different proxy can start handling the traffic at anytime, 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 the ProxySG in the failover group, or you can use 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 have them share a third VIP for failover.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Advanced Configuration
6OLGH$GYDQFHGIDLORYHU
Instructors Note: The standard failover configuration does not allow you to maximize the
fact that you have two or more ProxySG. This slide shows a pretty common implementation
where you can have both failover and load-balancing. Each ProxySG acts both as a master
and as a backup. You should combine DNS round-robin and this failover configuration to
create an environment combining load balancing with high availability.
The basic failover configuration discussed in the previous slide, 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. The basic idea is pretty simple:
Define two separate VIP
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 hostname of the ProxySG to each of the VIP
alternatively (DNS round-robin)
The same caveats discussed for the simple failover configuration, continue to be true for this more
advanced configuration. In particular you need to make sure that the proxies involved in the
failover have the exact same policies running. If the policies are not absolutely identical, the users
will experience inconsistent behaviors when accessing the Internet.
You can scale this configuration to any number of ProxySG; you need to have has many VIP as
you have ProxySG; you also need to set the priority in which they take over each other.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Parallel Bridging
6OLGH3DUDOOHOEULGJLQJ
Instructors Note: Parallel bridging is an interesting solution that combines failover with easy
transparent proxy deployment. There are few issues that you need to point out to the students
about this solution:
You are not taking full advantage of having two ProxySG in your network.
Requires loop-detection, which is available only in SGOS 5.1.x or higher.
Requires software bridging.
The ProxySG provides bridging functionality by two methods:
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.
Bridging supports the Spanning Tree Protocol (STP). STP is 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, when faced
with multiple paths, 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 spanning tree
participation for the interface.
In parallel failover mode, two ProxySG systems are deployed side by side on redundant paths. In
parallel failover, the back-up does not actively bridge any packets unless the master fails. If the
master fails, the back-up takes over the master IP address and begins bridging.
Blue Coat recommends that you enable loop-detection (STP) if you have parallel bridging enabled.
Failure to do so may have unpredictable results on the stability of your network infrastructure.
Note:
Parallel bridging can be implemented only by using hardware bridging. Software

bridging cannot be used.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Note:
Bridge interfaces cannot be used in WCCP configurations. If the configuration

includes bridge interfaces, you will receive the following error if you attempt to load
the WCCP configuration file:
Interface 0:0 is member of a bridge
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Serial Bridging
6OLGH6HULDOEULGJLQJ
Instructors Note: The same notes discussed before apply to serial bridging failover;
however loop-detection, and consequently SGOS 5.1.x, is not required. Point out again that
this is still an active-passive configuration where you can only use one ProxySG at the time.
There is not load-balancing available in this configuration. You should discourage it.
In serial failover mode, the backup proxy is inline and continuously bridges packets, but 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, etc. A serial configuration is shown in
the slide above.
In this scenario loop-detection is not necessary. But you still loose 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, as yields limited gains to the overall
infrastructure.
Note:
Serial bridging can be implemented only by using hardware bridging. Software

bridging cannot be used.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Implementing Failover Lab

Overview
Students will work in pairs to simulate failover from the master to the slave of the failover group.
Equipment
Role
IP Address
Students SG with Odd

IP Address
Master
172.16.90.21,
172.16.90.23,
172.16.90.25,
172.16.90.27,
172.16.90.29
Students SG with Even

IP Address
Backup
172.16.90.22,
172.16.90.24,
172.16.90.26,
172.16.90.28,
172.16.90.30

Software/Hardware
Version/Model
Firefox
Version 2.0.0.5
Internet Explorer
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build

Software/Hardware
Version/Model
Firefox
Version 2.0.0.5
Internet Explorer
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build
Desired Results
A continuous ping to the VIP will time out before resuming when simulating failover of master to
slave in a failover group.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 22:Access Logging Advanced Topics
Instructors Note: This chapter focuses on two important advanced topics in access logging:
log formats and security. This page and the next offer a brief review of access logging before
beginning new material. It is important to review the SSL protocol and the concepts behind
digital certificates and PKI before teaching this section.
This chapter is divided in two main sections. The beginning of the chapter describes in details log
types and log formats. You should spend enough time on these two concepts to make sure the
students understand the difference. The most important log type is the one called main, as it is
used for HTTP and other protocols. For better performances with Blue Coat Reporter, main should
always use the bcreportermain_v1 log format.
Remind the students how to read the variables used to define the log format by drawing the
following diagram:
Client (C) ----> Proxy Server (S) ----> Remote Server (R)
Use as example the following variables:
- CS-category: the categorization for the client request URL to the proxy
- RS(content-type): the file type sent from the OCS (remote server) to the proxy
Important: Discuss how the proxy may indeed modify many of the values when processing data
from the client to the proxy (CS) and then sending it to the remote server (SR) and vice versa.
The second part of the chapter discusses two seldom used features of the access log, which
nonetheless are very important for security conscious customers. ProxySG allows you to sign and
encrypt log files using PKI.
To sign access log you can create a self-signed certificate using the ProxySG; however for
encrypting the access logs you need to have a way of creating the private and public keys pair
outside the proxy. You can use a variety of software suites; if you decide to do the lab, you should
briefly discuss OpenSSL.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Understanding Access Logs

Defining Access Log
Selecting log types and log formats
Understanding access log fields

Detailed transaction information
Custom Access logs
Troubleshooting using access log

Useful links
Access logging filters
6OLGH8QGHUVWDQGLQJ$FFHVV/RJV
Instructors Note: Use the slide to cover what you discuss in the first part of the chapter.
Particularly prepare the students how to use Access logging feature for advanced
troubleshooting. You may show the Access logging tail short cut for the main access log at:
https://{proxysg IP}:8082/Accesslog/tail/main
Blue Coat Systems has a number of resources to provide diagnostic information.The most widely
used ones are logs. Different types of logs are available on the ProxySG:
Access logs: Access logging allows you to track Web usage for the entire network or specific
information on user or department usage patterns. These logs and reports can be made
available in real-time or on a scheduled basis. Access logs record client requests to the
ProxySG. Reports can be made of these logs and their information analyzed.
Event logs: Contain information of activity on the ProxySG. Used to view administrators
actions and the status of the machine.You can configure the ProxySG to log system events as
they occur. Event logging allows you to specify the types of system events logged, the size of
the event log, and to configure Syslog monitoring. The ProxySG can also notify you by e-mail
if an event is logged.
Policy trace logs: A policy trace can provide debugging information on policy transactions. This
is helpful, even when policy is not the issue. A policy trace log records policy-related events in
each layer.
By using these three types of logs, you can gain a detailed view of what occurs on a ProxySG. To
create access logs, you can choose an existing format or create a custom format. Pre-defined
formats are include NCSA, Squid, SurfControl, Websense, and W3C ELFF (default). You can
create other formats using custom or ELFF format strings. A log facility is a separate log that
supports a single log format. You associate a protocol with the log facility and add configurable
information to it, such as an upload schedule. Four log facilities are available: im, main, p2p, and
streaming. For instance, you can assign HTTP and HTTPS to the main log facility using the W3C
ELFF format. When you enable access logging, by default you enable logging for all protocols
unless you see the word none next to a protocol in the Management Console. This means no log
format is associated with that protocol.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 22: Access Logging Advanced Topics
By configuring an upload client, you can transfer access logs from the ProxySG to the repository
from where you will run reports. The ProxySG supports four types of upload clients: FTP client
(default), HTTP client, custom client, and Websense client. The appliance also supports secure FTP
and HTTPS. The upload schedule allows you to configure the frequency of access logging upload
to a remote server.
You can also create a logging policy that will help you manage the access logs you set up. You can
create policy either through the Visual Policy Manager (VPM) or by using Content Policy
Language (CPL). You can use the Reporter tool to analyze your log files.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Log Types and Formats

Main
Used by default by HTTP Proxy

Uses bcreportermain_v1 format; supports PVC
CIFS
Used by default by CIFS proxy

Uses bcreportercifs_v1 format
SSL
Used by default by SSL and HTTPS forward proxies

Uses bcreporterssl_v1 format
6OLGH/RJW\SHVDQGIRUPDWV
Instructors Note: . The slide shows the three most commonly used log types and the best
log format you should associate to these log types when using Blue Coat Reporter, in order to
obtain maximum performances. Read the first few variables used to create the three log
formats; it is important that the students learn how to decipher the meaning of each log entry.
Mention that if you are using SmartFilter, SurfControl, or Websense, you may want to use their
reporting tools as well. If you use reporting tools other than Blue Coat Reporter, you need to
use the specific log format for that vendor.
Content is logged under its own special format in access logs. A majority of content is HTTP
content and uses the Main log type. Blue Coat has its propreitary format for such content and the
ProxySG uses the bcreportermain_v1 format to log this content. Similarly, CIFS content, which
comprises mostly intranet access uses the bcreportercifs_v1 format, and secure content like
SSL and HTTPS uses the bcreporterssl_v1 format. The fields that are under every format are
described below:
bcreportermain_v1 format:
date time time-taken c-ip cs-username cs-auth-group x-exception-id scfilter-result cs-categories cs(Referer) sc-status s-action cs-method
rs(Content-Type) cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uriquery cs-uri-extension cs(User-Agent) s-ip sc-bytes cs-bytes x-virus- id
bcreportercifs_v1 format:
date time c-ip c-port r-ip r-port x-cifs-uid x-cifs-tid x-cifs-fid xcifs-method x-cifs-server x-cifs-share x-cifs-path x-cifs-orig-path xcifs-client-bytes-read x-cifs-server-bytes-read x-cifs-bytes-written
x-client-connection-bytes x-server-connection-bytes x-server-adnconnection-bytes x-cifs-client-read-operations x-cifs-client-writeoperations x-cifs-client-other-operations x-cifs-server-operations saction x-cifs-error-code cs-username cs-auth-group s-ip
bcreporterssl_v1 format:
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
date time time-taken c-ip cs-username cs-auth-group x-exception-id scfilter-result cs-categories sc-status s-action cs-method rs(ContentType) cs-uri-scheme cs-host cs-uri-port cs-uri-extension cs(User- Agent)
s-ip sc-bytes cs-bytes x-virus-id x-rs-certificate-observed- errors
x-rs-connection-negotiated-cipher-strength x-rs-certificate- hostname
x-rs-certificate-hostname-category
The bcreportermain_v1 format also supports the Page View Combiner (PVC). This feature
combines multiple HTTP requests that are associated with a single Web page into a single log line.
When a user browses to a Web page, that page often sends out request for more content either
from the same server or from different servers. Rather than regarding each of these requests as
separate requests, the PVC combines all of these related page requests into one. This reduces the
number of database entries from the original log file and improves report generation performance.
A log format simply indicates the type of log being used. The ProxySG supports several different
existing, or pre-defined formats:
ELFF (W3C Extended Log File Format):
ELFF is a log format defined by the W3C that contains information about Windows Media and
RealProxy logs and is general enough to be used with any protocol. The W3C Extended Log
File Format (ELFF) is a subset of the Blue Coat Systems format. Each field is described using a
text string. When using an ELFF or custom format, a blank field is represented by a dash
character. Unlike the Blue Coat custom format, ELFF does not support character strings and
require a space between fields.
NCSA common log format:
The NCSA common log format contains one line for each request and contains only basic
HTTP access information. This format cannot be modified. The format of each log entry is
shown below:
remotehost rfc931 authuser [date] request status bytes
SQUID-compatible format:
The SQUID-compatible format contains one line for each request and is a log type designed
for cache statistics. This format cannot be modified. For SQUID-1.1,the format is:
time elapsed remotehost code/status bytes method URL rfc931

peerstatus/peerhost type
SmartReporter, an ELFF log format compatible with the SmartFilter Reporter tool.
SurfControl, a log format compatible with the SurfControl Reporter tool.The SurfControl log
format includes fully-qualified usernames when an NTLM realm provides authentication. The
simple name is used for all other realm types.
Websense, a log format compatible with the Websense Reporter tool.
bcreportermain_v1: This is a reserved format that cannot be edited.
bcreporterssl_v1: This is a reserved format that cannot be edited. It only contains fields that
do not reveal private or sensitive information, unlike the bcreportermain_v1 format. In
addition, a number of other ELFF-type log formats are also pre-defined: im, main, p2p,
streaming. It also is possible to create newELFF and custom log formats.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Sample Log
1. Log file header
Valid log files must have an header
2. Log entry
First entry separated from header by empty line
6OLGH6DPSOHORJ
Instructors Note: The slide discusses some key points about the structure of an access log.
The file shown in the slide is a main access log using bcrepotermain_v1 format. You need to
point out few important elements: 1) the header must exists in all log files. If the header is
missing, the Blue Coat Reporter does not process the file and the data it contains. You may fix
a log file by manually copying and pasting the headers from a properly formatted log file. 2) An
empty line separates the header and the data. 3) Point out that the #Remark header contains
the serial number and the IP address of the proxy, which created it; this is important
information when you are troubleshooting a multi-proxy environment.
Question: What is the IP address of the client making the request? What is the requested
URL?
Answer: Client IP is 156.160.20.11; URL is http://www.ig.com.br
Question: Is the content coming from the proxy cache? (difficult question)
Answer: Yes. The sc-status is 304, which is the response to a GET IF-MODIFIED-SINCE
(GIMS) when the content did not change. Additionally you can see that the s-action is
TCP_HIT (discussed in more details on Slide 22-7).
This slide presents a sample log as seen in an access log file. Every log file should have a header.
The header lists information regarding the version of the ProxySG, the date and time of the log,
and the fields that are present in the access log.
The header is followed by the log entries that are separated from the header by an empty line. Log
entries contain detailed information about the date, time, and the content that was accessed by a
client. These log entries make up the final log file that can then be digitally signed, encrypted and
uploaded onto the management console.
You can manually recreate the header if you have log files which would otherwise be valid.
Header-less files may appear when you switch log formats without interrupting access logging
first.
Important: It is important for log files to have valid headers. Blue Coat Reporter does not
process log files without valid headers.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Access Logging- Custom Format
6OLGH$FFHVV/RJJLQJFXVWRPIRUPDW
Instructors Note: This slide discusses the custom format available for creating a log format.
A complete list is available in the ProxySG (ProxySG) Configuration and Management Guide.
Not much to cover in this slide. Just re-iterate what the meaning of C (client), S (ProxySG),
and R (Remote Server) are. You should discuss the examples, which appear in the student
section.
The ProxySG can create access logs with any one of six formats. Four of the six are reserved
formats and cannot be configured. However, you can create additional logs using custom format
strings. Custom formats are a series of space delimited fields and each field is described using a
text string.
The different field types in a custom format are:
identifier: A field type unrelated to specific party such as date or time.
prefix-identifier: Describes information related to a party or a transfer, such as c-ip

(clients IP) or sc-bytes (how many bytes were sent from the server to the client).
prefix(header):Describes a header data field. The valid prefixes are:

c=client
s=server (ProxySG)
r=remote (OCS)
sr=server to remote
cs=client to server
sc=server to client
rs=remote to server
Custom format allows any combination of characters and format fields. Multiple spaces are
compressed to a single space in the actual access log.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Log Field Samples 1 of 2
6OLGH/RJ)LHOG6DPSOHV
Instructors Note: There are few interesting things to point out in this slide. You should
discuss all of them in form of questions.
Question: What is the username authenticated in the proxy?
Answer: student01
Question: Which domain is NOT being requested? (difficult question)

Answer: www. cnn.com as it appears as the Referer, which means it is NOT the log for a
request to www.cnn.com (however the user requested www.cnn.com, which then contains
references to external resources)
Question: What is a cache miss or a cache hit?
Answer: It is a cache miss
Reports are compiled based on the information contained in the access logs. The contents of an
access log are determined by the log field names (which determine what data types are captured
during the SG appliance logging process).
The ELFF format, which is a subset of the Blue Coat systems format, contains fields described
using a text string. The different types of fields include identifier, prefix-identifier, and
prefix-header.
Some log fields correlate to absolute data such as URLs, while others derive information from
access log variables such as browsing time.
Administrators can gain a lot of valuable information from the log fields. The fields shown in the
slide above have been described as follows:
date: GMT date in YYYY-MM-DD format
time: GMT time in HH:MM:SS format
time-taken: Specifies the time taken in milliseconds to process the request
c-ip: Specifies the IP address of the client
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
cs-username: Specifies the relative username of the client authenticated to the proxy
cs-auth-group: Specifies one group that the user belongs to. If the user belongs to multiple
groups, the group logged is determined by the Group Log Order configuration specified in the
VPM. If a Group Log Order is not sepcified, an arbitrary group is logged. Note that only
groups referenced by policy are considered
x-exception-id: Identifies the exception resolved. It is left blank if the transaction has not
been terminated
sc-filter-result: Provides the content-filtering result. The field can specify Denied,
Proxied or Observed
cs-categories: Specifies all the content categories of the request URL
cs(Referer): Specifies the URL from the Request header
sc-status: Specifies the protocol status code from the appliance to the client
s-action: Describes the action that the appliance took to process the request. TCP_MISS
means that the requested object was not in the cache
You will find description of some more actions on the following page.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Log Field Samples 2 of 2
6OLGH/RJ)LHOG6DPSOHV
Instructors Note: There are few interesting things to point out in this slide. You should
discuss all of them in form of questions.
Question: What is the IP address of the ProxySG?
Answer: 172.16.90.20
Question: What is the requested URL?

Answer: http://i.l.cnn.net/cnn/.element/css/2.0/main.css/
Question: What is really being requested? (difficult HTML question)

Answer: A style sheet.
The slide above represents another section of sample log fields. It mostly consists of client to
server prefixes that occur during a transaction. Note that apart from providing client and server
information, access logs also keep a record if a virus was detected in the transaction.
cs-method: Specifies the request method used from the client to the appliance
rs(Content-Type): Describes the information in the response header and specifies the
content type
cs-uri-scheme: Specifies the scheme from the log URL
cs-host: Specifies the host name from the clients requested URL. If rewrite policies are used,
this fields value is derived from the log URL.
cs-uri-port: Specifies the port from the log URL
cs-uri-path: Describes the path from the log URL. Does not include the query
cs-uri-query: Specifies the query from the log URl
cs-uri-extension: Specifies the document extension from the log URL
cs(User Agent): Specifies request header : User Agent
s-ip: Specifies the IP address of the appliance on which the client established its connection
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
sc-bytes: Specifies the number of bytes sent from the appliance to the client
cs-bytes: Specifies the number of bytes sent from the client to the appliance
x-virus-id: Identifies a virus if one was detected
Using these pointers, you can ascertain information that is specified in access logs. More fields can
get added depending on the client-server transaction.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Transaction Information
6OLGH7UDQVDFWLRQ,QIRUPDWLRQ
Instructors Note: You may want to discuss this slide actually earlier in the chapter, so that it
is easier for the students to answer some of the questions about the status of the transaction
or you can use it as a summary. Focus on the three main actions: TCP_MISS: The object is
cacheable but not available in cache at the moment TCP_NC_MISS: The object is
non-cacheable, therefore it is not in cache and will not be cached one retrieved. TCP_HIT: The
object is cacheable and it is available on the ProxySG.
Important: All content which contains a ? in the URL (query string) is consider dynamic
content and not worth caching. This is the most common example of non-cacheable content.
This slide describes the transaction that occurs between a client and a server and how access logs
keep a record of information that was served from a cache or entirely from the RAM, or when the
information was obtained from the origin server. The transaction is described below:
When the client first requests information (object) the ProxySG checks with the cache to see if the
requested object can be served from there. If the object is present in the cache, then TCP_HIT is
recorded in the access log and the object is sent to the client. If the object was entirely present in the
RAM, it is served from the RAM and TCP_MEM_HIT is recorded in the server action field in the
access log.
If the object was present in the cache but the virus-scanner-tag-id did not match the current
scanner tag, the object is rescanned by sending it to the ProxyAV. The server action field in the
access log then records the action as TCP_RESCAN_HIT. The object is sent to the client after the
virus scanning.
If the requested object is not found in the cache or the RAM, the request is sent to the origin server
to retrieve the object. If the requested object was not present in cache at all, the action is recorded
as TCP_MISS. Usually when objects are obtained from the origin server, the ProxySG saves a copy
in its cache. If the object returned from the origin server is non-cacheable, the action is saved as
TCP_NC_MISS. To speed up delivery of requested objects, the ProxySG can serve cached objects
while requesting for fresher content from the origin server. In this case, the action gets recorded in
the access log as TCP_PARTIAL_MISS.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Actions are also logged in the access log when objects are delivered to the client. When the obejct
is successfully delivered to the client, the action is logged as ALLOWED. When policies in the
ProxySG deny the object from being delivered to the client, the action is logged as DENIED. When
access to the requested object is denied by a filter, the action is logged as TCP_DENIED.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Access Logging Encryption
6OLGH$FFHVV/RJJLQJHQFU\SWLRQ
Instructors Note: Slide 22-8 introduces the topic of securing access logs. Do not spend a lot
of time here; the next slides discuss the topic in greater detail. However, it is important to make
sure students understand the difference between signing and encrypting before proceeding to
the next slide.
To ensure greater security, you can configure the ProxySG to digitally sign and encrypt access logs.
To encrypt access log files, you must first place an external certificate on the ProxySG. You can
import an X.509 certificate into ProxySG to use for encrypting data. The ProxySG derives a session
key from the public key in the external certificate and uses it to encrypt the log. When an access
log is encrypted, two access log files are produced: an ENC file (extension .enc), which is the
encrypted access log file, and a DER file (extension .der), which contains the ProxySG session
key and other information.
You need four things to decrypt an encrypted access log:
the ENC file
the DER file
the external (public key) certificate
the corresponding private key
To decrypt an encrypted access log, you must concatenate the DER and ENC files (with the DER
file in front of the ENC file) and use a program such as OpenSSL for decrypting. For example, use
the following UNIX command and a tool such as OpenSSL to concatenate the DER and ENC files
and decrypt the resulting file:
cat path/filename_of_DER_file path/filename_of_ENC_file | openssl smime-decrypt
-inform DER -binary -inkey path/filename_of_private_key -recip
path/filename_of_external_certificate -out path/filename_for_decrypted_log_file
You can also download a script based on the OpenSSL tool for decrypting.
Go to: https://download.bluecoat.com/release/SG4/files/accesslog_decrypt.zip.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Access Logging Digital Signing
6OLGH$FFHVV/RJJLQJGLJLWDOVLJQLQJ
Instructors Note: The idea behind signing logs is to make sure that the data is actually
coming from a specific ProxySG and is not spurious information uploaded by a malicious user.
Without the signing option, a malicious user could upload fake data to the FTP server, making
reports useless. Digital signing is very important for companies that must adhere to strict
compliance rules (for example HIPPA and SOX in the U.S.).
You can digitally sign access logs to certify that a particular ProxySG wrote and uploaded the
particular log file. Signing is supported for both content types text and gzipand for both
upload typescontinuous and periodic. Each log file has a signature file associated with it that
contains the certificate and the digital signature for verifying the log file. The signature file has the
same name as the access log file but with a .sig extension; that is, filename.log.sig, if the access
log is a text file, or filename.log.gzip.sig, if the access log is a gzip file.
You can digitally sign your access log files with or without encryption. If the log is both signed
and encrypted, the signing operation is done first, meaning that the signature is calculated on the
unencrypted version of the file. You must decrypt the log file before verifying the file. Keep in
mind that attempting to verify an encrypted file fails. When you create a signing keyring (which
must be done before you enable digital signing), keep in mind the following:
The keyring must include a private key and a corresponding x.509 certificate.
The certificate purpose must be set for smime signing. If the certificate purpose is set to
anything else, you cannot use the certificate for signing.
Add the %c parameter in the filenames format string to identify the keyring used for signing.
If encryption is enabled along with signing, the %c parameter expands to

keyringName_Certname.
Note:
Digital Signing is disabled by default. The signing feature is not available for custom
or Websense clients.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
If the file whose digital signature you want to verify is also encrypted, you must decrypt the file
prior to verifying the signature.You can use a program such as OpenSSL to verify the signature.
For example, use the following command in OpenSSL:
openssl smime -CAfile cacrt -verify -in filename.sig -content filename.log -inform
DER -out logFile
The table below explains what the terms in the above Open SSL command stand for.
Table 22-1: OpenSSL commands to verify digital signature

cacrt
The CA certificate used to issue the certificate in the signature file.
filename.sig
The file containing the digital signature of the log file.
filename.log
The log file generated after decrypting. If the access log is a gzip file, it
contains a .gz extension.
logFile
The filename that is generated after signature verification.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Access Logging- Statistics
6OLGH$FFHVV/RJJLQJVWDWLVWLFV
Instructors Note: Briefly show this slide and mention that you can see a lot of information
about the ProxySG status in the Advanced URLs available in the Management Console or
directly as shortcut URL. Open a web browser and point it to: https://{proxysg
IP}:8082/Accesslog/tail .Show the different links available there and focus on the main
access log type. Discuss how you can set the refresh time using the format:
/Accesslog/tail/<logName>?<refresh_time>
Access-log statistics can be viewed from the Management Console Statistics>Access Logging tab or
the CLI show access-log statistics [log_name] command, although not all statistics you can
view in the Management Console are available in the CLI. You can also view some access log
statistics by navigating to Statistics>Advanced and clicking Access Log.
Statistics you can view from Statistics>Advanced on the Management Console include:
Show list of all logs: The access log manages multiple log objects internally. These are put
together as one logical access log file when the file is uploaded. The show list shows the
available internal log objects for easy access. To download part of the access log instead of the
whole log file, click on the individual log object shown in the list. The latest log object can be
identified by its timestamp.
Show access log statistics: The statistics of an individual access log is shown.
Show statistics of all logs: The statistics of all the access logs on the system are displayed in a
single list.
Show last N bytes in the log: The last N bytes in the log are shown.
Show last part of log every time it changes: A stream of the latest log entries is shown on the
page as they are written in the system.
Show access log tail with optional refresh time: A refresh from the browser displays the latest
log entries.
Show access log objects: The statistics of individual access log objects are displayed.
Show all access log objects: The statistics of all access log object are displayed in a single list.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The Log Size tab on the Management Console displays current log statistics:
whether the log is being uploaded
the current size of all access log objects
disk space usage
last modified time
estimated size of the access log file, once uploaded.
The ProxySG displays the current access logging status on the Management Console. This
includes separate status information about:
the writing of access log information to disk
the client the ProxySG uses to upload access log information to the remote server.
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 23: Web Cache Communication Protocol (WCCP)
Instructors Note: This chapter describes how WCCP works between ProxySG and Cisco
WCCP-capable router to achieve transparent proxy. Differences between WCCP version 1
and WCCP version 2 are clearly highlighted with different deployment scenarios given. Spend
ample time discussing the advantages WCCP version 2 has over WCCP version 1. For
example the support for multiple routers and the ability to support other protocols such as FTP
and streaming.
Todays networks require proxy services in order to secure inbound and outbound
communications. Therefore, communications need to be intercepted by the proxy services in order
to apply a secure policy.
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 ProxySG, with the aim of optimizing resource usage and lowering response times.
The main benefits of using WCCP are:
Q Scalability: With no reconfiguration overhead, redirected traffic can be automatically

distributed to up to 32 appliances.
Q Redirection safeguards: If no appliances are available, redirection stops and the router
forwards traffic to the original destination address.
WCCP has two versions, version 1 and version 2, both of which are supported by Blue Coat.
However, only one protocol version can be active on the SG appliance at a time. The active WCCP
protocol set up in the SG configuration must match the version running on the WCCP router.
A WCCP-capable router operates in conjunction with the appliances to transparently redirect
traffic to a set of caches that participate in the specified WCCP protocol. IP packets are redirected
based on fields within each packet. For instance, WCCP version 1 only redirects destination TCP
port 80 (default HTTP traffic) IP packets. WCCP version 2 allows you to redirect traffic from other
ports and protocols.
If you use WCCP version 2, 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 SG appliance for servicing. The
amount of redirection hash tables assigned to each SG appliance can be altered to provide a form
of load balancing between caches in a service group.
A hash table is configured by a dynamically elected SG appliance participating in service group,

enabling the simultaneous interception of multiple protocols on multiple ports. You can configure
up to 100 dynamic or standard service groups. A single service can intercept up to eight port
numbers.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
What is WCCP ?
Web Cache Communication Protocol by Cisco

Available on Cisco Routers and L3 Switches
Works with Blue Coat SG to achieve transparent

proxy
6OLGH:&&3,QWURGXFWLRQ
Instructors Note: Make sure that students understand what transparent proxy is. Point out to
students that in transparent proxy, clients do not know there is a proxy in the path. Lead the
students to discuss about the characteristics of transparent proxy, the various ways of
implementing transparent proxy and the advantages of using it.
WCCP was first described in the Internet-Drafts of IETF on June 1999 by Cisco Systems. WCCP is
supported on various models of Cisco Routers and Cisco L3 Switches. Specifically, WCCP Version
1 is supported in IOS 11.1 and above while WCCP version 2 requires the equipment to have at
least IOS 12.0(3) .
The Web Cache Control Protocol (WCCP ) feature allows redirection of web traffic transparently to
a Blue Coat Proxy SG with no configuration on the clients. WCCP also offers proxy load balancing
to as many as 32 SG appliances with very minimal configuration.
ProxySG and routers become aware of one another and form a service group using management
packets defined in WCCP. Once the service group has been established, one of the ProxySGs is
designated to determine the load assignments among other ProxySGs. All ProxySGs periodically
communicate with the home router to verify WCCP protocol 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.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
WCCP Overview
6OLGH&OLHQWV+7735HTXHVWDUHEHLQJUHGLUHFWHGE\:&&3SURWRFRO
Instructors Note: Explain to students that WCCP is used to redirect requests from the router
to the ProxySG so that policies configured on the ProxySG can be enforced.
As the request from clients user agent arrived at the router, the router will intercept the request
and forward it to the ProxySG .
Generally there are two ways the request can be intercepted and forwarded to router.
GRE: 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: 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 you 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. The caveat in L2 MAC rewrite however, requires that both the ProxySG
and the WCCP-capable router to be in the same broadcast domain.
If you want to continue using GRE, there is no configuration needed. However, to use L2 MAC
rewrite, you must add forwarding-type L2 option to the SG configuration file.
Note:
WCCP is also known as Web Cache Control Protocol and Web Cache Coordination
Protocol in some IETF Internet-Drafts.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
WCCP Overview
WCCP version 1
Support port 80 http traffic only

Single router deployment
WCCP version 2
Support for other ports and protocols

For e.g., HTTP, HTTPS, FTP
Multiple routers deployment
Multicast interaction
6OLGH7KHWZRYHUVLRQVRI:&&3
Instructors Note: Highlight to the students the differences between WCCP version 1 and
WCCP version 2 and make sure they understand the limitations of WCCP version 1.
In WCCP version 1, the WCCP-configured home router transparently redirects TCP port 80
packets to a maximum of 32 appliances. One of the caches participating in the WCCP service
group is automatically elected to configure the home routers redirection tables. This way, caches
can be transparently added and removed from the WCCP service group without requiring
operator intervention. WCCP version 1 supports only single service group.
WCCP version 2 offers the same capabilities as version 1, but with greater support for more than
just HTTP traffic. WCCP version 2 is more suitable in a multiple router deployment as it allows
multicast exchange packets to discover both the router and the ProxySG.
Note:
WCCP version 2 is enabled by default when you name a WCCP service group.
Version 1 requires a specific enable command. For example if you do not explicitly
configure the Blue Coat SG to run any version, version 2 is selected by default. In
event you are having older version of IOS router which only supports WCCP version
1, you will have to add wccp version 1 command in the configuration file.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
WCCP Version 1 Deployment
6OLGH:&&39HUVLRQ'HSOR\PHQW6FHQDULR
Instructors Note: Highlight to the students that WCCP version 1 does not require
configuration of port number as it only supports TCP port 80 (HTTP). Note that WCCP does
not perform protocol detection and thus non HTTP traffic with destination port 80 will also be
redirected.
In WCCP Version 1, the Blue Coat SG is configured with the address of the single router under the
home-router command. When a WCCP-capable router receives an IP packet, the router
examines the packet header to see if it has destination port 80 in the TCP header. Upon seeing
packets with destination port 80, router will redirects it to ProxySG.
1.
A clients user agent sends HTTP request to the original content server (OCS).
2.
The router will intercept all packets having destination port 80 on the TCP header and
redirects it to ProxySG either by using GRE encapsulation or L2 redirect method.
3.
ProxySG processes and applies configured policy, and if the clients request is not denied,
fetches the web objects from the OCS.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
WCCP Version 2 Deployment
6OLGH:&&39HUVLRQ'HSOR\PHQW6FHQDULR
Instructors Note: Highlight to the students that intercepting traffic on other TCP ports require
additional configuration on the ProxySG. For example, to intercept HTTP, FTP, Real Network
and Windows Streaming, you will have to add port 80, 21, 554, 1755, 0 0 0 0. Take note that
the 4 ending zeros are there because a single configured service group can intercept up to
eight port numbers.
WCCP Version 2 requires that each Blue Coat SG be aware of all the routers in the service group.
Optionally, Version 2 can use multicast packet exchange for discovery. Configuring a multicast
address on a WCCP-capable router provides reduced WCCP traffic and the ability to easily add
and remove caches and routers from a service group without having to reconfigure all service
group members.
The following sequence of events explains how WCCP Version 2 works:
1.
Each ProxySG sends Here_I_AM packets to the configured list of routers. Routers will build a
view (list) of all Blue Coat SG that is visible.
2.
Clients may send request to different routers on different departments.
3.
The WCCP-capable routers will redirect any configured TCP traffic to the ProxySG. For
example:
Q Port 21 (FTP)
Q Port 554 (Real Networks and Quick Time)
Q Port 1755 (Windows Media Streaming)
4.
ProxySG processes and applies configured policy, and if the clients request is not denied,
fetches the web objects from the original content server.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
WCCP Packet Exchange
6OLGH:&&33DFNHW([FKDQJH
Instructors Note: Tell the students that the router increments the value of the Received_ID
field each time it sends a I_SEE_YOU to the ProxySG and expects to receive the same value
back in the Received_ID field of the next HERE_I_AM from the ProxySG. This technique is
mainly used as a form of acknowledgement.
The following explains the packet exchange used in WCCP discovery process:
1.
ProxySG sends a HERE_I_AM packet periodically to the configured WCCP-capable router.
2.
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 packet at a fixed interval. The source IP address of the HERE_I_AM uniquely
identifies the Blue Coat Proxy SG. The router sends an I_SEE_YOU packet back to the SG in
response to each HERE_I_AM it receives.
To specify the address of the WCCP-capable router in the service group, you can use one of the
following method:
1.
Unicast : The IP addresses of the router is explicitly defined in the ProxySG.
For example : home-router 10.1.1.1
2.
Multicast : A single multicast address is configured on all ProxySG.
For example : home-router 224.1.1.1
Important: The valid multicast addresses supported by ProxySG are in the range of 224.0.0.0
to 239.255.255.255. The routers will also have to be configured to listen to the
same earlier configured multicast address by using ip wccp group-listen
command.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
WCCP Configuration
6OLGH:&&3FRQILJXUDWLRQVQDSVKRWVIURP3UR[\6*
Instructors Note: Point out that there are various ways of configuring WCCP in the ProxySG.
If time permits, take the initiative to demonstrate the different ways a configuration can be
entered into the ProxySG.
You can create a configuration file customized for your environment through the Command Line
Interface (CLI) or through a text file. The CLI enables the WCCP on the SG appliance immediately;
the drawback is that if any information changes, you must recreate the whole file using the CLI.
With a text file, if any information changes, you can change the individual line; the drawback is
that you must download the file again from an HTTP server to the ProxySG.
The following are two examples of the WCCP configuration in the ProxySG:
1.
Redirecting HTTP Only
To redirect HTTP traffic only, use the following commands in the WCCP settings editor on the SG
appliance.
wccp enable
wccp version 2
service-group web-cache
home-router 10.254.0.193
interface 0
end
In this example, WCCP version 2 is used, the service-group is configured to intercept HTTP traffic
and 10.254.0.193 is the IP address of the Cisco router.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
2.
Redirecting HTTP and Streaming
To redirect HTTP and Streaming protocol, you must use WCCP version 2 and the following
configuration can be used.
wccp enable
wccp version 2
service-group 10
priority 1
protocol 6
service-flags destination-port-hash
service-flags ports-defined
ports 80 554 1755 0 0 0 0 0
interface 0
end
In this configuration, traffic is being redirecting to the following TCP ports:
Q 80 (HTTP)
Q 554 (Real Networks and Quick Time)
Q 1755 (Windows Media Streaming)
10.254.0.193 and 10.254.0.194 are the IP address of the two participating routers.
To configure WCCP-capable router to redirect HTTP only, use the following commands in the
Cisco routers:
Router#config terminal
Router(config)#ip wccp web-cache

Router(config)#interface f0/0
Router(config-if)#ip wccp web-cache redirect out
To configure WCCP-capable router to redirect HTTP and streaming traffic, use the following
commands:
Router#config terminal
Router(config)#ip wccp 10
Router(config)#interface f0/0
outer(config-if)#ip wccp 10redirect out
Note:
Make sure the IP WCCP number in the router matches the service group number
configured in the ProxySG
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Monitoring WCCP on a Router
To monitor traffic redirected via WCCP, log on to the router and use the following commands
Router# show ip wccp
Global WCCP information:

Number of web-caches: 2
Total Packets Redirected:101

Redirect access-list:none
Total Packets Denied Redirect: 88

Total Packets Unassigned: 0
Table 23-1: Fields Description in Global WCCP information

Field
Description
Number of web-caches
Number of web-caches using the router

as the home router
Total Packets Redirected
Total number of redirected packets by the

router
Redirect access-list
Number of the access list that decides

which packets will be redirected
Total Packets Denied Redirect
Total number of packets that were not

redirected because they did not match the
access list
Total Packets Unassigned
Number of packets that were not

redirected because they were not
assigned to any ProxySG.
Note:
You may see many packets under the Total Packets Unassigned at the initial discovery
of the ProxySG or when ProxySG is dropped from a cluster.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
InstructorsLab Notes for Web Cache Communication Protocol

Overview
Each student will telnet into the classroom a Cicso Router to configure thier own service group
redirection. Students will create their own access-list that redirects their own computer IP to their
service group.
Equipment
Role
IP Address
Cisco Router
To perform WCCP
redirection
172.16.90.1
Students PC
Testing Host
172.16.90.1x
Students SG
Proxy
172.16.90.2x

Software/Hardware
Firefox
Version/Model
Version 2.0.0.5
Internet Explorer
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build
Cisco Router
Cisco ISR 1811 with IOS version 12.0

or above. Two FE ports required.

Software/Hardware
Firefox
Version/Model
Version 2.0.0.5
Internet Explorer
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build
Desired Results
Students will connect to the internet via the Internet Explorer. They should verify that the
connection has been redirected to their own ProxySG by observing the Active Sessions.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 24:Health Checks
Instructors Note: The goal of this chapter is to describe the function of Blue Coats health
check, why it is important and useful, and how it works. The main function of health checks is
to allow Blue Coat customers to monitor their external resources that work with Blue Coat
products. Customers are able to monitor many resources such as SOCKS gateways and
Websense off-box services.
Health checks gives customers an easy way to make that the resources they rely on are
running properly and effectively. This chapter will describe how these check are done,
depending on what is being checked, and how customers can view the health check state of
each resource of resource group.
Health checks are tests run on external resources, such as forwarding hosts, SOCKS gateways, and
ICAP and Websense off-box services, to determine status. You can use health checks in
conjunction with various failover mechanisms to handle a variety of failure scenarios. For
example, you can use health checks with forwarding rules to redirect traffic from one server or
proxy to another.
If the health check for an individual host fails, the ProxySG appliance can select a healthy host
ahead of time or report the failure quickly.
Health checks test for:
Network connectivity
Target responsiveness
Basic functionality of the upstream system or service
Health checks fall into three broad categories:
Determining if the IP address can be reached. Health check types that fall into this category
are:
Q Forwarding hosts
Q SOCKS gateways
Q Dynamic Real-Time Rating (DRTR) service
Determining if a service is responsive. Health check types that fall into this category are:
Q ICAP services
Q Websense off-box services
Determining if a group is healthy. Group tests are compilations of individual health checks,
and the health of the group is determined by the status of the group members. Health check
types that fall into this category are:
Q
Q
Q
Q
Forwarding groups
SOCKS gateway groups

ICAP service groups
Websense off-box service groups
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Health checks always have status. The status of any health check can be referenced in policy as a
condition. You can run an immediate health check from the Management Console. You can also
view the health check state on the Statistics > Health Check tab, but you cannot change settings in
Statistics.
A number of health checks are automatically generated, based on:
Forwarding configuration
SOCKS gateways configuration
ICAP configuration
Websense off-box configurations
Whether DRTR is enabled
Note:
You also can create user-defined health checks, including a composite health check
that compiles the results of multiple other health check tests.
Background testing of the DNS resolutions is done 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
(TTL) value of the DNS entry expires.
Note:
If a hostname consists of a dotted IP address, no 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 24: Health Checks
Health Check Types

Automatically Generated
Forwarding object (SOCKS Gateway, forwarding

hosts)
DRTR, ICAP, External services
User-defined
Host based
Composite
6OLGH&DWHJRULHVRI+HDOWK&KHFNV
Instructors Note: You should ask your audience the following question:
You create a SOCKS gateway, which points to a machine where there is a service running on
TCP port 1080; however the service is NOT SOCKS but HTTP. Would the pre-defined health
check for SOCKS gateways fail or no?
Answer: No, it will not fail as the health check only verifies that is possible to open a TCP
connection and does not verify protocol.
Tip: Do not respond right away but let the students think about it and verify if they can correctly
answer after you discuss Slide 24-4.
There are two categories of health checks, which ProxySG makes available: automatically generate
and user defined. Health checks are very important as they allow a ProxySG to know if a resource
is available before it even attempts to connect.
Automatically Generated
Every time you configure a forwarding host or a SOCKS gateway, the appliance generates a set of
health checks, appropriate for that object. For example, by default, when you create a SOCKS
gateway, the ProxySG automatically generates a health check object, which tests if there is a
SOCKS service running on the port that you specified in the gateway configuration (usually 1080).
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 (sending a ACK, RST TCP response), the system is labeled as not healthy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
User-defined
You can manually create and manage ICMP, TCP, HTTP/HTTPS, or SSL health check tests for any
upstream TCP/IP device. You can use these user-defined health check types to send notifications
of health check state changes. Under most circumstances, you do not need to create user-defined
health checks; the 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 Blue Coat 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, accepting that so long as a certain number
of the sites are healthy, then the Internet is considered healthy.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Health Checks Connections
6OLGH+HDOWK&KHFN&RQQHFWLRQV
Instructors Note: Describe why Blue Coats health check system is important to the overall
implementation of Blue Coat products. Use examples of general connection types and
commonly used external resources to support this point. Forwarding hosts and SOCKS
gateways both use the TCP test to check health states.
Blue Coats health check system allows you to not only monitor your Blue Coat products, but also
many of the external resources that are used by your ProxySG. This helps you maintain and
monitor your network and Blue Coat equipment.
Forwarding Hosts and SOCKS Gateways
ICMP, TCP, HTTP, and HTTPS tests can be defined for a forwarding host. A forwarding host can
also have its test defined to be the result of a previously defined composite health check. The
default for a newly created forwarding host is a TCP health check using the first port defined in
the forwarding hosts port array, which is typically the HTTP port. The port used with a TCP test
can be changed in configuration.
ICMP and TCP tests can be defined for a SOCKS gateway. A SOCKS gateway can also have its test
defined to be the result of a previously defined composite health check. The default health check
when a SOCKS gateway is created is a TCP test, conducted using the SOCKS port defined in the
SOCKS gateway configuration. The port used with a TCP test can be changed in configuration.
External Services
External Services include ICAP, Websense off-box, and the DRTR rating service. 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 ICAP and Websense off-box services will be changed to automatically create and destroy their
health checks. If a user does not desire a health check for a particular service, it can always be
disabled. During an upgrade, any new health checks that are added will be configured as
disabled, so as to match existing behavior.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Health Checks Categories
6OLGH+HDOWK&KHFN&DWHJRULHV
Instructors Note: This slide and page describe the basic tests that the Blue Coat health
check system can perform. Do not go into to too much detail here, as the specifics of each test
depends greatly on what is being tested. How each test is performed is discussed in more
detail on Slide 9-4.
As previously stated, the Blue Coat health check system is a series of tests performed by ProxySG
to determine if a resource is available for use. However, since there are many resources that a
ProxySG can use in its normal operations, there is also a large number of tests that appliance can
perform. Similarly, this multitude of tests check many different statistics. Which test is performed
depends on which resource the ProxySG is testing.
The most basic test determines whether the resource being tested is either healthy or sick.
However, the way the health check is determined depends on the test being used.
The ProxySG is able to perform a responsiveness check on all resources. The minimum,
maximum, and average response times are tracked. Their values are cleared whenever the
health check changes states.
At present, the DRTR code conducts a DNS resolution of the target host name and then
registers each IP address with the health checks for testing. It then uses the results to conduct
response time load balancing of the healthy IP addresses. The DNS resolution is updated once
every 24 hours, and if necessary health checks are automatically deleted and created to match
any changes to the IP addresses
Health checks can also be used to monitor the health any of the available groups. These
groups include forwarding groups, SOCKS gateway groups, and ICAP and Websense off-box
external service groups.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Health Checks Modes
6OLGH+HDOWK&KHFN0RGHV
Instructors Note: The focus of this slide is how the health check tests performed by the
ProxySG are done. In the slide, there is an example of each type test, which are described
below. Go over each test to give students an understanding of how the health check systems
versatility is able to test and monitor the different resources that interact with Blue Coat
products.
There are many ways that a Blue Coat appliance can perform health checks. A few of the possible
tests are listed below.
HTTP/HTTPS for Server and Proxies
HTTP/HTTPS tests execute differently depending on whether the upstream target is a server or a
proxy. For a forwarding host, the server or a proxy is a defined as part of the forwarding host
configuration. For a user-defined health check, the target is always assumed to be a server.
For a server:
The HTTP test sends an GET request containing only the URL path to an HTTP port.
The HTTPS test sends an GET request containing only the URL path over an SSL connection to
a terminating HTTPS port.
For a proxy:
The HTTP test sends an GET request containing the full URL to an HTTP port.
Since a server is required to terminate HTTPS, the HTTPS test sends an CONNECT request to
the HTTP port.
In the case of both servers and proxies, if an appropriate port is not available on the target, the test
fails.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
TCP Socket Connection Test
A TCP test establishes that a TCP layer connection can be established to a port on the host. Then
the connection is dropped. TCP tests for a forwarding host or a user-defined health check support
SOCKS gateways policy but not forwarding policy. TCP tests for a SOCKS gateway do not support
policy for SOCKS gateways or forwarding.
Ping (ICMP Test)
The basic connection between the Blue Coat appliance and the origin server is confirmed. The
server must recognize ICMP echoing, and any intervening networking equipment must support
ICMP. The Blue Coat appliance sends a ping (three ICMP echo requests) to the host.
ICMP tests do not support policy for SOCKS gateways or forwarding.
Group
A group test is a combination of individual tests that are combined for any of the four different
available groups (forwarding, SOCKS gateways, ICAP, and Websense off-box). If any of the
members is healthy, then the group as a whole is considered healthy.
Additionally, Blue Coat supports a composite test, used only with composite (user-defined) health
checks, that is similar to a group test except that, by default, all members must be healthy for the
result to be healthy. These settings are configurable.
By default, group health tests are used for two purposes:
Monitoring and notification
Policy
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Notifications
6OLGH+HDOWKFKHFNQRWLILFDWLRQV
Instructors Note: The health check notification system allows administrators to know about a
health check state change almost immediately. Be sure to say that this a configurable option,
allowing the customer to set the notifications to best suit their needs. There are three types of
notifications that the user can choose from: e-mail, event logs, and SNMP traps.
When configuring your health check system, it is possible to enable notifications. E-mail and event
log notifications can be sent when a change of health check state occurs. 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. For example, if you have multiple IP addresses
resolved and only one (or a few) of them works, that is healthy enough to be classified as healthy.
The health can continue to improve.
There three ways to receive notifications:
An e-mail notification can be sent to an administrator in the event of a health check state
change.
In the event log, state changes can be logged as either informational or severe logs. You can
enable notifications for each resolved IP address of a target device (if applicable), in addition
to the overall health of the device.
SNMP traps can also be configured to provide notification.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Instructors Notes for Health Checks Lab

Overview
Students will manually create a TCP 80 and ICMP health check for a host.
Equipment
Students SG
Role
IP Address
ADN Peer
172.16.90.2x

Software/Hardware
Version/Model
Firefox
Version 2.0.0.5
Internet Explorer
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build

Software/Hardware
Version/Model
Firefox
Version 2.0.0.5
Internet Explorer
SGOS
5.2.1.3 build 30166
Windows XP
SP2 build
Desired Results
The health check should initially show healthy. After deleting the default gateway, the health
check should fail.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 25: ProxySG Security
Instructors Note: This page presents a brief introduction to the various methods of securing
access to the Blue Coat SG. More information is given in subsequent pages. The
important thing to stress is that using the CPL to define access policies is the most secure
method.
You can provide read-only or read-write access to the ProxySG in the following ways:
Console account minimum security
The console account username and password are evaluated when the ProxySG is accessed
from the Management Console through a browser and from the CLI through SSH with
password authentication. The Enable (privileged-mode) password is evaluated when the
console account is used through SSH with password authentication and when the CLI is
accessed through the serial console and through SSH with RSA authentication. The simplest
way to give access to others is to share this basic console account information; however, but it
is the least secure method and is not recommended.
To give read-only access to the CLI, do not give out the Enable (privileged-mode) password.
Console access control list moderate security
Using the access control list (ACL) allows you to further restrict use of the console account and
SSH with RSA authentication to workstations identified by their IP address and subnet mask.
When the ACL is enforced, the console account can be used only by workstations defined in
the console ACL.
Blue Coat Content Policy Language (CPL) maximum security
CPL allows you to control administrative access to the ProxySG through policy. If the
credentials supplied are not the console account username and password, policy is evaluated
when the ProxySG is accessed through SSH with password authentication or the Management
Console. Policy is never evaluated on direct serial console connections or SSH connections
using RSA authentication.
You can also restrict access to a single IP address that can be used as the emergency recovery
workstation.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Role-Based Security 1 of 3
;; Tab: [Admin Authentication Layer (1)]

<Admin>
authenticate(blue_coat) authenticate.force(no) trace.request(yes) trace.rules(yes)
; Rule 1
6OLGH5HVWULFWLQJDFFHVVE\DXWKHQWLFDWLRQUHDOP
Instructors Note: This slide and the following slide are very important because they show
the preferred method for securing access to the ProxySG. Its important to note that once CPL
policies have been created, the administrator must configure the console ACL to deny all
access. Otherwise, the IP addresses listed in the console ACL can still administer the
ProxySG.
The preferred method of restricting administrative access is to use CPL to create policies that limit
access to one or more authentication realms. An authentication realm is the set of systems that is
served by a single logical authentication database. A realm can include any combination of one or
more systems or workstations.
The ProxySG uses CPL to define policies, including administrator, authentication, and
authorization policies. CPL also allows you to give administrator privileges to users in any
external authentication service. You can configure policies using the Visual Policy Manager or by
directly editing CPL policy files.
To control administrative access using CPL, you must do the following:
Using the CLI or the Management Console GUI, create an authentication realm to be used for
authorizing administrative access. For administrative access, the realm must support BASIC
credentialsfor example, LDAP, RADIUS, Local, or IWA with BASIC credentials enabled.
Using the Visual Policy Manager, or by adding CPL rules to the Local or Central policy file,
specify policy rules that: (1) require administrators to log in using credentials from the
previously-created administrative realm, and (2) specify the conditions under which
administrators are either denied all access, given read-only access, or given read-write access.
To prevent anyone from using the console credentials to manage the ProxySG, set the console
ACL to deny all access (unless you plan to use SSH with RSA authentication).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 25: ProxySG Security
Role-Based Security 2 of 3
define condition __USER1

realm=Blue_Coat user=MYDOMAIN\Bob.Smith"
end condition __USER1
;; Tab: [Admin Access Layer (1)]

<Admin>
condition=__USER1 allow admin.access=(read,write) trace.request(yes) trace.rules(yes) ; Rule 1
Deny
; Rule 2
6OLGH6HWWLQJDFFHVVSHUPLVVLRQVWRUHDOPPHPEHUV
Instructors Note: This slide shows the second step in creating CPL access policies,
specifying the conditions under which administrators are either denied all access, given
read-only access, or given read-write access.
Once you have allowed the authentication realm, you can specify whether read-only or read-write
access is given to members of the realm. You can make the policy contingent on IP address, time of
day, group membership (if credentials were required), and many other conditions.
As you can see in this example, user Bob Smith is allowed Read/Write access. Slide 25-2 also
shows the textual policy rules generated by these Visual Policy Manager settings.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Role-based Security 3 of 3
6OLGH5HVWULFWLQJFRQVROHDFFHVV
Instructors Note: This slide shows you how to limit access using the console ACL. You
should stress that while this method is somewhat secure, it is not nearly as secure as the CPL
method described in the preceding pages. Also, its extremely important that you remind
students that if they want to use this method, they must ensure that the IP address of their
console is included in the console ACL. Otherwise, they will lock themselves out of the system
and will have to use a serial console to add themselves back in.
The ProxySG allows you to limit access to the Management Console and CLI through the console
access control list (ACL). Slide 25-3 illustrates the console ACL set in the Management Console
and the equivalent CLI command. Only the workstation IP addresses listed in the ACL are able to
use the Management console account to administer the ProxySG.
Once set up, the console ACL is enforced only when console credentials are used to access either
the CLI or the Management Console, or when an SSH with RSA authentication connection is
attempted.
Important: Before you enforce the ACL, verify the IP address for the workstation you are
using is included in the list. If you forget, or you find that you mistyped the IP
address, you must correct the problem using the serial console.
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 26:Introduction to Blue Coat Director
Instructors Note: This chapter explains how organizations with multiple Blue Coat SG
appliances can benefit by using Blue Coat Director. Director makes it easy to manage
ProxySG appliances individually or in groups in branch offices as well as at the
companys core. This chapter also serves as an introduction to the rest of this textbook. Do not
go into detail here; the following chapters and lab exercises provide details about how Director
works and the specific tasks that you can perform with the appliance.
Important: The lab exercises provided for this course are instructor-led because it is not
practical for each student to access the Director appliance. However, the lab exercises are
provided to students so students can follow the procedures in class and refer to them later
when they set up and work with Director in their organizations.
The Management Console makes it easy to manage a ProxySG appliance. However, installing
configuration or policy updates on multiple appliances particularly in a distributed
environment can be a tedious and time-consuming task. Fortunately, 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 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 perform most tasks through an easy-to-use management interface that runs on any 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.
Ideal for WAN Application Acceleration
Director can be anywhere on your network so long as 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 SG appliances. Organizations with four or more
ProxySG appliances may 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 (ADN) to accelerate WAN traffic. Director makes it simple to
configure and manage the multiple ProxySG appliances that their networks require.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Course Organization
This course discusses Director running the Security Gateway Management Edition (SGME) 5.1.3.x
operating system or higher. The courses chapters and lab exercises cover the following topics:
Director architecture
Initial configuration of Director through the command-line interface (CLI) and client graphical
user interface (GUI)
Configuring and managing ProxySG devices
Monitoring ProxySG devices
Managing content with Director
Administering Director
Director Terminology
Several terms used in this textbook and lab exercises are specific to 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.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 26: Introduction to Blue Coat Director
Director Deployment
6OLGH'LUHFWRUGHSOR\HGLQWKHHQWHUSULVH
Instructors Note: The illustration and text on this page emphasize how Director can
configure, manage, and monitor all the ProxySG appliances in an organization from a single
location, typically at the organizations core. Emphasize that centralized management makes it
easy for organizations to perform many key tasks: installing and managing configurations and
policy, controlling the use of network resources, and monitoring the health of SG appliances.
A Director appliance is typically installed at an organizations headquarters and from there 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
Q Create and install standard configurations and policies throughout the enterprise. These
can include settings to enable application acceleration over the WAN.
Q
Q
Q
Q
Q
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
Q Manage bandwidth to conserve valuable resources.

Q Distribute content, including frequently used files to Blue Coat SG caches, expediting
downloads and reducing network traffic.
Q Limit access to Internet and intranet resources.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Monitoring and planning
Q Monitor key hardware and software metrics of ProxySG appliances remotely.

Q Create settings to issue alerts when certain changes occur.
Q Use statistics to evaluate and update network policies.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Components and Communication
6OLGH'LUHFWRUFRPSRQHQWVDQGWKHLUVHFXUHFRPPXQLFDWLRQV
Instructors Note: This page gives an overview of the components of the Director platform
and how they communicate with each other. Make clear that SSHv2/RSA is the preferred
authentication method between the Director and devices and between Director and the client.
It is important to emphasize this point because the Director labs use SSHv2 with simple
password authentication (not RSA) between Director and the client in the interest of saving
classroom time.
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
SG800/810 chassis or an SG510 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 devices: 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 between 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Managing Devices
6OLGH:RUNLQJZLWKGHYLFHV
Instructors Note: This page outlines the basics of how Director enables you to manage
multiple Blue Coat SGs. It introduces the concepts of grouping, applying profiles to distribute
basic settings, and applying overlays to customize selected devices. Do not spend a lot of time
on any one of these topics; they are discussed in greater detail later in this textbook and in the
lab exercises.
Administrators can perform a variety of actions through Director to manage Blue Coat SG
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Monitoring Devices
6OLGH0RQLWRULQJGHYLFHVZLWK'LUHFWRU
Instructors Note: One of the Directors most useful features is the ability to monitor the
ProxySG devices connected to it. The Monitor tab makes it easy to get an instant view of the
status of each group and individual device connected to Director.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Managing Content
6OLGH0DQDJLQJFRQWHQW
Instructors Note: How Director helps manage content in the distributed enterprise is
discussed in detail later in this textbook. At this point, simply outline the key concepts and
benefits of using Director to push content from the data center to branch offices.
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 (CDNs) 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Administering Director
6OLGH$GPLQLVWHULQJ'LUHFWRU
Instructors Note: This page introduces the primary tasks involved in administering the
Director appliance itself: controlling access to Director, logging activity, and backing up the
appliance.
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 CLI 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 27:Introduction to Blue Coat ProxyRA
Instructors Note: This chapter discusses the basic concepts behind the Blue Coat
ProxyRA. Discuss the various advantages of using the remote access feature when an
organization keeps expanding in terms of people and its resources. Also briefly cover the
issues of endpoint security when people try to access an enterprises resources remotely.
Make sure you brief the class about how the Blue Coat ProxyRA eleiminates the need for a
client side VPN solution. And finally, do not forget to mention how the Blue Coat ProxyRA
supports multiple authentication methods.
To meet the needs of the extended enterprise, organizations must manage a complex array of
demands and requirementsincluding diverse remote user groups; managed and unmanaged
devices; wireless and wired networks; regulatory compliance; and threats from malware, viruses,
information leakage and theft. What was once a onedimensional connectivity problem has grown
into a multi-dimensional connectivity, security, and policy enforcement dilemma. Traditional
remote access solutions, designed for simple connectivity, do not provide a scalable foundation to
meet expanding enterprise needs. The resulting "add-ons" and loose integrations have forced
organizations to accept the high costs and complexities of multiple management consoles, thick
client software administration, and hidden product limitations.
Blue Coat ProxyRA eliminates these complexities, and provides a safe, secure, and unified
connectivity solution to both managed and unmanaged endpoints. ProxyRA delivers the
following without the compromise required by other solutions:
Offers the following endpoint security services:
Q Detects and blocks spyware (keyloggers and screen capture programs) before
authentication, protecting your network access and reducing user risk
Q Prevents malware originating at the endpoint from accessing the corporate network
through the VPN connection in real-time
Q Provides granular and continuous host integrity checking that assures you of ongoing
security compliance at the known or unknown endpoint
Q Verifies the integrity of connecting applications to prevent malware hijacking or

masquerading
Q Allows you to apply policy-based information controls to prevent the copying, printing,
or saving of information to the endpoint
Q Offers automatic encryption of the client cache, temporary files, and other session
information to prevent snooping by programs or people
Q Removes all protected data before ending a ProxyRA Connector session to reduce the
risk of accidental data trails or information leakage
Grants application access based on user role and location
Works with any TCP or UDP application
Removes the need for client-side VPN software installation
Removes the need for administrator privileges on the endpoint
Allows tiered access based on client security status
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Company acquisitions and mergers further complicate the job of the network and security
administrator by introducing unmanaged devices and multiple authentication methods. ProxyRA
offers seamless support for multiple authentications methods,including the following:
Blue Coat internal user repository
Lightweight directory access protocol (LDAP) authentication and secure LDAP, including
Microsoft Active Directory
Remote Authentication Dial-In User Service (RADIUS) authentication
RSA SecurID server authentication, including RSA ClearTrust
Terminal Access Controller Access Control System Plus (TACACS+) authentication.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 27: Introduction to Blue Coat ProxyRA
Blue Coat ProxyRA
Clientless SSL VPN solution
Extends secure remote access to both corporate

and unmanaged desktops
Painless deployment
Protects your network and information

Works with any application
6OLGH%OXH&RDW5$RYHUYLHZ
Instructors Note: This slide is a brief overview of what is to come in the following pages. Do
not spend much time over this slide.Give a brief description of the Blue Coat ProxyRA here.
ProxyRA is an on demand SSL VPN that provides secure remote access for employees, partners
and customers. With integrated endpoint security and information protection features and no
VPN client software or local Admin rights required, ProxyRA provides an ideal remote access
solution for extending applications and resources to users on unmanaged endpoints that are
beyond the reach of IPSec VPNs and traditional SSL VPNs. ProxyRA is the industrys only
application-independent architecture and utilizes patent-pending on demand Connector
technology.
Some of the unique features of the ProxyRA are
Provides out-of-the-box support for web and non-web TCP and UDP applications
Provides uninterrupted access to both simple and advanced and feature-rich web applications
(XML, ActiveX, AJAX, Java, etc.)
Provides on demand access to packaged nd custom client-server and Web applications

through unique on demand connectivity agent
Controls access by applications for all supported applications and never requires unrestricted
network-layer connectivity
Provides endpoint security for managed and unmanaged devices seamlessly integrated with
remote access deployment and management
Identifies and temporarily suppresses processes and programs identified as potential threats,
such as framegrabbers and keyloggers, for the duration of user session without any
permanent system changes
Allows administrators to limit which applications can reach specific resources to block
unauthorized programs from contacting the internal assets
Defines access by user, target resource, source/location of user, time of day, and security
profile of connecting device
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Integrates with leading authentication schemes, such as Microsoft Active Directory,

LDAP/LDAPS, RADIUS, RSA SecurID, and TACACS+
Encrypts all information stored by the browser, including cache, temp files and cookies, and
clears all session information at the end of SSL VPN session using DoD 5220.22-spec file
deletion.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Proxy RA Components
6OLGH3UR[\5$&RPSRQHQWV
Instructors Note: This slide goes into details on the various components of the Blue Coat
ProxyRA ProxyRA Server, ProxyRA Manager, ProxyRA Connector. Again , briefly describe
what each compeonent does,as you will be dealing with each in detail seperately.
ProxyRA enables organizations to extend their corporate resources to mobile and remote
endpoints. To streamline remote access, ProxyRA integrates sophisticated application connectivity
with endpoint security services. The primary components are :
ProxyRA Server
The ProxyRA Server runs on an expertly-hardened appliance that provides the gateway and
management functions for all ProxyRA services. The components of the ProxyRA gateway are
secure reverse proxy and secure SOCKS proxy, the details of which are dealt with in the
following slide.
ProxyRA Manager
Provides shared management services for the entire ProxyRA appliance. The ProxyRA
Manager, a Web-based management console, allows administrators to securely manage
ProxyRA from any computer with a Web browser. Taking advantage of an intuitive design,
the ProxyRA Manager makes configuration and policy management easy.
ProxyRA Connector
The ProxyRA Connector is downloaded on demand from the gateway to the client computer.
By transparently inserting itself at layer 5 of the Open Systems Interconnection (OSI) model,
and then intercepting system calls for network resources and redirecting them to the gateway,
the Connector provides connectivity and security enforcement during the VPN session. No
administrative access or reboot is required to utilize the Connector. When the session is
terminated, no VPN software remains on the client machine.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Proxy RA Server
6OLGH5$6HUYHU
Instructors Note: What comprises the ProxyRA Server is described in Slide 27-3.The
ProxyRA Server has two main components secure reverse proxy and a secure SOCKS
proxy. Point out that the above combination is required to process authentication and access
requests. Briefly tell the class that the ProxyRA Gateway can be safely positioned in or out of
the DMZ.
The ProxyRA gateway provides the SSL, SOCKS (Secure SOCKS Proxy), and HTTP reverse proxy
(Secure Reverse Proxy) functions of the gateway. It is the conduit through which the ProxyRA
solution processes information, authentication, and access requests. Taking advantage of the
hardened appliance, the gateway can be safely positioned in or out of the DMZ. The gateway also
serves as the repository for the login and Connector rulebases, information control settings, host
integrity checks, and the Connector software. The two major components of the ProxyRA gateway
are :
Secure Reverse Proxy
The secure reverse proxy handles all HTTP and HTTPS traffic, including file share and nonConnector or portal traffic. Since HTTPS Reverse Proxy VPNs use pre-existing browsers to
establish connectivity, they require no additional client software to secure Web-based
applications and simple file shares. If Web applications or simple file shares are all that is
necessary, this model applies well to unmanaged devices since browsers are pre-installed on
virtually all remote devices.The HTTPS reverse proxy architecture works well when
connectivity requirements are limited to Web applications and endpoint security is not a
concern.
Secure SOCKS Proxy
The secure SOCKS proxy handles traffic including all Connector traffic. SSL connectivity
provides authentication and encryption to ensure the confidentiality of data in transit.
ProxyRAs SSL connectivity takes advantage of the ProxyRA Connector to support virtually
any enterprise application in its native format via a single, user transparent access mode.
Users may access applications from a standard portal interface or directly from their desktop
enabling an in office user experience.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The SOCKS proxy helps prevent the accidental leakage or intentional theft of confidential
application data by controlling what the user can do with the data once it arrives on the
endpoint.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Proxy RA Manager
System Health dashboard view

System resources
License utilization
Proxy status
Context-sensitive help
Object-oriented Web UI
Quick-launch for common tasks
6OLGH5$0DQDJHU
Instructors Note: Make sure that the class understands that the ProxyRA Manager is a GUI
that helps you to securely manage the Blue Coat ProxyRA from a Web browser.
The ProxyRA Manager, a Web-based management console, allows administrators to securely
manage ProxyRA from any computer with a Web browser. Taking advantage of an intuitive
design, the ProxyRA Manager makes configuration and policy management easy.
The RA appliance provides shared management functions for all RA services. These functions
include authentication, on demand deployment of the ProxyRA Connector and services, access
policy enforcement (authentication, access control, etc) and remote access connection termination
proxy. Management functions include policy definition and distribution, monitoring, alerting, and
logging. ProxyRAs management capabilities are shared across all ProxyRA services eliminating
the need for redundant consoles.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Proxy RA Connector
6OLGH5$&RQQHFWRU
Instructors Note: In this slide, make sure you discuss that the ProxyRA Connector is an .exe
file that lodges itself in the Layer 5 of the OSI model, when installed. Go in detail on the
various advantages and features of the ProxyRA Connector.
At the heart of ProxyRA is Blue Coats patent-pending session-layer ProxyRA Connector. The
ProxyRA Connector is a lightweight binary executable that downloads upon user login and
inserts itself into the remote client network stack at the session layer (layer 5) of the OSI model.
Operating at the session layer, the Connector intercepts system calls passing between higher level
applications and lower level operating system (OS) facilities. Intercepted system calls are then
handled according to a centrally defined policy. For example, if remote access services are required
by a Microsoft Exchange client, then Exchange network calls are intercepted and redirected to the
RA appliance. There are three technical advantages to implementing network security and
connectivity at the session layer.
Application Independence At layer 5, the Connector operates below remote client

applications with inline access to system calls originating from any application. This
independent access to system calls enables the ProxyRA Connector, and by extension all of the
ProxyRA services, to interact uniformly with any application without requiring special access
modes (such as network extenders and port forwarding clients). In short, a single access mode
supports all applications uniformly.
Operating System Independence At the session layer, the ProxyRA Connector operates
above the remote client OS kernel. Therefore, it can be delivered to clients on the fly without
thick client software installation, local Admin rights, changes to OS settings, or reboots. It
achieves the operational ideal of an on demand deployment. In other words, all remote
access and endpoint security capabilities can be deployed instantly without the cost of
touching desktops for any reason.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Extensibility ProxyRAs ability to manipulate system calls can be leveraged beyond the
redirection of network requests for remote access purposes. It also makes the Connector an
ideal platform for supporting any number of integrated endpoint security and performance
services. For example, ProxyRAs Information Controls service can intercept file save,
clipboard, print and print screen operations to prevent intentional data theft or accidental data
leakage. Additionally, ProxyRA Connector becomes the platform by which other services,
such as application acceleration, can be delivered.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
How it works ?
6OLGH+RZGRHV5$ZRUN"
Instructors Note: Use the above flowchart to disuss how the Blue Coat ProxyRA works
when installed. Highlight how the Blue Coat ProxyRA is an excellent choice for implementing
remote access solution ,as it does not leave behind any temporary files after the connection is
disconnected.
The architecture of theProxyRA solution provides a great deal of flexibility while retaining the
minimal impact of a clientless solution. The above flowchart explains the connection process and
how the individual components work together:
1.
The user establishes a standard HTTPS secure browser connection to the gateway.
2.
The gateway checks for and blocks prohibited software (that is, malware), then challenges the
user for a user name, password, and, if necessary, an authentication domain.
3.
Assuming the user submits the correct credentials and no further information is required by
the authenticating server, the gateway attempts to match the URL used to access the gateway,
group membership, and source address to a login rule.
4.
If the connecting user can download and run ActiveX controls or Java applets, the gateway
downloads the following components to the connecting computer: Binaries necessary for the
Connector, Customizable favoritesWeb links and file shares specified in the login rule, and
Endpoint security settings.
5.
At this point the ProxyRA Connector is active and ready to implement policies defined by the
administrator.
6.
The ProxyRA Connector then creates a SOCKS SSL connection to the gateway and reports the
results of any specified host integrity checkslimiting resource connectivity as appropriate.
From this point on, Connector checks all running applications against your Connector rules,
including validating applications against a cryptographic checksum, and provides this
information to the gateway. The gateway allows only specifically-permitted applications to
communicate with your corporate resources.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
7.
If the connecting user cannot initiate the ProxyRA Connector or is not running a supported
operating system, the user can take advantage of the secure reverse proxy. Individuals using
the secure reverse proxy can access only the corporate intranet Web sites and file shares
defined in the first matching login rule.
8.
When a connected user wants to end the session, the user simply clicks the Connector icon in
the system tray and, from the pop-up menu, clicks Logout. If Information Controls are
enabled, the Connector deletes all temporary files created during the session and then closes
the secure VPN tunnel. If connected using the Secure Reverse Proxy, the user simply clicks
Logout in the portal, closing the secure VPN tunnel.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Proxy RA Requirements
RA Manager
IE 6.0 or higher , Mozilla Firefox 1.0 or higher
RA Connector
Windows 2000 SP4 , XP SP1 , Vista or higher

Mac OS X 10.4
IE 6 .0 or higher , Mozilla Firefox 1.0 or higher
Firewall and AV for RA Connector
Must permit BlueCoat RAEnforcer.exe and BlueCoat

RAEnabler.exe
6OLGH6RIWZDUHUHTXLUHPHQWV
Instructors Note: Use this slide to go over the basic installation requirements for
implementing Blue Coat ProxyRA in your enterprise.
After configuring your ProxyRA gateway , you must further configure the gateway using the
ProxyRA Manager. The following Web browsers have been tested with Blue Coat RA Manager:
Microsoft Internet Explorer version 6 or later, including version 7
Mozilla Firefox version 1.0 and later, including version 2.
The ProxyRA Connector requires one of the following operating systems:
Windows 2000 SP4 or later
Windows XP SP1 or later
Windows Vista (any marketed version except Windows Vista Starter Edition)
Note:
Note: The ProxyRA Connector does not require administrator privileges on the
connecting computer.
The following executables are Blue Coat products and should be allowed through personal
firewalls and permitted to run by anti-virus products.
BlueCoatRAEnforcer.exe
BlueCoatAXEnabler.exe
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Available Configurations
6OLGH5$&RQILJXUDWLRQV
Instructors Note: The above slide gives you an idea about the various range of hardware
configurations available for Blue Coat ProxyRA. Point out to the class that one has to
diligently decide which configuration suits best, is always based on individual requirements.
In order for the ProxyRA to efficiently secure, manage, and enhance your network, you need to
select the model of the appliance that best fits your environment. When choosing a device, the
number of users and bandwidth requirements are the most important considerations. However,
you also need to consider the number and types of policies that you need to implement.
As shown in the above slide, the ProxyRA appliance is available in a range of models, each
optimized for a particular use:
ProxyRA 510 : Single CPU, 80GB SATA hardrive, and 1GB of memory, provides remote access
to 50 concurrent users.
ProxyRA 810-A : Single CPU, 73GB SCSI hard rive, and 2GB of memory and supports 50 to
100 concurrent users.
ProxyRA 810-B : Dual CPUs, two dual-redundant 73GB SCSI hard rives (mirrored, 73GB
usable), and 3GB of memory. Designed for enterprises and large branch offices.
ProxyRA8100: Four processor cores, two dual-redundant 73GB SCSI hard rives (mirrored,
73GB usable), two dual-redundant power supplies, and 4GB of memory.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Proxy RA Deployment
6OLGH5$'HSOR\PHQW
Instructors Note: Blue Coat ProxyRA appliances simplify setting up and maintaining SSL
VPNs. Emphasize that RA appliances are especially useful for organizations that must extend
access to unmanaged endpoints computers over which they have no control. The above
slide details how the Blue Coat ProxyRA can be deployed under two different situations.
In this slide you see how the some organizations can deploy the ProxyRA differently in separate
locations. Organizations can combine a variety of deployments in their different offices. The above
slide shows two different deployments possibilities.
Users could be the organizations employees traveling or working at home who need to access
e-mail and important applications, or business partners connecting from locked-down systems.
1.
A user accesses the ProxyRA SSL VPN by launching a browser, navigating to a portal, and
logging on.
2.
The ProxyRA scans the client for suspicious processes, performs a host integrity check to
ensure that the endpoint is secure, and suppresses any spyware that may be on the computer.
3.
The user is authenticated and can launch applications from the desktop, a quick-launch menu,
or the VPN portal. During the session, all information including e-mail attachments is
protected, and the browsers cache and temp files are encrypted.
When the user logs off or the session expires, the ProxyRA appliance shreds the session history,
browser cache and temporary files and removes theProxyRA on-demand agent, leaving the
endpoint as it began
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Licensing Proxy RA
Obtaining a license
Regular License
Blue Coat RA High Availability License
Configuring the RA gateway
Viewing and updating the license
6OLGH/LFHQVLQJ
Instructors Note: This slide describes the various procedures involved in licensing your Blue
Coat ProxyRA.
Licensing your ProxyRA comprises of the following steps:
Obtaining a license
You need one of the following types of licenses:
Q Regular License : Also referred to as a permanent or perpetual license. A license that
enables you to use the gateway with a specified number of concurrent connections. If you
are setting up a High Availability system, you apply this license to the primary gateway.
Q Blue Coat RA High Availability (HA) : This requires two types of licenses:
A regular license, which you apply to the primary gateway
A secondary gateway license, which you apply only to the secondary gateway.
Configuring the ProxyRA gateway
The ProxyRA gateway can be configured either during the intial configuration process or after
the intial configuration process. When you initially configure the gateway, a 60-day trial
license is generated automatically, but it limits you to 25 concurrent users. The trial license
cannot be used for an HA system because it does not enable you to set up a secondary
gateway. You can, however, use the trial license to set up your primary gateway. To configure
your ProxyRA during intial configuration , you should have already obtained your license
key. The advantage of licensing the gateway at initial configuration is that you can configure a
High Availability secondary gateway if you have a secondary gateway license.
You can obtain a license for the ProxyRA using your WebPower login , the hardware serial
number, which is printed on a label affixed to the rear of the gateway, and is also displayed
when you initially log in to configure gateway and an activation code, which was e-mailed to
the registered owner of the gateway.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Note:
If you do not have a WebPower login, contact Blue Coat Customer Support with your
name, company name, email address, phone number, product model, and serial
number.
If you plan to configure the HA license after initially configuring the gateway, you have 60 days
after initial configuration to obtain a permanent or High Availability secondary gateway license
key.
Viewing and Updating your license
To update your license, make sure the license key is available, either as a file you can upload to
the gateway, or by copying it to the clipboard.
Important:
Do not change the license key in any way; doing so will cause the update to fail.
1.Open a Web browser and access the Blue Coat RA Manager by entering the following URL in
your browser https://ip-address/admin , where ip-address is the IP address on which you
configured the gateway.
2. In the left navigation bar, click Maintenance>License. License details display in the right pane.
3. Click Update License, to update your license.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Troubleshooting Proxy RA
Troubleshooting RA gateway
Enabling and downloading low level logs

Allowing use of ping and trace routes
Viewing and searching logs
Troubleshooting RA Connector
RA Connector diagnostic tool
Blue Coat RA status window
RA Connector status
6OLGH7URXEOHVKRRWLQJ
Instructors Note: Use this slide to decribe the various troubleshooting techniques that might
come in handy when you run into issues dealing with the Blue Coat ProxyRA.
The following procedures help you diagnose user connectivity failures based on rulebase
configuration. Completing the following tasks before contacting technical support will expedite
your support experience.
Troubleshooting ProxyRA gateway:
You can optionally enable low-level logging to obtain detailed information for the gateway
and components. Also, you can optionally download the log file to your local file system. You
also allow the use of ping and tracert (trace route) executables to help users troubleshoot
connectivity or configuration issues they encounter during a session.
Note:
If ping and tracert are enabled, all proxied destinations are pingable; however, if they
are disabled, no proxied destinations are pingable.
One other troubleshooting technique that can be used is searching the search logs based on a
number of criteria, including time period and log type. You can optionally refine your
search based on action taken, administrator, destination address or port, login rule, source
address, Windows login name, and so on. The ProxyRA gateway enables you to construct
custom queries using the Lucene query language, or you can construct your query using a
graphical interface.
Troubleshooting ProxyRA Connector :
Blue Coat provides the following ProxyRA Connector troubleshooting tools:
Q Connector diagnostic log, which users can start during a Connector download to allow
network administrators to assist them with Connector download problems. Log messages
can help you narrow the source of the problem to network connectivity, Connector
compatibility with the host, SOCKS channel establishment problems.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Q The Blue Coat ProxyRA Status window provides the following troubleshooting tools
Real-time Connector status and Event viewer. The event viewer displays information that
is useful to users, such as messages displayed to the user in Connector pop-up messages,
a list of successful connections, and messages related to connecting to file shares.
Q Troubleshooting and detailed logging, the troubleshooting log viewer enables you to view
the current log entries, open the folder containing the log, and to save the log after you log
out of the Connector session. The detailed log is the same except that it contains more
detailed information than the troubleshooting log, and you cannot view log messages.
The detailed log is readable only by Blue Coat technical support. If you encounter
problems you cannot solve with the troubleshooting log alone, you can request users
enable the detailed log and send that log to Blue Coat Support.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 Figure A-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 A-1: Simplified asymmetric cipher model
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 A-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 A-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.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Figure Figure A-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 A-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.
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.
1. Netscape developed SSL in 1994. The most recent release of SSL is v. 3.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 A-4: Sample SSL transaction
In Figure Figure A-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.
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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
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 the Circuit City 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 Circuit City
and not to a hacker who is trying to hijack your credit card information.
Figure A-5: The role of a Certification Authority
The Figure Figure A-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 it2; 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).
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.
2. It is actually the browser that trusts the CA and validates the certificate using the CA public key.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Table A-1: shows a sample menu with assigned values to each choice.
Table A-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, you need to 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.
Modular Mathematics
In a simple division between two numbers, for instance (14: 3)m you define:
14 as the dividend, 3 as the divisor, 4 as the quotient, and 2 as the remainder. So that 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
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The number 65 can be factored3 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.
3. 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.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Appendix B: Blue Coat Authentication and Authorization Agent
The Blue Coat SG runs a proprietary operating system called SGOS. SGOS is specifically
designed to handle secure proxy server tasks. It is important to understand that SGOS is not a
variation, modification, or a distant relative of, Windows OS, UNIX, or Linux and their many
variants.
The ProxySG authentication features enable administrators to create policies based on information
contained in several types of authentication databases. These depositories of users credentials can
be divided into two groups:
Open Standard (for example, LDAP)
Proprietary (for example, NTLM)
Some systems actually use a combination of the two types. For example, Microsoft Active
Directory, in general, can be interfaced using LDAP, NTLM, or Kerberos.
The ProxySG has the ability to interface directly with open standard databases, as the details of the
implementation are known.
Proprietary systems, in which the fine details of the protocol are hidden, expose an API1 that
enables third party software vendors to interface with the system.
Creating an agent, external to ProxySG, is the most elegant and efficient approach to supporting
any number of authentication systems. Using this technique, ProxySG can support a growing
number of databases, which currently include:
Windows NTLM
Windows Kerberos
SiteMinder
COREid
The agent must run on a system supported by the supplier of the API for a given authentication
database.
Theory of Operation
The agent used by ProxySG is called the Blue Coat Authentication and Authorization Agent
(BCAAA, pronounced BECK-ah). BCAAA is available for different operating systems:
BCAAA supports all three realm types on Windows 2000 and later.
BCAAA versions earlier than 4.2 are supported on Windows NT.
BCAAA supports SiteMinder realms on Solaris.
1. Application Programming Interface: a software package providing a level of abstraction between the application and the kernel designed to enable third party software vendors to access a selected set of functions.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The following functional diagram identifies the interactions between the ProxySG, the machine
running BCAAA, and the authentication database.
Figure B-1: Interactions between the ProxySG, the BCAAA server, and the authentication database.
At high level, the ProxySG authenticates a transaction in three steps:

1.
The ProxySG uses an established TCP connection to connect to the machine running BCAAA.
A new TCP connection to BCAAA is created only when the machine is started, policy is
changed, or the configuration is changed. That single connection is then used to authenticate
transactions.
2.
BCAAA communicates with the required API running on the machine (For example, BCAAA
on a Windows machine using NTLM v2 authentication).
3.
The API allows BCAAA to connect to the authentication database and verify the users
credentials.
BCAAA Components
Internally, BCAAA consists of four main elements. These elements are used to perform very
specific tasks and are invoked at different times during the three steps listed previously. The four
main elements are as follows:
Acceptor (Windows) or Dispatcher (Linux/UNIX)
Processor
Configuration file
Shared objects and DLLs
Acceptor
The acceptor is the actual main process running on the Windows machine where the agent was
installed; it is called bcaaa.exe and is visible in the Windows task manager. BCAAA registers itself
as a service and it is configured to start automatically.2
The main role of the acceptor is to listen for incoming connection requests from the ProxySG. The
acceptor, upon receiving a connection request, determines the appropriate protocol version for the
incoming BCAAA request and launches the appropriate processor to handle the requests coming
from the ProxySG.
2. The service, by default, runs as Local System Account. You can change it to run as an actual user; this can
be necessary in particular scenarios.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Dispatcher
The executable, which contains the dispatcher code for UNIX systems, is called bcaaa. It is
considerably different from the acceptor in the sense that it does not actively listen on a socket for
connections.
The dispatcher is invoked from the inetd or xinetdi superservers, so it only starts when a
connection is ready to be processed. Once it is executed, it determines the appropriate protocol
version used by the ProxySG and executes the appropriate processor program.
Processor
The processor is the component that actually handles the requests coming from the ProxySG.
There are different processors for the different versions of BCAAA. Therefore, each system needs
to have all the necessary versions of BCAAA installed.
While BCAAA versions are, in general, not backward compatible, more than one version can be
installed on the same machine. The acceptor will manage the different versions and initiate the
correct processor based on the information in the request coming from the ProxySG.
The processor is an actual executable file; the name of the file indicates the protocol version
supported. The file name is bcaaa-n.exe (Windows) or bcaaa-nn (UNIX). The values for n are:
99 for SGOS version 4.1.x or earlier
100 for SGOS version 4.2.x and higher
Note:
The BCAAA version for SGOS 4.2 is not compatible with any earlier release of SGOS.
As mentioned previously, you can have multiple processors installed on the same machine. This is
useful when you have a mixed environment in which some of the ProxySGs are on SGOS version
4.1.x and others are on version 4.2.x. or higher.
Configuration File
The configuration information for BCAAA is stored in the bcaaa.ini file. This file is automatically
generated during the installation process and generally does not need to be changed. The default
settings should work well in most deployments.
Table B-1: Configuration settings and definitions
Setting
Definition
Port Number
Port number to accept connections on.

This port number must be the same as the
port number set on the ProxySG in the
realm's configuration.
NumThreads
The number of threads to use;

recommended value is 2; if set to 0, only a
single thread is used. Note: Threads in
excess of 2 can consume large trunks of
memory and can cause lock contention
which would adversely affect
performance.
AuthBasicDefaultDomaing
Default domain name for Basic

Authentication (i.e. Netscape).
Logging level.
EventLogMask
-1 = No logging; 0 = minimum; 3=
maximum.
AllIpAddressesEnabled
Set AllowedIpAddressesEnabled=1 to
turn on source IP address checking for
connect requests (Windows only).
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Table B-1: Configuration settings and definitions (Continued)
[AllowedIpAddresses]
Source IP addresses that are allowed to

connect to the agent to the
AllowedIpAddresses section.
Whether to permit, require, or forbid SSL

connections from the ProxySG.
UseSSL
0 = permitted, 1 = required, 2 = forbidden.

Default=0.
CertificateSubject
Specify the subject (CN) in the certificate.
SaveGeneratedCertificate
Set to 1 if an automatically generated

certificate should be saved in the
certificate store. Default = 0.
VerifySG
Set to 1 to specify that the ProxySG must

provide a valid certificate in order to
connect. Default = 0.
CertificateFile
The name of the file that contains the

certificate.
PrivateKeyFile
The name of the file that contains the

unencrypted private key.
TrustedCertificateAuthoritiesFile
The name of the file that contains the list

of trusted certificate authorities.
WorkingDirectory
Specify the working directory. This is

mostly for UNIX systems, Windows will
work even if this is not set.
Even if the configuration file can easily be edited and the instructions inside the file are very
detailed, you should use extreme caution before changing any parameter.
Some users are tempted to change the number of threads because, for some applications, there is
a performance gain. However, in the case of BCAAA, additional threads can consume large
chunks and causes a lock contention.
Shared objects and DLL
BCAAA needs to interact with several APIssome of which are provided as a DLL.3 For
SiteMinder interaction, BCAAA uses the SiteMinder SmAgentAPI.dll. For interaction with
COREid, BCAAA uses the COREid obaccess.dll, mscvr70.dll and mscvi70.dll plus additional
configuration and other files found in the /oblix/ subdirectory in the BCAAA installation.
BCAAA Functionality
In essence, BCAAA provides a way for the ProxySG to invoke platform-resident authentication
and authorization services; the actual feature and functionality may depend on the services
offered by the host platform and authentication database.
The BCAAA functionality can be broken down in four major areas:
Authentication
Authorization data
3. A Dynamic Link Library (DLL) is a file that programs can load and execute dynamically.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Groups and users browsing
Statistics
Authentication
This functionality allows BCAAA to verify that the credentials a user has submitted to the
ProxySG are valid.
Authorization Data
BCAAA retrieves the group membership information for the user whose credentials are being
verified. If the ProxySG has group-based policies, any required authorization data (group
information) is included in the response from BCAAA to the ProxySG.
Group and User Browsing
BCAAA enables the Visual Policy Manager (VPM) to retrieve the entire structure for an
authentication database, and have granular visibility on the objects it contains (users and groups).
This functionality is only available for Integrated Windows Authentication (IWA) and LDAP
realms (LDAP does not require BCAAA).
Statistics
BCAAA reports status information, which is available under Management Console > Statistics >
Advanced > Authentication or directly from one of the following URLs:
https://[proxy IP address]:8082/UA/Lookup/by-each
This URL provides statistics on all realms.
https://[proxy IP address]:8082/UA/Lookup/ntlm-all
This URL provides detailed statistics on the agent realm credential cache.
Operational Details
The full communication between the BCAAA and the ProxySG consists of eight high-level steps.
These steps are detailed in the following diagram.
Figure B-2 : Communication between the BCAAA and the ProxySG
Step 1
The ProxySG initiates a TCP connection to the BCAAA; the ProxySG logs in by sending the
relevant information:
a.
Protocol version
b.
Realm type
c.
Communication security requirements
The ProxySG establishes a persistent connection with the BCAAA. The connection lasts until
either machine is rebooted, policy is changed, or the BCAAA service restarts.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Step 2
The BCAAA acceptor (or the dispatcher) starts the appropriate processor, which loads the correct
code for the target realm type. The processor initiates i threads to handle the requests, where i is
the configurable number of threads specified during installation and in the bcaaa.ini file.
Step 3
ProxySG sends any configure requests and notifies BCAAA of any groups of interest.
For IWA Realms, if one or more of the groups do not exist in the realm, then an error message is
generated in the application event log (this is not a fatal error).
Step 4
BCAAA responds to configuration and group requests.
Step 5
The ProxySG sends an authentication request to BCAAA.
Step 6
The processor handles the incoming request and issues the appropriate API calls for that request.
This results in the next available thread to be used to communicate with the authentication
database.
Step 7
The authentication database returns a response to the processor. This response can be the
authentication result (success or failure) or the request for additional authentication steps (for
example, NTLM).
Step 8
BCAAA returns the information received by the processor to the ProxySG. If the connection times
out, an authentication error is returned to the client.
If the ProxySG wants to update statistics, the sequence ends with ProxySG sending a report stats
request.
If policy or configuration changes occurred, the sequence ends with a logout request.
Supported Realms
The following realms are supported via BCAAA:
IWA (formerly NTLM)
SiteMinder (formerly Netegrity)
COREid (formerly Oblix)
Each realm that is supported via BCAAA requires two levels of configuration:
ProxySG configuration
Q Host name and port where BCAAA is available

Q Realm name
Q Credential cache control
Product configuration
Q Defines how BCAAA interacts with the authentication database
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Integrated Windows Authentication (IWA)
SGOS has supported NTML authentication with Active Directory (AD) since version ProxySG
3.2.x. NTLM realms have been renamed to IWA realms in ProxySG 4.2 to reflect the addition of
support for Kerberos authentication.
BCAAA must be running on a Windows machine (Windows 2000 or later). Windows makes the
decision as to whether authentication succeeds or fails and reports that to BCAAA. BCAAA does
not make the decision itself. Windows will accept domain credentials for any domain trusted by
the machine BCAAA is running on.
For each group of interest, BCAAA generates a Windows mutex with access restricted to that
group.4 After authentication, BCAAA impersonates the user, via a Windows API, and attempts to
operate on each mutex. If BCAAA can successfully operate on a mutex, the user is a member of the
specified group.
The IWA realm supports Basic authentication, NTLM authentication, and Kerberos
authentication. See the section IWA Authentication Details for more information about IWA.
SiteMinder
This authentication database is owned by CA (Computer Associates). BCAAA uses the

SiteMinder SDK version 2.2, which is shipped with the BCAAA code. The ProxySG sends the
configuration to BCAAA and specifies which SiteMinder policy servers to use. The authentication
is a four-step process:
1.
The ProxySG sends the authentication request to BCAAA.
2.
BCAAA makes the appropriate SDK calls to authenticate the user and obtain authorization
data.
3.
SiteMinder determines if the credential sent are valid and returns any authorization data.
4.
BCAAA returns the authentication response and any authorization data to the ProxySG.
COREid
This authentication database is owned by Oracle. BCAAA uses the API for COREid available in
the COREid SDK version 6.5. The ProxySG sends the configuration information to BCAAA. The
authentication is a four-step process:
1.
ProxySG sends the authentication request to BCAAA.
2.
BCAAA makes the appropriate SDK calls to authenticate the user and obtain authorization
data.
3.
COREid determines if the credential sent are valid and returns any authorization data.
4.
BCAAA returns the authentication response and any authorization data to the ProxySG.
Performance and Troubleshooting

Security
To protect the sensitive information exchanged between the ProxySG and BCAAA and to reduce
the risk that BCAAA would be used for brute force password attacks, there are two
communication security options available:
1.
Restrict the requests accepted by BCAAA to only the IP addresses of the ProxySGs. The
disadvantages of this option is that IP spoofing may defeat it and every time there is an IP
change, the BCAAA configuration needs to be updated.
4. A primitive object that provides mutual exclusion between threads.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
2.
Use SSL to setup encrypted communication between the ProxySG and BCAAA. This option
does require certificate setup but will give strong authentication of both endpoints.
Performance
The main factor in determining the response time of the authentication request is the BCAAA
machine capacity. The second most important factor is the capacity of the domain controllers.
The requests sent to the ProxySG are put on hold until the authentication information is returned
by BCAAA. If BCAAA is installed on a slow machine, the users will experience degraded
response time. It is strongly recommended that BCAAA be installed on a dedicated machine.
For NTLM and Kerberos, each connection requires authentication by BCAAA. If a browser does
not support persistent connections with the proxy, there is an authentication request for each
object that the client requests. Particularly in the case of NTLM authentication, which is a
three-step process, the load on BCAAA can be significant. To optimize performance, you have two
options:
Make sure that the browser supports persistent connections (HTTP/1.1) though the proxy (see
Internet Explorer setting below) and that the ProxySG is configured for persistent
connections.
Figure B-3 : Ensuring that the browser supports persistent connections
Reduce authentication load by using a surrogate credential:
Q Proxy-IP
Q Origin-IP-Redirect
Q Origin-Cookie-Redirect
Troubleshooting
BCAAA logs information to the Windows Application Event log. On UNIX machines, BCAAA log
information is in the syslog. The amount of information written in the logs is configured in the
bcaaa.ini, using the EventLogMask parameter. Use care when setting the value, as a higher
verbosity may flood the event log. The EventLogMask can have the following values:
-1 = Turn off logging completely
0 = Log default events (most of these events are errors)
1 = Log Authentication events (User and Group authentication failures); this is the default value
2 = Log Debug events
3 = Log Authentication and Debug events
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Some common problems encountered are:
If an attempt to start the BCAAA service is issued when BCAAA is already started, the
following error message displays:
The requested service has already been started.
If another application is using the same port number as the BCAAA service, the following
messages are displayed:
The BCAAA service could not be started.
A system error has occurred.
System error 10048 has occurred.
Only one usage of each socket address (protocol/network address/port) is normally permitted.
You can find a detailed list of event log messages for the BCAAA in the ProxySG (ProxySG)
Configuration and Management Guide.
IWA Authentication Details
As previously mentioned, the IWA realm supports three types of authentication: Basic, NTLM,
and Kerberos.
Basic Authentication
Basic authentication is by far the least secure option. The authentication credentials are
transmitted from the proxy to the BCAAA in plain text or base64 encoded, which is practically
plain text (this is an encoding schema, not an encryption algorithm). The advantage of basic
authentication is compatibility with browsers that do not understand the NTLM protocol. The
BCAAA calls the LogonUser API to pass the credential for authentication. This is a two-step
process, as shown in the following example.
NTLM Authentication
NTLM authentication is considerably more secure than Basic authentication. However, it does
require a compatible user agent.
The illustration below shows the steps of an NTLM authentication in an explicit proxy setup:
Figure B-4 : NTLM authentication in explicit proxy setup
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
1.
The ProxySG sends an HTTP 407 authentication challenge to the client with a NTLM
Proxy-Authenticate header.
2.
The client reissues the original request to the ProxySG with a Proxy-Authorization header and
the NTLM Type 1 message blob.
3.
The ProxySG passes the blob to BCAAA.
4.
BCAAA passes the blob to the Windows API AcceptSecurityContext.
5.
The Windows API decides if the blob is valid and if yes, replies that a further challenge is
needed and provides the NTLM Type 2 challenge message blob to return to client.
6.
BCAAA passes the NTLM Type 2 message blob to the ProxySG.
7.
The ProxySG sends an HTTP 407 challenge to the client with the Proxy-Authenticate header
and the NTLM Type 2 challenge message blob.
8.
The client computes the hash of the challenge using the users password and sends a request
to the ProxySG with an Authorization header containing the response NTLM Type 3 blob.
9.
The ProxySG passes the NTLM Type 3 blob to BCAAA.
10. BCAAA passes the blob to the Windows API AcceptSecurityContext.
11. The Windows API decides if the blob is valid and returns the value to BCAAA.
12. BCAAA then calls the Windows API QueryContextAttributes to determine the users name.
13. Windows returns the users name to BCAAA.
14. BCAAA returns whether the user was successfully authenticated by Windows, the users
name and any authorization data it also obtained to the ProxySG.
15. The ProxySG will allow or deny the users request based on the data returned from BCAAA
and the configured policy.
The communication between the ProxySG and the BCAAA is base64 encoded; however this is not
a security liability, as only the user name is visible, while the password is never transmitted.
Kerberos Authentication
Kerberos is the newest authentication protocol available for Windows. It requires:
Active Directory in native mode (Windows 2000 or higher on the desktops and the servers)
Transparent proxy mode (Internet Explorer does not support Kerberos in explicit proxy mode.)
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
The authentication in transparent mode uses either cookie or IP surrogate credentials. The client
receives an HTTP 401 authentication request from the ProxySG. This authentication appears from
a virtual URL, where the user request has been redirected.5 This process is described in Figure
Figure B-5:, beginning at the point where the ProxySG challenges the user agent for
authentication.
Figure B-5: Kerberos authentication
1.
The ProxySG sends an HTTP 401 response to the user agent (WWW-Authenticate) along with
the NEGOTIATE header. Basic (if configured in the realm) and NTLM headers are also
included, so that the browser has a choice.6
2.
The user agent decides to use Kerberos. It contacts the Key Distribution Center (KDC) and
obtains a Kerberos ticket for the requested URL.
3.
The user agent sends the response to the ProxySG and includes the Authorization header. This
header contains several bits of information, including the Kerberos ticket base64 encoded.
4.
The ProxySG passes the authentication information (namely the Kerberos ticket) to the
BCAAA.
5.
BCAAA uses the AcceptSecurityContext() API to authenticate the user.
6.
The authentication server responds with a success or failure.
7.
The BCAAA passes the result of the authentication to the ProxySG, which then sets a
surrogate credential as appropriate and replies to the client.
5. The details are not included as they are not relevant to the scope of this paper. See the ProxySG
(ProxySG) Configuration and Management Guide for information on authentication modes.
6. NTLM authentication cannot be disabled if Kerberos authentication is enabled in an IWA realm. Basic
authentication can be enabled or disabled.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

BCCPP Ebook

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BCCPP Ebook

Transféré par

Droits d'auteur :

Formats disponibles

Pr

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Blue Coat Systems Inc.

North America (USA) Toll Free: +1.866.302.2628 (866.30.BCOAT)

The Regents of the University of California. All rights reserved.

Copyright (c) 2003 Finjan Software, Inc. All rights reserved.

Copyright (c) 1996-2002 Greg Ferrar

ISODE 8.0 NOTICE

RSA Data Security, Inc. MD5 Message-Digest Algorithm

Copyright (c) 2003 Microsoft Corporation. All rights reserved.

The OpenLDAP Public License Version 2.7, 7 September 2001

Instructor Edition iii

Blue Coat Education and Training Services BCCPP Course v 3.0.3

- GMP is no longer used, and instead we call BN code from OpenSSL

- The make-ssh-known-hosts script is no longer included

- MD5 is now external, in the OpenSSL library

3) ssh-keygen was contributed by David Mazieres under a BSD-style license.

Optimised ANSI C code for the Rijndael cipher (now AES)

@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>

Third Party Copyright Notices

@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>

The Regents of the University of California. All rights reserved.

Copyright (c) 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Copyright (c) 1997-2001 University of Cambridge

Copyright (c) 1996-2003 Phaos Technology Corporation. All Rights Reserved.

Copyright (C) 1992-2001 by SNMP Research, Incorporated.

Third Party Copyright Notices

Restricted Rights Legend:

Copyright (c) 1999, 2000 Boris Fomitchev

Copyright (c) 1994 Hewlett-Packard Company

Copyright (c) 1996-1999 Silicon Graphics Computer Systems, Inc.

Copyright (c) 2003 Secure Computing Corporation. All rights reserved.

Copyright (c) 2003 SurfControl, Inc. All rights reserved.

Copyright (c) 2003 Symantec Corporation. All rights reserved.

Copyright (c) 1982, 1986, 1988, 1990, 1993, 1994, 1995

The Regents of the University of California. All rights reserved.

Copyright (c) 1989-2003 Trend Micro, Inc. All rights reserved.

Copyright (c) 2003 by the Open Source Initiative

Instructor Edition vii

Blue Coat Education and Training Services BCCPP Course v 3.0.3

viii Instructor Edition

Chapter 1: System Architecture .................................................................. 1

Chapter 3: Content Policy Language ........................................................ 39

Chapter 5: Managing Downloads and Apparent Data Types .................... 91

Chapter 7: HTTP Details ......................................................................... 113

Chapter 8: Using Authentication In Transparent Proxy Mode ................. 127

Chapter 9: Understanding Kerberos Authentication (Optional) ............... 143

Chapter 12: Windows SSO ..................................................................... 181

Chapter 14: Guest Authentication ........................................................... 209

Chapter 16: Bandwidth Management ..................................................... 239

Chapter 18: Forwarding .......................................................................... 273

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Chapter 20: Two-Way URL Rewrite ........................................................295

Chapter 21: Failover ................................................................................307

Chapter 23: Web Cache Communication Protocol (WCCP) ..................337

Chapter 25: ProxySG Security ................................................................361

Chapter 26: Introduction to Blue Coat Director ........................................365

Chapter 27: Introduction to Blue Coat ProxyRA ......................................375

Appendix: Understanding Digital Certificates ..........................................395

Estimated Lesson Time: ProxySG 45 minutes

Analyzes and processes policy

Blue Coat Education and Training Services BCCPP Course v 3.0.3