The discovery of the POODLE attack on the SSL/TLS protocol caused a major shake-up throughout the internet. The severity of the attack forced service providers and software vendors to rush to implement and deploy adequate countermeasures. Even though the authors of TLS came up with a dedicated protocol patch, the majority of web parties decided to follow a simpler path, disabling support for SSL v3.0 in its entirety. As among those who have ceased or announced the cease of support for SSL v3.0 are market players as huge as Mozilla and Google, the beginning of a new, pure TLS 1.0+ era of Internet communication should probably be welcomed and accepted.

While generally being a reasonable decision (version 3.0 is quite old and insecure and should have been got rid of long ago), ceasing support for SSL v3.0 is still a substantial change in configuration that breaks what could be referred to as a delicate compatibility balance that had built up over the years. Literally millions of installations of secure clients and servers come with support for SSL 3.0 switched on by default. Some of them are updated automatically; others are not. Updating their configuration will surely take some time, so we will most likely notice a rise in the number of connectivity issues between SSL/TLS peers. From our local perspective, we are noticing a sharp fall in the number of public servers accepting SSL v3.0 connections after the discovery of the attack.

As SSLBlackbox client-side components, just like the majority of others, come with SSL v3.0 support turned on by default, software that uses them might start experiencing compatibility problems when connecting to those servers that stopped supporting SSL v3.0. This article is intended to help those of our customers who use SSLBlackbox and SSLBlackbox-powered packages (FTPSBlackbox and HTTPSBlackbox) achieve maximum compatibility. We strongly suggest that you read this guide if you use one of those packages in your product and apply the recommendations given here.

Note: To increase compatibility and improve protection from the POODLE attack, starting from build 12.0.262 support for SSLv3.0 is switched off by default in the client-side components. It will still be enabled in the server-side components. This means that you might start experiencing negotiation problems with older servers that only support SSL v3.0. If you are affected by this change, please read our suggestions for client-side components below.

I use client-side SSL/TLS-based (HTTP, FTP, SMTP/POP3, and EDI) components: what should I do?

In the default configuration, you will only be able to connect to servers that support versions TLS 1.0 and higher (TLS 1.1 and TLS 1.2). Therefore, older servers that only support SSL 3.0 will reject connections from the components (there are not too many such servers). To maximize compatibility we recommend using the so-called 'fallback dance'. The idea is to try to connect with the TLS 1.0-TLS 1.2 versions enabled first. If the connection fails for whatever reason (some older servers might just crash without providing a meaningful response), another attempt with a lower version should be performed. In case of another failure, a subsequent lower version is tried, and so on. Please see the diagram below:

Note that using the Client.Extensions.FallbackConnection property is vital to counteracting the POODLE attack. Remember to set it when attempting to reconnect with a lowered protocol version. At the same time, do NOT set this property when connecting with the highest version supported by your application.

If you use an older version of SecureBlackbox with no support for the FallbackConnection property, the only way to counteract all downsides of SSL v3.0 is to switch it off completely.

I use server-side SSL/TLS components: what should I do?

The server-side components automatically recognize and counteract what might potentially be POODLE attacks, so you should not do anything with your server implementation. However, connections from genuine yet older SSL v3.0 clients are still subject to an increased risk of attack due to other vulnerabilities in the protocol, so it might make sense to disable SSL v3.0 if you aim for higher security levels. Note that it is likely that we will be disabling SSL v3.0 in the server-side components within a term of several months, so it makes sense to try switching off SSL v3.0 manually (e.g., in experimental/provisional versions of your software) in order to probe the environment.

If you use an older version of SecureBlackbox, switching off SSL v3.0 is the only way to counteract the attack.