Wednesday, 15 October 2014

POODLE SSLv3 Vulnerability

Bodo Möller, Thai Duong and Krzysztof Kotowicz from Google who discovered this, released a security advisory which you can find on OpenSSL website [2]. 
The Padding Oracle On Downgraded Legacy Encryption aka #POODLE vulnerability, has already a good write-up [1]. Jesper Jurcenoks explains the vulnerability on his blog [3] in a very detailed manner but at the same time, easy to understand. I am happy to see that Jesper used for his blog-post the logo I made for the poople vulnerability! :) Also, if you are thirsty for more technical details, you should also read this blog-post from ImperialViolet [4]. If you want to see some statistics on how vulnerable we are today in regards to this, you should read this article on netcraft [5]. The following post outlines the steps on how to disable SSLv3 [6]. If you wanna do a quick test and see if your browser supports SSLv3 regarding the poodle vulnerability, then you can visit: www.poodletest.comOn the other hand, www.howsmyssl.com can provide some useful information about the SSL/TLS client you used to render its page. Last but not least, if you need to a server given its domain name for this vulnerability, you may use www.poodlescan.com

CVE­-2014-­3566 has been allocated for this protocol vulnerability.

I had an idea for a logo for this vulnerability which I posted on twitter when the vulnerability came out and I would like to share it with you. We are trying to ditch SSLv3 for quite some time now, the logo had to look a little bit old style, retro and maybe vintage. Let me know what you think. ( you are free to use this logo, it would be nice if you reference it with: @drgfragkos )



Do you want to test manually?
Use this command: 
openssl s_client -connect google.com:443 -ssl3
If the handshake fails then the server doesn't support SSLv3 


Just a few words reagarding SSLv3:
SSL version 3.0 [RFC6101] is an obsolete and insecure protocol. While for most practical purposes it has been replaced by its successors TLS 1.0 [RFC2246], TLS 1.1 [RFC4346],  and TLS 1.2 [RFC5246], many TLS implementations remain backwards ­compatible with  SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. The protocol handshake provides for authenticated version negotiation, so normally the  latest protocol version common to the client and the server will be used. 

However, even if a client and server both support a version of TLS, the security level offered by SSLv3 is still relevant since many clients implement a protocol downgrade dance to work around server ­side interoperability bugs. 
The security Advisory [2], discusses how attackers can exploit the downgrade dance and break the cryptographic security of SSL 3.0. Also, the POODLE attack (Padding Oracle On Downgraded Legacy Encryption) allows them, for example, to steal “secure” HTTP cookies (or other bearer tokens such as HTTP Authorization header contents). The advisory also gives recommendations for both clients and servers on how to counter the attack: if disabling SSL 3.0 entirely is not acceptable out of interoperability concerns, TLS implementations should make use of TLS_FALLBACK_SCSV.

In order to disable the SSLv3 support on Nginx you need add after "ssl on;" the following line in the nginx configuration:
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;



[1] http://www.csoandy.com/files/dancing-poodles.html
[2] https://www.openssl.org/~bodo/ssl-poodle.pdf
[3] http://learning.criticalwatch.com/poodle/
[4] https://www.imperialviolet.org/2014/10/14/poodle.html
[5] http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html
[6] http://dave.harris.uno/poodle-vulnerability-and-disabling-sslv3/

No comments:

Post a Comment