SSLv3 is highly insecure and vulnerable to man-in-the-middle attacks, as attackers can access the plain text information from the intercepted SSL traffic. This exploit is called POODLE, and is referenced in CVE-2014-3566. Please read the following Security Advisory for more information: SA-83

TLSv1.0 is also insecure, as it supports a downgrade to SSLv3.

What is and what is not impacted

On the Edge SWG (ProxySG), there are several services which use the SSL encryption: management console, proxy services, authentication against a tiers service, FTP client.

All versions of the Edge SWG (ProxySG) OS prior to version 6.5 are vulnerable, because SSLv3 is enabled by default for all services. The upgrade is strongly recommended and will automatically disable SSLv3 even if it was enabled in your original configuration, except for the proxy services.

Note: The proxy services are the services you can find in your Management Console at: Configuration > Services > Proxy Services. These services are the "proxy listeners" meant to intercept the users requests. Whatever is the version of your Edge SWG (ProxySG) OS, the Edge SWG (ProxySG) will always allow SSLv3 for the proxy services. So that all users can access any websites - this is the default behavior. However for security reasons, it is recommended to apply the CPL code below to block SSLv3 in the proxy services - this will prevent your users from accessing potentially harmful websites.

SSLv3 is highly insecure and vulnerable to man-in-the-middle attacks, as attackers can access the plain text information from the intercepted SSL traffic. This exploit is called POODLE and is referenced in CVE-2014-3566. Please read the following Security Advisory for more information: SA-83

TLSv1.0 (TLSv1) is also insecure as it supports a downgrade to SSLv3.

What is and what is not impacted

On the Edge SWG (ProxySG), there are several services which use SSL encryption: Management Console, Proxy Services, Authentication against a tiers service, FTP client, etc

All versions of the Edge SWG (ProxySG) OS prior to version 6.5 are vulnerable because SSLv3 is enabled by default for all services. An upgrade is strongly recommended and will automatically disable SSLv3 even if it was enabled in your original configuration, except for the proxy services.

Note: The proxy services are the services you can find in your Management Console at: Configuration > Services > Proxy Services. These services are the "proxy listeners" meant to intercept the users requests. Whatever the version of your Edge SWG (ProxySG) OS, the Edge SWG (ProxySG) will always allow SSLv3 for the proxy services. So that all users can access any websites - this is the default behavior. However for security reasons, it is recommended to apply the CPL code below to block SSLv3 in the proxy services - this will prevent your users from accessing potentially harmful websites.

Add the following to the CPL part of your policy in order to block SSLv3 between end-users and OCSs (Origin Content Server):

<SSL>
client.connection.negotiated_ssl_version=(SSLV3) force_exception(silent_denied)
server.connection.negotiated_ssl_version=(SSLV3) force_exception(silent_denied)

In order to present the exception page to the client/user, the  appliance has to complete the SSL/TLS negotiation with the server.
During the SSL negotiation, the proxy is not forwarding any data to the server, just passing the ssl handshake.

If the server terminate/reset the connection during the ssl handshake, the exception page won't be presented to the client.
In this case the policy trace will show n/a: for the rules

 <ssl>
   n/a:     client.connection.negotiated_ssl_version=SSLV3
   n/a:     server.connection.negotiated_ssl_version=SSLV3

When the SSL is negotiated, the exception page is presented to the client and the appliance tears down the connection without forwarding or proxying any data traffic.

Verification steps

If you want to ensure this piece of code blocks SSLv3 for all intercepted traffic, follow the steps below:

Before applying the CPL code:

1. Find an SSLv3-enabled browser. Use Internet Explorer, which enables SSLv3 by default, or you enable SSLv3 on Firefox: go to about:config and change the value of security.tls.version.min to 0 (zero).
2. Clear the browser's cache.
3. Go to https://www.ssllabs.com/.
4. Click Test your browser.
5. In the POODLE Vulnerability section, the page will say "Your user agent is vulnerable". Under Protocol Features, SSL 3 will say "Yes". This means you are using SSLv3.

After applying the CPL code to your configuration and installing the policy:

1. Open the same SSLv3-enabled browser.
2. Clear the browser's cache.
3. Go to https://www.ssllabs.com/.
4. Click Test your browser.
5. The test will say you are no longer vulnerable, meaning the proxy is blocking SSLv3 even though client and OCS are SSLv3-enabled.

Additional notes on verification

If the verification involves testing the device (SG/ASG/SGVA) itself against SSLv3 using vulnerability scanner, you may still observe that vulnerability tools are reporting SG’s service port 443  is vulnerable to SSLv3, even with the above policy being applied. This can be considered as false positive because when testing  service port 443 (without connecting to OCS via proxy), SG will intercept the connection and perform SSL handshake (regardless of the SSL version) to present below exception message. You can test this by connecting to: https://<ProxyIP>, you will get the following:

Most vulnerability scanner tools considers this as vulnerable as SG is performing SSL handshake . (i.e Server hello , certificate was provided back to the scanner when it offered SSLv3 Client Hello). vulnerability scanner tools does not consider the actual HTTPS response being retuned by the SG. 

This false positive can be corrected as well by changing the listener configuration of proxy service port 443. Navigate under web UI --> Configuration --> Services --> Proxy Services --> edit service "HTTPS" or whichever service has port 443 listener --> Under listeners change "destination" from all to Transparent. Make sure you hit 'Apply' at the end. This will remove the false positive from the scanner as Proxy will no longer respond on Port 443 request coming to it's own IP.