Re: Being vulnerable to POODLE

[Florian Weimer <fweimer () redhat com>]

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[1]

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