Poodle – SSL Security Threat Explored

Poodle is a breed of dog with legs that resembles cotton candies. It is intelligent and a regular staple at dog shows. Even the most friendly dogs have the propensity to bite. Now we see all kinds of security alerts and snafus likes heartbleed and shell shock!!! The latest in addition is POODLE.

This is all started when a team in google developed and tested an attack named POODLE (Padding Oracle On Downgraded Legacy Encryption) which uncovered vulnerability in  Secure Sockets Layer (SSL) version 3 protocol or in short SSLv3.

SSLv3 is an obsolete but still used encryption in both older and new web browsers. (SSLv3 is a 18-year-old protocol which was replaced by the TLS protocol)

POODLE tries to force the connection between your web browser and the server to downgrade  to SSLv3. The POODLE attack takes advantage of the protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 and then uses this new vulnerability to decrypt select content within the SSL session. The decryption is done byte by byte and will generate  large number of connections between the client and server.

How do they do it?

An attacker can run a JavaScript agent on a website to get the victim’s browser to send cookie ­with HTTPS requests to https://xyz.com, intercept and modify the SSL records sent by the browser in such a way that there’s a non­ negligible chance that xyz.com will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies. Cookies

TLS 1.0 and newer versions perform more robust validation of the decrypted data and as such are not susceptible to the same problem. But for SSLv3 there’s no fix.

How bad is this and how does this affect you?

Secure connections primarily use TLS (the successor to SSL), most users become vulnerable because web browsers and servers will downgrade to SSLv3 if there are problems negotiating a TLS session. Most SSL/TLS implementations remain backwards compatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. An attacker performing a man-in-the-middle attack could trigger a protocol downgrade to SSLv3 and exploit this vulnerability to decrypt a subset of the encrypted communication and extract information from it. The POODLE vulnerability only works if the browser of the client and the server’s connection are both supporting SSLv3.

How to test if my browser is vulnerable ?

Go to poodletest.com website to test this.  If you see a poodle, you are vulnerable. If you see a  Springfield Terrier, you are safe.

http://www.bolet.org/TestSSLServer/ http://code.google.com/p/sslaudit/

What can I do to prevent this? Poodle vaccine?

As a end user, disable SSLv3 support in your web browser. If it’s disabled, POODLE can NOT downgrade your browser to it. To encourage security best practices I would strongly recommend using the highest version of TLS . For most browsers this should be TLS 1.2.

Will this affect my browsing experience?

This will have an impact on some older browsers. Websites that has already ended support for SSLv3 will become incompatible with older browsers and operating systems. Old browsers like Internet Explorer 6 running on Windows XP or older versions will see an SSL connection error.

SSL v3 will be disabled by default in future releases of many web browsers.

How to disable this at the server?

CloudFlare announced that it was disabling SSLv3 by default from its servers. So did many service providers.

If you are running Apache, just make this change in your configuration among the other SSL directives:

SSLProtocol All -SSLv2 -SSLv3

This disables SSL protocol versions 2 and 3.

How can developers prevent this?

.NET

Use the SecurityProtocol property to enable TLS.

For details on how to use the SecurityProtocol property, visit:

http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol(v=vs.110).as…

http://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx

As an example, to force TLS 1.2 in a C# .NET implementation, you’d use:

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

JAVA

NOTE: TLS 1.2 was first supported in JDK 7, and will be default in JDK 8: https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls

Use the SSLContext.getInstance method to enable TLS.

For details on how to use the SSLContext.getInstance method, visit:

http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String)

http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String,…

http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext

For example, to use the default security layer provider to enable TLS, you’d use:

object = SSLContext.getInstance(“TLS”);

To force TLS 1.2 while using Sun’s Java Secure Socket Extension (JSSE), you’d use:

object = SSLConnect.getInstance(“TLSv1.2”, “SunJSEE”);

cURL

Use the CURLOPT_SSLVERSION option to enable TLS.

For details on how to use the CURLOPT_SSLVERSION option, visit:

http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html

As an example, to force cURL to use TLS 1.0 or later, you’d use:

C/C++/C#:

curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);

PHP:

curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);

In cURL 7.34.0 or later, to force TLS 1.2, you’d use:

C/C++/C#:

curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

PHP:

curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

RailsCarma team geared up in full defence mode to plug all holes that were left open by this vulnerability. We applied the necessary patches to our applications to disable insecure SSL/TLS options.

References

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-POODLE-Information-Updated/ba-p/48163

http://arstechnica.com/security/2014/10/ssl-broken-again-in-poodle-attack/

https://zmap.io/sslv3/

https://www.imperialviolet.org/2014/10/14/poodle.html

http://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

http://www.theregister.co.uk/2014/10/16/poodle_analysis/

http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/

http://www.pcworld.com/article/2834015/security-experts-warn-of-poodle-attack-against-ssl-30.html

http://www.alertlogic.com/blog/poodle-man-middle-attack-sslv3/

https://www.us-cert.gov/ncas/alerts/TA14-290A

https://www.openssl.org/~bodo/ssl-poodle.pdf

http://www.makeuseof.com/tag/stop-poodle-from-biting-your-browser/

https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack

Disabling Poodle

https://www.linode.com/docs/security/security-patches/disabling-sslv3-for-poodle

http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566