The POODLE vulnerability is applicable to SSLv3 only. To prevent against this with Sentry, disable the SSLv3 protocol option in any Sentry SSL policies (this includes SSL Termination and SSL Initiation policies).
Note that disabling SSLv3 could cause interoperability issues with trading partners who only support SSLv3. Therefore, this change should be tested before being implemented.
Ultimately the requirements of the services deployed should restrict clients to using at least TLS 1.0 (preferably 1.1 or 1.2) and prohibit any undesired cipher suites. Then build the SSL policies in Sentry to enforce accordingly.
The SSL handshake is a negotiation of sorts between the client and server where the most secure SSL protocol and cipher suites are selected to use for the connection. Both parties have to support the same protocol and cipher suites in order for a connection to be established.
The POODLE bug relies on server's allowing a fallback to SSLv3.
In Sentry, when you build an SSL policy (termination or initiation) you can specify which protocols (SSLv3, TLS 1.0, TLS 1.1, and TLS 1.2) and which cipher suites (too many to list here) are available for use with the client/server.
If you do not allow the use of SSLv3 in the SSL policy, you remove the vulnerability to the POODLE attack, but you might suffer from interop issues with clients who ONLY support SSLv3. These would be legacy apps that haven't been modernized to support the latest TLS standards - they should be rare and they should be required to update or not be allowed to access the service.
The best way to determine which protocol and cipher suites are used during an SSL handshake is to review a packet capture of a transaction. While the data is encrypted when using SSL/TLS, the SSL handshake is not and you can see this negotiation happening and which SSL version and cipher suites are selected.
The Sentry log shows the cipher suites used in DEBUG mode, but not the SSL version. For instance:
SSL handshake completed from '/192.168.82.72:56461' to '/192.168.82.26:443' using cipher suite 'TLS_ECDHE_RSA _WITH_AES_128_CBC_SHA'
Again, to ensure there is no vulnerability you will need to disable SSLv3 on any SSL policies that are currently using it.
Info on the Web
The following paragraph is taken from: http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
“A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).
It is important to note that this is NOT a flaw in SSL certificates, their private keys, or their design but in the old SSLv3 protocol. SSL Certificates are not affected and customers with certificates on servers supporting SSL 3.0 do not need to replace them.
It’s believed to not be as serious as the Heartbleed bug in OpenSSL, since the attacker needs to have a privileged position in the network to exploit the latest. The usage of Hotspots, public Wi-Fi, makes this attack a real problem. This type of attack falls into the “Man-in-the-middle” category.”