How McAfee Web Gateway can protect end users from the POODLE vulnerability

Version 6

     

    What is POODLE?

     

    POODLE stands for "Padding Oracle On Downgraded Legacy Encryption" . This vulnerability allows a man-in-the-middle attacker to downgrade TLS to the old SSL3 method which allows an attacker to more easily decrypt user HTTPS traffic.

    More details are available via CVE-2014-3566

     

    How can McAfee Web Gateway help me keep my users safe?

     

    McAfee Web gateway (MWG) has the unique advantage to be a fully featured SSL Scanning proxy server that sits between the clients and the destination server. As a proxy, MWG controls the client side and the server side of the connection in two separate TCP connections. For each connection, the client and the server side have to "agree" on the protocol version to be used.

     

    POODLE is dangerous because often times the client (your browser) and the web server will list SSLv3 as supported protocol versions, which then allows the attacker to force the usage of that version. With MWG in control of the connections, we simple "scratch" SSLv3 off of the list of supported protocol versions. The server thinks the client cannot support SSLv3 and the client thinks the server does not support SSLv3. That way, if an attacker tries to downgrade the connection, neither the server nor the client will agree to do it.

     

    Prerequisites

     

    You have to use the "SSL Scanner" in MWG to benefit from this protection. If you are already using the SSL Scanner in production today, the changes recommended below are quick and simple and will most likley give you protection without any issues (see Risk area at the bottom of this article). If you have not deployed SSL Scanner yet, we recommend that you carefully consider deploying it for future protections.

     

    For more information on the SSL scanner and best practices see this article: https://community.mcafee.com/docs/DOC-5276

     

     

     

    Client Side

     

    To prevent client side (the end users browsers) from using SSLv3, you need to edit your "SSL Client Context with CA" settings containers (all of them if you are using more than one!) and simply uncheck the support for SSLv3 as shown below.

     

    SSL Client Context With CA - Disable 3.0.png

     

    If you are using the "SSL Client Context without CA" (mostly used for reverse proxy deployments only), you can disable SSLv3 support for those connections as well.

     

    SSL Client Context Without CA - Disable 3.0.png

     

     

    Server Side

     

    For the connection from the MWG to the web server, you need to edit both, the "Certificate Verification" and "Content Inspection" containers as shown below.

     

                   1alt_settings_certverify.png

     

                        1alt_settings_contentinspection.png

     

    Exceptions for Special Sites

     

    In the event that you have a critical business site that requires SSLv3 support, it may be necessary to create a rule to include SSLv3 in the Web Gateway's handshake. This is easily accomplished through the flexibility of the Web Gateway's Rule Engine. Criteria can be given to the Web Gateway to apply special settings for requests destined for those sites.

     

    sslv3 rule.png

    sslv3_settings2014-10-17_204718.png

     

    Risks

     

    By disabling SSLv3 for all connections going through your Web Gateway, you are protecting your end users, but under some special circumstances, this can also lead to connection issues.

    For example, if the client browser does not support TLS, the connection will fail. The only browser known to have this limitations is IE6 (and older). All newer versions of IE and other common browsers support TLS.

    On the server side, you might run into a webserver that does not support TLS, but this is also very unlikely. In all honesty, if you do find a webserver that does not support TLS, it probably has not been updated/patched in a long time and you might want to stay away from that particular death trap :-)

     

    In case you do run into any of these issues (clients or server absolutely requiring SSLv3), you can create exception rules on the MWG for those particular connections and allow SSLv3 again.

     

    Changelog

     

    2014-Oct-28 - Added changelog

    2014-Oct-27 - Server side settings were updated to include alternative handshake settings using TLS 1.0