The discovery of the POODLE attack on SSL/TLS protocol caused a major shake-up throughout the Internet. The severity of the attack forced service providers and software vendors to rush up with implementing and deploying adequate countermeasures. Even though authors of TLS came up with a dedicated protocol patch, the majority of web parties decided to follow a simpler path of 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, a beginning of new, pure TLS 1.0+ era of Internet communication should probably be welcomed and accepted.
While being generally a reasonable decision (version 3.0 is quite old and insecure and should have been got rid of ages ago), ceasing support for SSL v3.0 is still a substantial change in configuration that breaks what could be referred to as delicate compatibility balance that have been built up for 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, the 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 which stopped supporting SSL v3.0. This article is intended to help those of our customers who use SSLBlackbox and SSLBlackbox-powered packages (FTPSBlackbox, HTTPSBlackbox) achieve the maximum compatibility level. We strongly suggest that you read this guide if you use one of those packages in your product and apply 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 client-side components. It will still be enabled in 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, EDI) components: what shall I do?
In default configuration you will only be able to connect to servers that support versions TLS 1.0 and higher (TLS 1.1, TLS 1.2). Therefore older servers which only support SSL 3.0 will reject connections from the components (there are not too many such servers, to be fair). To maximize compatibility we recommend using so-called ‘fallback dance’. The idea is to try to connect with 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 for 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 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 shall 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 increased attack risk 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 several months term, 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 SecureBlackbox, switching off SSL v3.0 is the only way to counteract the attack.