Maintaining backward compatibility so a new technology or standard can work with older versions and products is...
a drag on improving the overall security of the Internet.
The need to maintain support for legacy systems means insecure protocols and technologies can't be completely replaced and relegated to the history books. The SSL/TLS protocol is a good example of where security is compromised for the sake of interoperability.
In this tip, I am going to take a look at the security issues the POODLE vulnerability caused for SSL/TLS and explain how to find and mitigate them.
SSL was groundbreaking in its day and paved the way for the start of the e-commerce boom due to the fact that it allowed sensitive data such as credit card numbers to be safely exchanged over the Internet. However, as the years have passed, weaknesses have been found and it has been superseded by the more secure TLS or Transport Layer Security protocol.
TLS introduced multiple security improvements, including support for newer and more secure algorithms. However, to maintain backwards compatibility with SSL, there is a protocol downgrade option during the TLS protocol handshake where the server and client negotiate which protocol version to use. This functionality means that even if a client and server both support TLS, an attacker may still be able to target weaknesses in the SSL protocol.
Inside the POODLE vulnerability
The POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability that hit the headlines last October was discovered by Google's security team; the team found that by using a man-in-the-middle attack they could spoof packets sent between a website and a user to force a protocol downgrade, forcing the connection to use SSL 3.0. The attacker could then exploit vulnerabilities in SSL to steal the authentication cookies or security tokens used to access user accounts. This is not an easy attack to pull off, as it requires the attacker to modify thousands of requests until they can successfully deduce the contents of encrypted payloads. POODLE is not seen nearly as serious a threat as the Heartbleed flaw; however, the Internet community has moved quickly to mitigate the problem, as there is no practical workaround other than limiting or eliminating the use of SSL.
Remediating the problem
Google plans to remove SSL support from its products completely, while Microsoft will disable SSL by default in its products and services within a few months. Mozilla has already disabled SSL in Firefox 34, and it has been disabled in the open source cryptographic software library LibreSSL version 2.1.1.
To mitigate the risks of POODLE and SSL security vulnerabilities, network administrators should implement support for the TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV). This enables a server to reject a connection in case of a downgrade attack. Recent versions of OpenSSL have added support for TLS_FALLBACK_SCSV. To be effective, clients also need to support TLS_FALLBACK_SCSV; the major browsers either already support it or will in upcoming versions.
While disabling the SSL protocol in the client and server and enabling TLS_FALLBACK_SCSV is fine in the majority of situations, it may not be possible if older systems need to be supported that only support SSL, such as Internet Explorer 6 on Windows XP. TLS_FALLBACK_SCSV doesn't actually resolve the POODLE vulnerability when SSL is used -- it just prevents newer clients from downgrading to SSL and thus becoming vulnerable. If your organization really has to support SSL, then it should disable all SSL cipher suites that run in CBC mode and use some form of an RC4 cipher. This is not ideal, but it's better than nothing. Also be sure to set an alert to fire if the number of requests generated by a client is unusually high, as this could indicate that the plaintext recovery phase of a POODLE attack is underway.
Worryingly, a variant of the original POODLE attack was announced in December. The variant exploits implementation flaws in versions of the TLS protocol, making some servers vulnerable to POODLE, even if they disable SSL. The vulnerability occurs when encryption padding is not validated properly. According to Qualys SSL Labs, about one in 10 websites are vulnerable to this new attack, which is easier to execute than the original attack, as there is no need to downgrade the connection to SSL first. Many popular websites are at risk due to the popularity of F5 load balancers, which are vulnerable to this form of POODLE attack; read the F5 Security Advisory for more information and details of their recommended actions.
Until SSL is completely retired, SSL/TLS security risks will remain. Network administrators who are unsure whether their networks are affected should use the Qualys SSL Server Test to see if their servers need patching; suggestions will also be given to improve website security -- for example, not only disabling SSL 3.0, but also improving signature security. This is a test I recommend running as soon as possible to detect and remediate potential issues.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He co-authored the book IIS Securityand has written numerous technical articles for leading IT publications. He was also formerly a Microsoft Certified Database Manager and a registered consultant with the CESG Listed Advisor Scheme (CLAS). Mike has a passion for making IT security best practices easier to understand and achievable. His website www.hairyitdog.com offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices.
Learn the latest in SSL and TLS security.
Uncover how to improve SSL/TLS security through education and technology.