Open Stack

On 2014-11-22 19:45:09 +1300 (+1300), Robert Collins wrote:
> Given the persistent risks of downgrade attacks, I think this does
> actually qualify as a security issue: not that its breaking, but
> that SSLv3 is advertised and accepted anywhere.

Which downgrade attacks? Outside of Web browser authors deciding it
was a good idea to bypass the normal TLS negotiation mechanism, as
long as both ends _support_ TLS then causing a downgrade within TLS
version negotiation to SSLv3 or earlier should not be possible. If
you're suggesting we strengthen against unknown future attacks,
that's a fine idea and is something we call "security hardening"
(not a vulnerability fix).

> The lines two lower:
>
>     try:
>         _SSL_PROTOCOLS["sslv2"] = ssl.PROTOCOL_SSLv2
>     except AttributeError:
>         pass
>
> Are even more concerning!

_SSL_PROTOCOLS is only used in sslutils.validate_ssl_version() which
is in turn used by a method in rpc.impl_kombu. Checking *all*
current branches of *all* official OpenStack projects in our Gerrit,
the only way it's called is when the kombu RPC backend is in use and
kombu_ssl_version is set in a configuration file. It will *allow*
explicit selection of insecure SSL versions (SSLv3 and SSLv2) by the
administrator--this isn't a "magically uses insecure protocols
without telling you" situation--merely providing the option to
configure use of a specific insecure protocol. (You can also
configure it not to use any encryption at all for that matter.)

I'm all for dropping this nonsense completely in master and also
backporting a patch to make this not spontaneously vomit when run on
platforms where SSLv3 is no longer available (perhaps something
similar to the SSLv2 try/except example above), but we shouldn't
backport a patch which suddenly breaks someone's cloud because they
made a conscious decision to configure it to use SSLv3 for RPC
communication. Visibly documenting (in the Security Guide or an
OSSN) that you should configure your RPC communication to use TLS
instead of SSLv2/3 is of course a great idea too.

My point is that suggesting there's a vulnerability here without
looking at how the code is used is sort of like shouting "fire" in a
crowded theater.

> That said, code like:
> https://github.com/mpaladin/python-amqpclt/blob/master/amqpclt/kombu.py#L101
> is truely egregious!

Yikes... glad I'm not on _their_ VMT instead!
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141122/92a24da2/attachment.pgp>