ProxySG

These release notes apply to Blue Coat machines running or upgrading to this release of the Port 80 Security Appliance (SGOS 2.1.11). Prior to starting the upgrade process, please review the Upgrade Instructions section.

Questions regarding this release can be emailed to support@bluecoat.com.

Terminology

· Port 80 Security Appliance can be referred to as Web Security Appliance or Appliance

· The Visual Policy Manager can be referred to as "VPM"

· The Blue Coat Content Policy Language can be referred to as "CPL"

· Access Control List can be referred to as "ACL"

Tech Briefs

Blue Coat has created a number of quick-start documents designed to help you get up and running quickly once you've installed the product. You can refer to the quick-start documents for topics such as content filtering, ICAP integration, and LDAP and NTLM integration, among others.

To view the documents, see http://bluecoat.com/resources/resourcedocs/techbriefs.html.

System Requirements

Hardware Requirements

Blue Coat 400, 5x5, 610, 611, 6x5, 6x6, 3000, 5000, 6000, and 800 platforms can be upgraded to this release of SGOS 2.1.11.

Software Requirements

You must be at version CacheOS 4.x or SGOS 2.1.x to upgrade directly. If you are upgrading from a previous CacheOS version, please refer to Upgrading_to_SGOS21.x.html.

In this release, SGOS is certified with the following third-party vendors' implementation of ICAP

· Symantec CarrierScan Scan Engine 3.0 with ICAP .95 (version 3.0.0.26)

· Symantec AntiVirus Scan Engine (SAVSE) 4.0 with ICAP 1.0 (version 4.0.4.46)

· TrendMicro Interscan WebProtect (ISWP) 1.0 with ICAP 1.0 (build_SOL_1151)

· TrendMicro ISWP 1.5 with ICAP 1.0 (response and request modification) (build_SOL_1266)

· WebWasher 4.4 with ICAP 1.0 (build 542)

· Finjan SurfinGate 7.0 (Malicious Mobile code and virus protection) (build 472)

For notes on these third-party vendors, see ICAP: Third Party Vendors.

Upgrade Instructions

A license key is required to download the Security Appliance software. When a valid license key is entered, an automated email response is generated and sent out. This email contains a valid URL that can be used to download SGOS 2.1.11. For more information or to download the software, go to the Security Appliance Home Page. If you need to purchase a license key or renew a support contract, contact your local reseller or email sales@bluecoat.com.

If you need to look up your license key or support contract, contact your local reseller or email support@bluecoat.com.

Blue Coat NTLM Authentication Agent

For this release, if you use NTLM, you must upgrade to the latest version of the Blue Coat NTLM Authentication Agent (CAASNT). CAASNT is distributed as a zip archive, to be installed with each Security Appliance software version.

To download the zip archive containing the Blue Coat NTLM agent for this release, click here.

Installation instructions for the Blue Coat NTLM Authentication Agent Service are in Chapter 8 of the Blue Coat Port 80 Security Appliance Configuration and Management Guide.

Upgrading from SGOS 2.1.x

· Upon upgrading to SGOS 2.1.11, the VPM might fail to launch if the browser was opened using a previous version of SGOS 2.1. If the browser is closed and a new browser instance is opened, VPM will load correctly.

· The default access log file name now begins with SG. Previously, it began with CF. This might affect any automated procedures dealing with access logging.

· When upgrading from SGOS 2.1.05, you might encounter increased refresh activity as the probabilistic refresh re-learns the relative popularity of objects in cache. To control the amount of actual refresh bandwidth used, set a refresh limit to control refresh activity in the short term (over a period of several days).

· Anyone using ICAP patience pages should increase both the system's maximum cacheable size (Management Console: Management>Caching>Policies) and the FTP maximum object size (Management Console: Management>Caching>FTP cache) to 1GB in SGOS 2.1.11. (It is not required for other users, but it might help performance in some situations.)

· When upgrading from SGOS 2.1.07 (and earlier), take note that the "time-of-day" parameter for automatic download of the Smartfilter database is now in UTC time as oppose to local time.

Upgrading from CacheOS 4.x

· Note that when you first upgrade from CacheOS 4.x to SGOS 2.1.x, a one-time migration of configuration settings occurs. This migration will take the configuration from the 4.x system and use it as the basis for the SGOS 2.1.x system configuration. All necessary conversions are handled automatically. After the initial upgrade to the Port 80 Security Appliance, the two system configurations are maintained independently. If you decide to downgrade, none of the configuration updates that you made are migrated back to your 4.x configuration; the 4.x configuration will be just as it was when the 4.x system was last run.

· If you use SmartFilter onbox content filtering and you want to take advantage of the latest version 3.x SmartFilter database, change the network path to ftp.smartfilter.com/pub/sfv3/lists/ and pick up the sfcontrol list. Note: SmartFilter v2 cannot be used with SGOS 2.x.

· Direct/Deny settings are not migrated to SGOS when upgrading from CacheOS. Upon upgrade, these settings must be re-entered in the advanced forwarding configuration.

· If you used advanced forwarding in CacheOS, the rules might not be upgraded correctly when you upgrade to 2.1.11.

· The statistics reported by "Cache Available" in the pie chart located at

Statistics > Resources > Disk Use

in the Management Console GUI no longer count the number of bytes available on the disk and instead count the number of objects on the disk. Since there is a limit to the number of objects that can be stored on disk, which if calculated in bytes would be much less than the total disk space, measuring disk usage by counting objects gives a much more accurate reflection of resources used/available.

Upgrading from Versions Earlier than CacheOS 4.0

Please contact support@bluecoat.com for the appropriate upgrade path when upgrading from releases prior to CacheOS CA 4.0.

New Features

New Version Numbering Scheme

Starting with release SG 2.1.8, Blue Coat Systems is using a new four digit numbering scheme for its software releases. The purpose of the 4-digit version number is to provide a very clear numerical versioning scheme for releases to the customer that describes when new features are introduced and when patch fixes are applied

The release numbering format is: a.b.c.d build e, where:

a	is the major release number and is incremented when a release has extensive new functionality;
b	is the minor release number and is incremented when a release has significant new features;
c	is the dot release number and is incremented when a release has a collection of bug fixes or unintrusive features;
d	is the patch release number and is incremented when a interim bug fix is provided to a restricted set of users;
e	is the internal build number primarily of interest to Blue Coat. It does not imply anything about the release contents.

ICAP HTTPS Support

Blue Coat now supports HTTPS/connect redirection to an ICAP server. This allows content-filtering ICAP servers to block HTTPS sites.

ICAP Customizable Patience Pages

You can customize the patience page just as you customize any other message page. That is, you download a copy of the page, customize it, and upload it back onto the Security Appliance.

Three new substitutions can be used on the Patience Page:

$(PATIENCE:Progress)
$(PATIENCE:Elasped-Time)
$(PATIENCE:Url)

Note: Do not modify the refresh after five seconds (line 1855) or the $(PATIENCE:Javascript) substitution. Modification will likely result in the Patience Page no longer working.

For information on working with Message Pages, including Patience Pages, refer to Chapter 17, "Using Customized Message Pages," in the Configuration and Management Guide.

Enhancements in this Version

Resolved Issues

SG 2.1.11.5 (build 22674)

· Support new 36GB drive model (SEAGATE ST336807LC 10K.7) for SG645, SG6045 and SG800 platforms.

SG 2.1.11.3 (build 21824)

· Support new 73GB drive model (SEAGATE ST373207LC 10K.7) for SG800 platform.

· Fix for bug 45565 - Divide by zero(HWE=0x0) in " HTTP SW " in "ce_admin.dll" at .text+0x10843".

SG 2.1.11. (build 21545)

· Update VPM Certificate.

· Resolve SG3.x downgrade issue on SG800.

All resolved Issues in SGOS 2.1.11 are described in this table.

SG 2.1.10.3 (build 21093)

· Apply fixes for TCP vulnerability CAN-2004-0230.

SG 2.1.10.1 (build 20894)

· Apply fixes for OpenSSL vulnerability CAN-2004-0079.

· Apply fixes for OpenSSL vulnerability CAN-2004-0081.

All resolved Issues in SGOS 2.1.10 are described in this table.

Doc Errata

· Access Logging: The "log" option was ambiguous, not clearly indicating which request URL was being logged. This has been changed. The definition for the log option now says: Request URL used to address the cache used when generating log messages.

· CPL: Appendix B, Well-Known HTTP Headers, the WWW-Authenticate header is listed as being appendable. It is not.

· CMG: Chapter 5, Defining Advanced Forwarding Rules, includes a statement: Instead of forwarding everything to an HTTP host, Blue Coat recommends specifying Advanced Forwarding rules to forward only HTTP traffic. The Security Appliance cannot convert HTTPS traffic to HTTP through Advanced Forwarding when the CONNECT method is used. The HTTP host will not understand the CONNECT method, and the transaction fails. <Errata> These statements are inaccurate and should not be followed <Errata/>

· CMG: Chapter 8, Authentication and Authorization, mistakenly indicates that LDAP cache credentials are stored for 15 minutes by default. Cache credential values are actually seconds, and the default is 900 seconds (15 minutes). This has been corrected in the text and the screen shot.

· CMG: Chapter 15, Streaming features support: The existing document indicates that "advanced streaming features" are not supported by a non-Windows Media server, but it should indicate that no streaming features are supported in those circumstances (unless the streaming content is pre-populated from an HTTP server).

· CMG: Secure Connection to the Management Console with HTTPS: The encryption/decryption process relies on the use of two related but different keys, called a keypair. One key is called the private key and one is called the public key. The creator of encrypted data generates a public/private keypair, and uses the public key to encrypt data. The receiver of the encrypted data has the matching private key. Because the keypair is matched, the private key decrypts data only encrypted with the matching public key. In this case, because the public key matches the private key, the recipient can decrypt the data.

The creator of encrypted information can be either at the client or server side of the network. Because the two entities have each other's public key, they can carry on a two-way secure conversation. The SSL protocol builds on keypairs and certificates to create an efficient yet secure connection between compatible peers.

A keyring, in SGOS usage, is a collection of information that holds a public/private keypair and a signed certificate for the origin server being accelerated. SGOS allows for the creation of multiple keyrings, each with a single keypair and certificate for each origin server being accelerated.

· CMG: CLI is limited to 16 telnet sessions and one serial console session.

· CPL: The example for the cache( ) property inadvertently used <Proxy> layers. The cache( ) property is only valid in <Cache> layers.

· CMG: the instructions for adjusting the HTTP receive timeout setting in the CLI only discuss adjusting "server" settings, and that is done in the Dynamic Bypass section. The CLI command also adjusts "client" and "refresh" receive timeout settings, though these are not related to Dynamic Bypass.

· CMG: The CMG does not contain advanced forwarding directives, host affinity directives, or load balancing directives. (B#27804)

· CMG: Chapter 12: ICAP does not contain a note indicating HTTP Progressive downloads/streams cannot be scanned. See ICAP Limitations below. (B#27374)

· CMG: Chapter 9, RADIUS service types: The documentation did not indicate the values for the [alternate-server | primary-server] service-type type. The values for type are:

1. Login

2. Framed

3. Callback Login

4. Callback Framed

5. Outbound

6. Administrative

7. NAS Prompt

8. Authenticate Only

9. Callback NAS Prompt

10. Call Check

11. Callback Administrative

Note that if the user record contains Check-list ServiceType attributes, then at least one of the ServiceType values must match the service-type of the RADIUS server as configured on the ProxySG. (B#43680).

Known Issues

Known issues in SGOS 2.1.11 are discussed in this table.

· No password changes are propagated from 2.1.11 to 2.1.05 and earlier.

· If you downgrade from 2.1.11 to 2.1.05 or earlier, change passwords and then upgrade to 2.1.11 again, any changes to passwords that already existed in 2.1.11 will not be propagated back to 2.1.11.

· If a 2.1.11 policy references the new ICAP properties or the notify_email action and you downgrade to 2.1.05 or earlier, your policy will not load. SGOS 2.1.05 does not understand the new tags and generates errors when compiling the policy. As a consequence, your policy in 2.1.05 is empty. You must fix the policy in 2.1.11 to avoid this situation, or use inline CLI commands to place the policy in 2.1.11.

· The ProxySG does not return a patience page if the requested object does not contain HTTP headers. The workaround is to modify the requested object to contain the HTTP version line (such as "HTTP/1.0 200 OK").

· URL rewrite on upstream proxy: The host alias setting with a rule pointing to itself does not work in hierarchy due to CPL rules. (B#17479)

· Substitution variables ('user) and ('user.name) do not work when used as the replacement URL part of URL rewrite. This is because the rewrite is occurring before the authentication is complete and significantly before the username is available. Possible workarounds are to rewrite the policy file to say:

  <proxy>
     authenticate(ntlm)
  <proxy>
     user=!nobody action.write_substitution(yes)

  define action write_substitution
   rewrite(url,"^http://www\.yahoo\.com/rewrite\.txt","http://example.bluecoat.com/'(user.name)")
  end

<proxy>
url=http://example.com/rewrite.html bypass_cache(yes) action.rewrite_srvr(yes)

define action rewrite_srvr
rewrite(url, "^http://example.com/(.*)", "^http://example.com/'(user)/'(1)", server)
end

· If two percentage sign characters (%%) exist sequentially anywhere in the string of the <filename> for the filename-prefix configuration parameter,

(config)archive-configuration filename-prefix <filename>

the ProxySG will page fault upon execution of "upload configuration" CLI command.

· When enabling automatic download of the Smartfilter database, the "time-of-day" parameter is now in UTC time as oppose to local time. See "Upgrading from SGOS 2.1.x" section for more details.

· The policy redirect( ) action is executed after response from origin server:

If policy similar to the following example policy is installed,

define action pleaseRedirectToBlueCoatHomePage
redirect(301,"", "http://www.bluecoat.com")
end action pleaseRedirectToBlueCoatHomePage

<proxy>
url_domain = www.bluecoatsystems.com action.pleaseRedirectToBlueCoatHomePage(yes)

The ProxySG will perform a DNS lookup and proceed with the server side request to origin server even though the intent is to execute the redirection immediately upon receipt of the client request. This is a limitation in SG2 policy framework but has been fixed in SG3. A workaround can be to use the replace( ) policy action - please see SG2 CPL policy guide for more details.

Limitations

Authentication

· The CPL has_attribute.name= condition should not be used if the LDAP realm is a Novell Directory Serverbefore v8.6.2. Users (both admin and proxy) will appear to have the attribute even if they do not. (B#18504)

· LDAP Group and Attribute authorization does not work with Netscape/iPlanet Directory Server v5.0. It does work correctly for versions v4.1 and v5.1. (B#19468)

· Cookie-based transparent authentication uses a mechanism that adorns the URL with a query string representing an authentication token. If JavaScript inside the requested object references the object's URL (the document.location.href member), the Blue Coat authentication token can appear in the URL constructed by the JavaScript. This can cause a variety of behaviors, depending on the function of the JavaScript. (B#13656, B#19517)

· An authenticate-401 challenge does not occur if the HTTP method is CONNECT. In this case, it will always challenge with an authenticate-407. (B#19310)

· If the connection between a Security Appliance and the NTLM agent (CAASNT) fails, you might see error code 1704 or 1712. These error codes display when the read attempt on the CAASNT request protocol header failed with no bytes read. (B#23330)

Browser

· HTTPS proxy authentication: With NTLM proxy authentication enabled, Internet Explorer (IE) 6 only does first-time sign-on (sending the credential of the local machine's current user). Any credential entered through the authentication message box (the user entered) is not sent. With IE 5 and Netscape, HTTPS proxy authentication works correctly. (B#18434)

· A known issue with the IE browser may cause an unexpected re-authentication pop-up request on the client when configured for NTLM proxy auth. If you have this problem, you might see error codes 1304, 1305, or 1306. The issue and a workaround is described here. (B#20759, 23330)

· If Show friendly http errors is configured on IE 6 and you are using TrendMicro, the browser will not display the correct error message if the message is less than 256 bytes. To view the correct message, verify Show friendly http errors is not selected. (B#22533)

· The Management Console sometimes does not display properly because of a bug in IE 6.0.2800.1106 that causes IE to be unable to find the spacer.gif file. If the Management Console does not display properly, try to re-launch the Management Console, reboot the Appliance, or use a different browser. (B#22723)

· A known issue with specific combinations of Windows operating systems and the IE browser prevent changes from being saved in the Management Console if you switch to a different applet before applying the changes. In this situation, the "Unsaved changes" dialog box shows-up incompletely and the browser must be closed and relaunched. The workaround is to save your changes before switching applets. (B#42153)

This behavior is seen with the following combinations of OS and browser:
WIN XP SP4 - IE (6.0.2800) with SP 1 - jre 1.4.1_07
WINNT SP2 - IE (6.0.2800) with SP 1 - jre 1.3.1_04
WIN2k server SP4 - IE (6.0.2800) with SP 1 - jre 1.4.1_07
WIN2k professional SP4 - IE (6.0.2800) with SP 1 - jre 1.3.1_04
WIN2k professional SP4 - IE (6.0.2800) with SP 1 - jre 1.4.1_03

Content Filtering

If you use SmartFilter onbox content filtering on CacheOS 4.x and have upgraded to SGOS 2.1.x you are required to re-download the SmartFilter database as SGOS 2.1.x makes use of SmartFilter v3 and not the older SmartFilter v2, which is supported on CacheOS 4.x. Under rare circumstances the download of the database might fail if HTTP is used to download the database. If this occurs the following procedure has been known to alleviate from the problem:

In the Filtering section and Download tab of the Management Console GUI:

· Erase whatever text is in the Content filter field and click Apply.

· Attempt to download the database by clicking Download filters (this will fail)

· Enter the text “sfcontrol” in the Content filter field and click Apply.

· Attempt to download the database by clicking Download filters (this will now succeed)

Hardware

· SGOS 2.1.01 r17983 and 2.1.02 r18052 should not be used in an IP-spoofing environment. If you use IP-spoofing, you should upgrade.

· Changing a gigabit Ethernet interface between half and full duplex can take a few seconds. When this change is made from the Management Console, that status line flashes Unsaved changes until the Apply button is clicked. Once applied, the status line usually reports Configuration successfully updated, however in some instances, the status message may erroneously report Unable to update configuration in red text. The configuration has actually updated successfully, but is erroneously reported. Re-clicking Apply displays the correct message.

· If you use the Security Appliance front panel manager to set initial network connections, be aware that the front panel sets the DNS address to the network address if you do not specify otherwise. If you do use the front panel, either enter the correct DNS address or reset the DNS field to none. The serial console does not set defaults for the DNS address. (B#22958)

HTTP

· The privileged command display, which displays the source code (such as HTML or Javascript) used to build the named URL, only handles HTTP. It cannot handle HTTPS.

Note: The display command is deprecated and its HTTP protocol compliance is suspect. Blue Coat recommends using PCAP to test http connectivity.

ICAP

· ICAP service protocol versions and methods cannot be modified while the service is referenced by policy or an ICAP cluster. (B#23419)

· Patience pages display regardless of any pop-up blocking policy that is in effect.

· If problems occur with the Patience Page, you can configure an ICAP service without a Patience Page by using the appropriate CPL triggers.

Potential problems include:

q When the browser is configured to download FTP URLS through an HTTP proxy and the Patience Page is enabled on the Security Appliance, right-clicking the link for download will lead to the HTML page showing the Patience Page itself to be saved instead of the original object.

You must left-click the link to download FTP URLs.

q You might experience problems with download agents and virus scanning due to potentially long scan times. If the agents do not get a response before their timeout time, they will attempt to reconnect and re-download the request file and will eventually stop trying. To avoid this, Blue Coat recommends you significantly increase the timeout values for these agents (scans on loaded ICAP servers can take minutes).

q      The response header Accept-Ranges, when a Patience Page is being used, causes Microsoft Internet Explorer to display an error because IE was expecting a PDF file and not a Patience Page. If this problem occurs, you can change your policy to:

<Cache>
   response.icap_service(name)

<proxy>
action.del_res_header(yes)

define_actions
     define action del_res_header
       delete(response_header.Accept-Ranges)
     end action del_res_header

· Currently, it is not possible to perform ICAP scanning of HTTP progressive download and HTTP streaming objects because of the unknown nature of their size (potentially infinite for live radio/TV streams). The following is an example policy that can be used to bypass ICAP scanning of such objects:

<Cache>
url_scheme=http request_header.User-Agent="RealPlayer G2" response.icap_service(no)
url_scheme=http request_header.User-Agent="(RMA)" response.icap_service(no)
url_scheme=http request_header.User-Agent="(Winamp)" response.icap_service(no)
url_scheme=http request_header.User-Agent="(NSPlayer)" response.icap_service(no)
url_scheme=http request_header.User-Agent="(Windows-Media-Player)" response.icap_service(no)
url_scheme=http request_header.User-Agent="QuickTime" response.icap_service(no)
url_scheme=http request_header.User-Agent="(RealMedia Player)" response.icap_service(no)
response.icap_service(name)

This policy depends on detection of characteristics most identifiable of an HTTP progressive download/stream. One of these characteristics is the User-Agent. The above is an example policy and does not contain every User-Agent that is capable of initiating a HTTP progressive download/streaming transaction.

ICAP: Third-Party Vendors

· ICAP Server Vendors: In configuring the Security Appliance to work with an ICAP server, ensure that the number of connections on the Security Appliance does not exceed the number of scan threads on the ICAP server. Take into consideration all of the ICAP services configured across all of the Security Appliances that are connecting to the ICAP server. Note that sense-settings that retrieve information from the ICAP server will not account for this-- it will only return the number of scan threads on the ICAP server.

· Symantec: Symantec's use of the Nagle algorithm on v3 and v4 of their ICAP servers can result in virus scanning performance degradation on heavily loaded systems. This appears more likely to occur using ICAP 1.0 and SAVSE 4.0 due to the expanded use of 204 responses.

The cache_block size for request and response HTTP headers in ICAP can be no more than 8k. Some headers produced by Symantec are greater than 9k. You can turn off headers in Symantec SAVSE 4.0.3.41 by setting SendExtendedICAPViolations=0 in the configuration.

· TrendMicro: Blue Coat supports the X-Client-IP and X-Server-IP headers for Trend ICAP server. When enabled, each request to the ICAP server contains additional headers to inform the ICAP server of the relevant server/client address. Each header can be enabled/disabled from the Management Console or the CLI.

TrendMicro does not support REQMOD of connect methods.

· Finjan: When using content filtering, the proper message page is not always returned from the ICAP server and therefore cannot be displayed to the client. Instead, the client receives a blank page.

· WebWasher: Response to a POST that was sent for REQ-MOD scanning is corrupted. (B#28652)

Policy Framework

Before using Content Policy Language (CPL) to create policies, review the Content Policy Language Guide and Reference. You might find CPL to be very complex if you are not familiar with other programming languages. Current limitations include:

· If there is an active content removal policy that removes Java applets on the Security Appliance, then it will also remove all the Management Console applets, causing the Management Console to be unavailable.

· Policy should not be edited in both VPM and the CLI at the same time. There is no locking mechanism to dynamically update and save the policy between the VPM and CLI if both are used simultaneously.

· Leaking Cookies in Clustering Scenarios: Cookie-based transparent authentication uses cookies where the cookie name indicates the identity of the Security Appliance that set the cookie. This allows the Security Appliance to strip out its cookies to prevent credential leakage upstream. However, special care must be taken when configuring clusters of Security Appliances behind a load-balancing switch to ensure that any member of the cluster removes the cookies set by other cluster members. You can rely on each of the Security Appliances to remove its own cookies, but you must add additional CPL rules to remove cookies generated by other Security Appliances in the cluster. To do this, install CPL policies on each of the Security Appliances that delete these cookies.

· <Cache> Layers:

q If there is a rule in the <Cache> Layer that prevents certain content from being accessed, content distribution commands for this content fails.

q If the administrator’s browser is proxied to the Security Appliance, it is possible to generate CPL (through the Management Console's Web Access layer) that denies access to the management console.

· <Admin> Layer: The Management Console never sees the client IP address. Instead, the client address is the IP address of a Security Appliance. This can potentially break all the IP-based decisions, such as any policy rules in Admin layers.

· URL rewrite is supported for CONNECT requests, but the host and port are the only the URL components you can change.

· VPM: Policy that makes an “early action” conditional on a “late condition” is a violation of CPL design; however, while not recommended, it is allowed in VPM. In most circumstances a policy installation failure results.

This type of policy can be grouped into two classes:

q An “early action” is conditional upon a “late condition” within the same rule.

q A “late condition” appears in rule #n while an “early action” occurs in rule #n+i within the same policy layer. The result is that the “early action” in rule #n+i is not executed unless the late condition in rule #n has been tested and proven to be false.

Early Action Conditional on a Late Condition

An “early action” is conditional on a “late condition” within the same rule.

· The override authentication action (proxy_authentication(no)) must not be conditional on Group, User, Attribute, or MIME Type.

· The 'Use ICAP Request Service' action (request.icap_service(servicename | no)) must not be conditional on MIME Type conditions.

· The 'Rename Streaming Alias' action must not be conditional on MIME Type conditions.

Late Condition Conditional on an Early Condition

A “late condition” appears in rule #n while an “early action” occurs in rule #n+i within the same policy layer The result is that the “early action” in rule #n+i is not executed unless the late condition in rule #n has been tested and proven to be false. This type of policy is logically flawed. The same condition/action combinations that are illegal in part 1 are also illegal in part 2.

· The override authentication action (proxy_authentication(no)) must not appear in rule #n+i if rule #n is conditional on Group, User, Attribute and MIME Type.

· The 'Use ICAP Request Service' action (request.icap_service(servicename | no)) must not appear in rule #n+i if rule #n is conditional on MIME Type.

Proxy Chaining

There is a known limitation using the Security Appliance in proxy chaining scenarios. (B#20140) The scenario and workaround are described below:

Scenario: Transparent Cookie Authentication enabled on child AND/OR parent Security Appliance

Applies to the following setups:
Client ------->SecApp1 ------> SecApp2 (Any auth protocol) -----> OCS
Client ------->SecApp1 (Any auth protocol) ------> SecApp2 (Any auth protocol) -----> OCS

Issue: For transparent request using cookie-based authentication, the child Security Appliance (SecApp1) gets confused with the www.cfauth.com URL and doesn't forward the request to the parent Security Appliance and hence authentication fails.

Workaround: Make sure that the virtual URLs on child and parent Security Appliance have different values from each-other.

RIP

RIP must be disabled before current settings are changed to avoid compilation errors.

Serial Console

· If you use an older version of Windows, you might see double prompts or be unable to bring up the serial console using the Microsoft cmd session. The workaround is:

q Use the <Ctrl><Enter> key sequence instead of just <Enter>.

q Use the <Enter> key on the keypad

q Use a different Telnet client.

q From the cmd prompt, unset the CRLF variable.

· If you attempt to push a VPM-XML file greater than 2K from one ProxySG to another through Director, the file will be truncated because the CLI on the ProxySG has a 2K limit.

SSH

· Using SSH RSA public key authentication, you are treated as a serial port user and would use the console enable password. Otherwise, SSH admin sessions require the individual administrator’s password to enter enable mode (provided the user is allowed to enter enable mode).

· The console access list is used to control authorization through SSH admin sessions. Therefore, the console access list must include all IP addresses where an SSH session would originate from. If the console access list is used this way, the trade-off is a weakening in the protection of the console credentials, as the console access cannot be restricted to a single machine or disabled entirely.

Streaming

· ASX rewrite rules set up for multiple Security Appliances configured in a HTTP proxy-chaining configuration can produce unexpected URL entries in access logs for the downstream Security Appliance (the Appliance that the client proxies to). The combination of proxy-chained Security Appliances in the HTTP path, coupled with ASX-rewrite rules for multiple Security Appliances in the chain, can create a rewritten URL requested by the client in the example form of protocol1://downstream_SecApp/redirect?protocol2://upstream_SecApp/redirect?protocol3://origin_host/origin_path.

In this scenario, the URL utilized by the downstream Security Appliance for caching and access logging might be different than what is expected. Specifically, the downstream Security Appliance creates an access log entry with protocol2://upstream_SecApp/redirect as the requested URL. Content is also cached using this truncated URL.

Blue Coat recommends that the asx-rewrite rule be set for only the downstream Security Appliance, along with a proxy route rule that can forward the WMT streaming requests from the downstream to upstream Security Appliances. (B#21880)

· The Real Media CLI command for configuring multicast address ranges (streaming real-media multicast address-range range) accepts a hyphen (-) for a valid range without returning an error.

· Applies to Windows Media Player Version 6.4 only: for ASX rewriting to occur, the player must be configured to use the Security Appliance as the HTTP proxy. Configuring the browser only as the HTTP proxy is not sufficient.

Streaming: Third-Party Vendor Issues

RealProxy

· RealOne ver.1 player does not understand NTLM challenge. Use RealOne ver. 2 instead.

· RealProxy stability might be dependent on RealPlayer stability. Specifically, RealPlayer instability while the client to Security Appliance connection is still active might impact RealProxy stability within the Security Appliance. (B#20020, 20237, 20936, depending on the RealPlayer version).

WMT

· WMT Streaming NTLM-auth problems with 6.4 players have been observed on Win2k Professional. The problem does not occur with NT or Win2k Server. Since 7.x players are supported on Win2K, the impact of this problem can be minimized for stand-alone use of the players. However, the use of NTLM-authenticated content that is streamed to an embedded player hosted within a Web page on a Win2k browser is impacted: Browser-embedded-player content typically utilizes 6.4 players.

· WMP6.4 player has problems resolving host-only domain names; for example, URLs of the form http://foo/test.asf.

·         WM Player does not respond to auth challenges for .nsc file requests. The problem applies to proxy auth challenges from the Security Appliance or a server auth challenge from an origin http server (even when bypassing the Security Appliance). A work around solution can be made by providing security exceptions when the authenticate property is set. Example:
<proxy>
   authenticate(ntlm_rlm)
<proxy>
   url = http://www.bluecoat.com/test1.nsc proxy_authentication=no

· Multicast .nsc files must be requested from a player with a .nsc file extension. URL rewrite rules cannot be specified at the Security Appliance that rewrites a non-.nsc filename to a .nsc filename.

Transparent FTP

· With transparent FTP, there is no way to write policy that tests the FTP user name, or tests for anonymous FTP.

· Transparent FTP proxy does not support proxy authentication.

· Caching is supported for anonymous FTP only.

· An object cached by transparent FTP will not be served from the Security Appliance in response to an FTP request over HTTP, and vice versa.

· There is no action available in CPL that forces the dropping of a connection in transparent FTP. For example, policy that denies a particular file only applies to the command that references that file (for example, the get filename command in a UNIX-style FTP command line is denied if the filename matches, but the FTP session remains open). However, there is a mechanism to prevent connections from being established to particular FTP servers using the url_host and method triggers:

For example: deny method=OPEN url_host=ftp.example.com

denies all attempts to open a connection on the ftp.example.com server.

· Virus scanning, URL rewrite, and content transformation are not applied to objects transferred through transparent FTP. In explicit proxy mode, FTP traffic goes over HTTP and you will be able to take advantage of virus scanning, rewriting, etc.

Changes in this Version

SGOS 2.1.11 (build 21545)

There are no new features in SGOS 2.1.11.

SGOS 2.1.10 (build 21093)

Major features of SGOS 2.1.10 include:

· New Version Numbering Scheme

· ICAP HTTP Support

· Customizable Patience Pages

· You can configure a default advanced forwarding host during initial configuration from the Serial Console.

· You can delete the X-Bluecoat-Via-Header, a proprietary Blue Coat header inserted to prevent looping.

· Policy event logs have been given their own internal log level for sorting. Some Blue Coat Systems products were utilizing versions of OpenSSH and OpenSSL that exposed a buffer management vulnerability or allowed an attack based on malformed client certificates.

· Unzipping the archive containing the Blue Coat NTLM agent (CAASNT) extracted the files to the "wdir_ca/Release" subdirectory under the directory in which the extraction was specified to occur. This no longer occurs and instead unzipping simply extracts the files to the directory specified.

Blue Coat Port 80 Security Appliance Documentation

These manuals are available in Adobe® Acrobat® PDF format on the Blue Coat Web site.

SGOS 2.1.11 Release Notes (this document)
Blue Coat Port 80 Security Appliance Configuration and Management Guide
Blue Coat Content Policy Language Guide (updated for 2.1.10)
Blue Coat Command Line Reference Guide
SNMP MIBS

In addition to the above documents, the Security Appliance Management Console contains online help in the form of a built-in HTML version of the Configuration and Management Guide that is linked to Help buttons. However, this online help is updated with every dot release. Therefore, Blue Coat recommends that you visit the Blue Coat Web site for the most up-to-date documentation.

Support

Support questions regarding this release should be directed to Blue Coat Technical Support. To contact Blue Coat Systems:

· North America (USA) Toll Free: 1.866.362.2628 (866.36.BCOAT)

· North America Direct (USA): 1.408.220.2270

· Asia Pacific Rim (Japan): 81.3.5425.8492

· Europe, Middle East, and Africa (United Kingdom): +44 (0) 1276 854 101

· support@bluecoat.com

Copyright © 2002-2004 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 Systems, Inc. specifications and documentation are subject to change with notice. Information contained in this document is believed to be accurate and reliable; however, Blue Coat Systems, Inc. assumes no responsibility for its use. Blue Coat™, ProxySG™, CacheOS™, are trademarks of Blue Coat Systems, Inc. and CacheFlow®, and Accelerating The Internet® 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.