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.
On the 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 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 ProxySG OS, the 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 OSCs:
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
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.
If you want to ensure this piece of code blocks SSLv3 for all intercepted traffic, follow the steps below:
If your 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
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 433. 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. This will remove the false positive from the scanner.