The version 3 of SSL is broken. It is considered dangerous to use, since man-in-the-middle 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
What is and what is not impacted: 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.
Solution: 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
Now, it must 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 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.
As the time of writing this article (June 2016), the only versions of SSL that are still considered acceptable are TLS v1.1 and TLS v1.2. TLS 1.0 is still in use in many places and yet is considered weak since it allows the downgrade to SSLv3 during the SSL handshake process. TLS v1.0 is disabled by default (for all services except for the proxy services) in the ProxySG OS starting from version 6.6.2.
Imported Document ID: 000031356
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe