Date: Mon, 28 Dec 2015 18:22:37 +0100 From: Florian Weimer <fweimer@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: Being vulnerable to POODLE On 12/28/2015 04:55 PM, Sevan Janiyan wrote: > Hi, > > On 28/12/2015 14:32, Florian Weimer wrote: >> How so? >> >> With some OpenSSL versions, it disables the 0/n split to mitigate a >> *different* CBC vulnerability in TLS 1.0, and the client code explicitly >> prevents OpenSSL from using TLS 1.1 and later. > > SSLv23_server_method() is called to setup a server without any > restrictions & SSL_CTX_set_options() sets SSL_OP_ALL on the context. > The change I'm proposing explicitly disables the use of SSLv2/v3 so that > we're not reliant on the SSL library (which may be out of date?) to > impose restriction. Having SSL 3.0 support enabled does not mean that a MITM attacker can force a downgrade to SSL 3.0. The vulnerability response to POODLE was somewhat botched and initially did not fix the actual vulnerability (insecure protocol downgrade in web browsers). I think as far as FLOSS is concerned, this has since been corrected, so offering SSL 3.0 support does not longer result in connections which are vulnerable to POODLE. Clients which offered SSL 3.0 support but did not perform an out-of-protocol downgrade (like web browsers did) were not vulnerable, either. > Looking up the documentation before I reply, it seems that by using the > SSL_OP_ALL setting, the mitigation you mention is actually disabled. See > SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS & SSL_OP_ALL on Yes, this is what my meant, the documented SSL_OP_ALL setting is not really safe. But this is a different vulnerability from POODLE. Florian
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ