SGOS 6.7.1.1 was released on February 22, 2017. To download this release and the SGOS 6.7.x Release Notes, log in to the BlueTouch Online (BTO)  Downloads page with your BTO credentials. Refer to the Release Notes for details on the features, security fixes, and known issues in this release.

Upgrade Note: The Application Delivery Network (ADN) feature is not supported in SGOS 6.7.1.1. If you use ADN in your deployment, do not upgrade until this issue is addressed in a subsequent 6.7.x release.
SGOS 6.7.1.1 introduces the following new features:

Support for Universal Policy

Universal policy is a set of global rules that you create in Blue Coat Management Center and apply to users in any location. The policy can include global rules that apply to both on-premises and Web Security Service (WSS) users, as well as individual rules that apply to only one or the other. It can also include location-specific policy when necessary. In essence, universal policy comprises the various rules that reflect your organization’s acceptable use policy. Using Management Center to distribute the policy to on-premises devices and the WSS makes it easy to apply the relevant policy to all users in your organization.

To support universal policy, this release of SGOS allows you do the following on the ProxySG appliance:
  • Specify and change enforcement domains in the Visual Policy Manager.
  • Designate sections of policy as being appliance- or WSS-specific using the #if enforcement=appliance and #if enforcement=wss variables, respectively.
  • Specify the ICAP service type in the Management Console or in the CLI.
  • Configure the enforcement classification file in the CLI.

Cloud Policy Configuration in Management Console

You can now configure cloud policy in the Management Console ( Configuration > Cloud Configuration > Cloud Registration); previously, only CLI commands were available.

Web Application Firewall Features

This release includes the following enhancements for Web Application Firewall (WAF):

Command Injection Engine Version Logging

If WAF engines detect a command injection attack, the x-bluecoat-waf-block-details and x-bluecoatwaf-monitor-details fields in the bcreporterwarp_v1 access log format include the version of the command injection engine used for the detection:
  • version 2 - Indicates the legacy version used in versions prior to 6.6.5.1. This version targets chained command sequences, and requires command-separation characters to be present in the payload to be effective.
  • version 3 - Indicates the current default version. The command injection engine detects a wider set of attacks, including non-chained command injection payloads. Blue Coat recommends that you use this version.
WAF Scan Details Logging

If policy includes the http.request.detection.bypass_cache_hit(yes) property, the x-bluecoatwaf-scan-info field in the bcreporterwarp_v1 access log format indicates if WAF processing is intentionally skipped due to cache hit optimization being bypassed.
  • If WAF engines scan a transaction, the field reports WAF_SCANNED.
  • If WAF evaluation does not occur due to the presence of http.request.detection.bypass_cache_hit(yes) property or the absence of WAF policy, the field reports WAF_SCAN_BYPASSED.
  • If no WAF policy is present, the field reports WAF_DISABLED.
SOAP Request Handling

The appliance can now interpret SOAP messages correctly and parse attachments in SOAP content. SOAP content is normalized correctly before it is sent to WAF engines for evaluation. Attachments are sent for further scanning based on their content type. SOAP request handling occurs without additional configuration when WAF policy exists.

Deep Multipart Inspection

The appliance now parses and normalizes sub-parts of multipart HTTP request bodies. Sub-part content is parsed based on the content-type. For example, if one of the sub-parts is JSON, and another is XML, each part is parsed correctly.

The http.request.detection.other.invalid_form_data(block) property blocks a matching request when an invalid multipart format is encountered.

Cross Site Request Forgery (CSRF) Attack Protection

Through the use of secure tokens, the appliance validates user authentication on subsequent requests and protects POST requests in static and AJAX forms. This feature includes new CPL gestures:
  • http.csrf.authentication_link(userid,client_ip)
  • http.csrf.detection(action)
  • http.csrf.token.insert(n)
Masking Sensitive Data in Access Log Details

This feature works when http.request.log_details[header](yes) or http.request.log_details[body](yes) is used to output header or body data to an access log. The following new CPL obfuscate sensitive information from access logs:
  • http.request.log.mask_by_name[regex_pattern](yes)
  • lttp.request.log.mask_by_value[regex_pattern](yes)
Obscured content appears as asterisks ( ****) in the log.

The following is an example of access logging policy:
; mask social security number (ssn) values from body text when reported in an access log
<proxy>
  http.request.log.mask_by_value["[0-9]{3}[ -]?[0-9]{2}[ -]?[0-9]{4}"](yes)

Invalid/Multiple Encoding Details in Access Logs

The appliance now reports the normalization function that triggered an invalid encoding or multiple encoding policy match. When invalid encoding or multiple encoding issues are identified in normalization, the function that caused it is added to the x-bluecoat-waf-block-details or x-bluecoat-waf-monitor-details access log fields as appropriate. No additional configuration is required for this feature.

Access logs include details for following functions:
  • Multiple encoding: base64Decode, cssDecode, htmlEntityDecode, jsDecode, urlDecode, urlDecodeUni,utf8toUnicode
Note: utf8toUnicode is access logged when a second application of the normalization sequence includes a decoding of utf8 bytes.
  • Invalid encoding: utf8toUnicode
Identify Transactions in Exception Pages and Access Logs

Exception pages now include the transaction ID (a unique, per-transaction identifier) by default. As an example, an exception page includes the following text:
"Transaction ID: c27001ec614d1217-00000000000002d1-0000000058238d68"

To aid in general troubleshooting:
  • Include the x-bluecoat-transaction-uuid field in the access log format
  • Instruct users who receive exception pages to report the transaction ID
  • Locate the transaction ID in the log to learn more about the transaction
If you do not want exception pages to show the transaction ID, you can:
  • Remove it from the exceptions definition under $(exception.help)
  • Override the HTTP exceptions format with one that omits the $(x-bluecoat-transaction-uuid) substitution using the following CLI command:
#(config exceptions)inline http format eof_marker

After an SGOS upgrade, the default exceptions definitions are updated but the current exceptions are unchanged; you must edit your current exceptions manually to get the changes. See the  SGOS Upgrade/Downgrade WebGuide for instructions.

Integration with WAF App for Splunk Plugin

A Blue Coat WAF App for Splunk plugin is available from Splunkbase. The plugin presents WAF log data visually on dashboards, allowing you to:
  • Aggregate log files passed into the database
  • Specify how log files are parsed
  • Search WAF log files
  • Pivot search WAF logs and Blue Coat Security Analytics logs

DNS Access Logging

A new dns access log for the DNS proxy was added as a default access log. It is available in the Management Console Default Logging Policy list, the default access Log Formats list, and as a default log facility.
  • The CLI has been extended to include DNS; dns is included in the #(config access-log) default-logging command.
  • In the Management Console, to configure the DNS (or any) Access Log, go to Configuration > Access Logging > Upload Client. To trigger log transfers to the client, go to Configuration > Access Logging >
  • Upload Schedule.
  • IPv6 is not supported at this time.
  • On downgrade, the DNS default log facility remains visible in the Management Console, though logging will not work. Issue the #restore-defaults factory-defaults command to remove DNS access log objects.

SSLV Offload

In this release, you can connect one or more ProxySG appliances to an SSL Visibility appliance running version 4.0.1 to offload SSL/TLS traffic processing. Configuring SSLV offload requires that you identify the ProxySG and SSLV appliances to each other using their respective serial numbers.

Configure SSLV offload on the ProxySG appliance using one of the following methods:
  • Managing SSLV appliances in the Management Console (Configuration > SSL > SSLV Offload)
  • Issuing the #(config ssl)sslv-offload command
You must also add ProxySG appliance information to the SSLV appliance(s). 

Routing Domains Configuration in Management Console

Routing Domains allow you to route traffic for unique networks through the same appliance, where each network has its own gateway and DNS server. This release introduces this feature as a configurable option in the Management Console ( Configuration > Network > Routing > Routing Domains).

Network HSM Failover

The ProxySG appliance HSM Failover ability applies to HSM keyrings contained in an HSM keygroup. If the ProxySG appliance encounters an error when attempting to use an HSM keyring, it is flagged as failed. The signing
operations will be tried on another member of the HSM keygroup, if applicable. The ProxySG appliance will periodically attempt to see if the error has been corrected. Once it has been, the HSM keyring will be put back into service.

IWA Direct Feature Enhancements

  • In previous versions of SGOS, the appliance sent LDAP pings for domain controller discovery over the TCP protocol. In SGOS 6.7.1.1, you can specify UDP or TCP as the protocol using the following command:
#(config security windows-domains)ldap-ping-protocol {tcp | udp}
  • When upgrading to this release, the TCP setting is preserved for existing Windows domains and the default for new domains is UDP.
  • By default, the appliance now uses the SMB2 protocol for connecting to the Active Directory server. If the server still uses the SMB1 protocol, issue the following command:​
#(config security windows-domains)smb2 disable

User Email Address Reporting

The ProxySG appliance can report on the email address of an authenticated SAML or IWA Direct user. This allows you to include the email address in:
  • HTTP/S requests to the Elastica Cloud Access Security Broker (CASB) Gateway
  • Access log formats, using the new field x-cs-user-email-address
  • Exception pages and policy, using the new $(user.email_address) substitution variable
For unsupported authentication realms, the field returns an empty string.

Refer to Blue Coat Knowledge Base article 000032542 for an example of how to send the email address in requests to the CASB service.

The following CLI subcommands were added for IWA Direct:
#(config iwa-direct realm_name)email-address enable
Enable the feature to report on the user's email address. Use in conjunction with the email-attribute subcommand.

#(config iwa-direct realm_name)email-attribute attribute
Specifies the attribute that represents the user's email address. Enable retrieval of this attribute with the email-address enable subcommand.

The following CLI subcommand was added for SAML:
#(config saml realm_name)email-address-attribute attribute
Specifies the attribute that represents the user's email address and retrieves the value of the attribute.

Note: Map the SAML email address attribute to the relevant field on the IDP. For example, if your IDP is Shibboleth, map the emailAddress attribute to the mail field.

Client Certificate Emulation

To facilitate choosing signing certificates for the client in a reverse proxy deployment, this release includes client certificate emulation. When this feature is enabled:
  • The appliance requests a certificate from the client.
  • If the client returns a certificate, the appliance copies the certificate attributes to a new client certificate (so that it appears to originate from the client). Emulation does not occur if the client does not return a certificate.
  • The appliance presents the certificate during the SSL/TLS handshake when an OCS requests a client certificate.
The following CPL action was added to support this feature:

server.connection.client_issuer_keyring(no|<keyring_id>|<hsm_keyring_id>|<hsm_keygroup_id>)

where:
  • no disables client certificate emulation; this is the default setting
  • <keyring_id> means to use the specified keyring for client certificate emulation. This must be a valid keyring, specified on the appliance with a CA certificate.
  • <hsm_keyring_id> means to use the specified HSM keyring for client certificate emulation.
  • <hsm_keygroup_id> means to use the specified HSM keygroup for client certificate emulation.

New TLS and Cipher Defaults

On an initial upgrade to version 6.7.x, TLS 1.1 and 1.2 are the default protocol selections for the Management Console and the SSL device profiles. TLS 1.1 will be used if 1.2 is not available. TLS 1.0 has been disabled by default. The default ciphers suites have been correspondingly updated as well.

If the default protocols (TLS 1.0, 1.1, and 1.2) for the SSL device profile (as with the HTTPS Console service) were selected previously, only TLS 1.1 and 1.2 are selected by default now. If the SSL device profile protocols were changed from the defaults previously, the selections do not change.

Notes:
  • The predefined SSL passive-attack-protection device profile can be used by many services, such as Authentication, Access-log, ICAP, Secure ADN, and OCSP.
  • Interoperability issues may arise if a default or user-configured device profile is used to connect to a remote service which does not understand TLS 1.1 or 1.2.
  • Management Console will no longer connect to browsers which don't support TLS 1.1 or 1.2 (Chrome before v21, Firefox before v23, Internet Explorer 8 and 9).
  • If an SSL device profile uses a custom cipher suite, that cipher suite will be overwritten on upgrade.
  • BCAAA may or may not support TLS 1.1. or 1.2. If the BCAAA connection fails, enable TLS 1.0 on the default SSL device profile.
    • Windows XP and Windows Server 2003 do not support TLS 1.1 or TLS 1.2.
    • Windows Vista and Windows Server 2008 do not support TLS 1.1 or TLS 1.2.
    •  If you are using a Windows version later than those listed here, do not edit the default SSL device profile.
  • User-configured SSL device profiles and Management Console settings retain their previous settings. Blue Coat strongly recommends updating the settings as soon as possible. If Director or Management Center attempts to copy a configuration containing these older protocols to a different device, the operation will fail, as the client device treats copied device profiles as new profiles.
  • The reverse proxy is unchanged. The defaults are TLS 1.0, 1.1, and 1.2 enabled. SSLv3 and SSLv3 are options.
  • For the forward proxy, SSLv2 and v3 are disabled by default.
  • SSLv2 and SSLv3 have been removed from the CLI for the Management Console and SSL device protocol; attempting to use them will generate errors.
  • On a downgrade from version 6.7.x , your selections do not change (whether you kept the default selections or changed them).
Any subsequent upgrades to 6.7.x, for example after a downgrade, do not change the protocol selections; the protocols selected prior to the subsequent upgrade are retained.

Enhancements and Changes in SGOS 6.7.1.1

SGOS 6.7.1.1 also introduces the following enhancements and changes:

Pipelining Disabled by Default for Better Network Performance

Due to recent advances in web browsers, pipelining provides limited benefits and can increase CPU utilization in certain workloads. Thus, in a new installation of 6.7.x, or upon an upgrade to this release, pipelining is disabled by default.

ECDSA Signed Certificate Support

The ProxySG appliance can now verify ECDSA certificates during the SSL handshake, as well as DSA and RSA.

Increased Key Sizes for Emulated Server Certificates

The key size supported for emulated DSA and ECDSA server certificates has been increased to 2048 bits. The key size for emulated RSA server certificates is now matched up to a maximum of 4096 bits. For example, when the ProxySG appliance intercepts a 4k RSA server certificate, it will emulate a 4k certificate. On downgrade, the previous RSA 2k and DSA/ECDSA 1k limits will be enforced.

AES-GCM and SHA384 Ciphers Support

The appliance now supports the following cipher suites for SSL forward proxy:
  • AES128-GCM-SHA256
  • AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-SHA384
The following product documentation was updated for this release:
Refer to the SGOS 6.7.x Release Notes for information on the known issues in this release.
Imported Document ID: 000032742

Thanks for your feedback. Let us know if you have additional comments below. (requires login)

    © 1995-2020 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.