The SSL POODLE vulnerability allows an attacker to listen to SSL 3.0-encrypted communication. It is short for “Secure Sockets Layer Padding Oracle on Downgraded Legacy Encryption.” It is widely known as the bug that brought SSL usage to its end. In fact, the POODLE vulnerability no longer affects Transport Layer Security (TLS), SSL’s successor, which was released in 1999.
While the advent of TLS usage should’ve ended woes related to the SSL POODLE vulnerability, that is not the case. 2021 stats revealed that 46 million websites still use SSL, which means they could still be vulnerable.
Other interesting terms…
Read More about “SSL POODLE Vulnerability”
The SSL POODLE vulnerability was discovered by Google Security Team researchers Bodo Möller, Thai Duong, and Krzysztof Kotowicz on 14 October 2014. Its discovery led to the shift to TLS. Unfortunately, a similar bug on TLS was found on 8 December 2014.
Why Should Users Still Be Wary of the SSL POODLE Vulnerability?
We all know the impracticality of shifting to the latest technologies as soon as they become available. That is especially true for companies that have to purchase tons of the newest software or hardware just to keep up.
And if you take implementation and rollout into consideration, they would have to devote a lot of time and effort (IT man-hours) to the endeavor as well.
Last but not least, even if you manage to upgrade to the latest tech, would all your customers, partners, and site visitors be able to do the same? If you kill SSL support, will they still be able to interact with your pages?
That is why it’s common to keep old software and hardware running despite weaknesses like the SSL POODLE vulnerability.
How Does the SSL POODLE Vulnerability Work?
Before discussing how the SSL POODLE vulnerability works, you first need to know that SSL allows servers and browsers to use various algorithms called “cipher suites” to encrypt communications.
The SSL POODLE vulnerability affects cipher suites that use a combination of symmetric encryption and block ciphers, such as Advanced Encryption Standard (AES) or Data Encryption Standard (DES). While you may find that too complex, just think of it this way: SSL usage requires clients and servers to agree on a private and public key combination. All communications between the clients and servers use these keys to encrypt and decrypt messages so they can’t be seen by prying eyes.
The SSL POODLE vulnerability also affects systems that use the cipher-block chaining (CBC) mode. The process involves adding a random data block at the start of the cipher, known as an “initialization vector,” to the data that is being encrypted. CBC then requires using the logical operation XOR to the previous data block to get the value of the current block. The entire process is done so each time the data is encrypted, it looks different, disallowing attackers from figuring out the data based on similarities.
If the explanation still seems complicated, maybe watching this video will help:
What Can Attackers Do via the SSL POODLE Vulnerability?
The SSL POODLE vulnerability, as mentioned earlier, lets threat actors eavesdrop on encrypted communications. Translation: Attackers can steal confidential data, such as passwords or session cookies, which they can use to impersonate affected users. The stolen credentials can cause website administrators to lose control over web applications. They can even get locked out of the systems that control the apps.
How Can Users Tell If They’re Affected by the SSL POODLE Vulnerability?
All web servers that support SSL 3.0 are vulnerable to the SSL POODLE vulnerability. If you don’t know what protocol (SSL or TLS) your web server, applications, and browsers use, you can use an online tool. Note, though, that a similar bug affects TLS 1.0. If that’s the case, disable all SSL and TLS 1.0 connections.
The test can also be done manually using the curl command:
curl -v3 https://yourwebsite.com
How Can Users Fix the SSL POODLE Vulnerability?
To protect against the SSL POODLE vulnerability, configure your web servers to support only TLS 1.2. Today’s browsers (e.g., Chrome, Firefox, and Internet Explorer) support TLS 1.2.
Apache server users should edit the SSLProtocol directive in the ssl.conf file, usually located in /etc/httpd/conf.d/ssl.conf. If you have SSLProtocol all, change it to SSLProtocol TLSv1.2, then restart httpd.
NGINX users should edit the ssl_protocols directive in the nginx.conf file. If you have ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;, change it to ssl_protocols TLSv1.2; then restart nginx.
Finally, Microsoft IIS users need to disable TLS 1.0 by editing the registry settings in Microsoft Windows. Follow these steps:
- Open the registry editor.
- Find the key HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server.
- Change the DWORD value of the Enabled entry to 0.
- Create a DisabledByDefault entry and change the DWORD value to 1.
- Repeat the above steps for all versions of SSL and TLS 1.1.
—
As you’ve seen, the SSL POODLE vulnerability can spell disaster for anyone who maintains a website. But the weakness is avoidable if you follow the best practices featured in this post.
