Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-25 Thread Thomas Goirand
On 11/23/2014 06:01 AM, Jeremy Stanley wrote:
 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.

I'm having a hard time figuring out in which case it would make sense to
do so. However...

On 11/23/2014 06:01 AM, Jeremy Stanley wrote:
 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.

I agree with that point, but also with your point about anticipation of
future issues. I think it would be a good idea to strengthen things, in
advance of possible downgrade attacks that may occur if we keep support
for SSLv3.

On 11/24/2014 01:09 AM, Doug Hellmann wrote:
 The only place things will be breaking is on the version of Python
 shipped by Debian where the constant used to set up the validation
 logic is no longer present in the SSL library. Let’s start by making
 the smallest change we can to fix that problem, and then move on.

Yes please! And I need this backported to Icehouse ASAP (as that's we're
shipping in Jessie). At this point, I prefer to let others who are
better than me at this sorts (sensitive) of patches do the work.

On 11/24/2014 01:09 AM, Doug Hellmann wrote:
 hat’s an easy patch for us to land, and I hope Thomas will update the
 patch he has already submitted based on feedback on that review.

Could someone take over my patch? :)
I'm quite busy doing other things, and it isn't my role to work on such
things directly. I often send a patch here and there when I see fit, but
here, I don't think I'm the best person to do so.

 I don't really mind if we continue to allow it, but at least we
 should move fast to have oslo-incubator fixed. I will need to do
 something fast for Icehouse in Sid/Jessie, as we're in freeze mode.
 Best would be to have the issue resolved before the next point
 release (currently set for May 14 2015).

 Sure. See my comments on your current review for what I think we need
 to do to handle the backwards-compatibility issues more clearly.

 Doug

Hum... git review -d  ? :)

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-25 Thread Brant Knudson
Could someone take over my patch? :)
 I'm quite busy doing other things, and it isn't my role to work on such
 things directly. I often send a patch here and there when I see fit, but
 here, I don't think I'm the best person to do so.


I updated the patch based on the comments so far:
https://review.openstack.org/#/c/136278/

Looks like it's failing the Jenkins check now due to unrelated issues.

- Brant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-23 Thread Doug Hellmann

On Nov 22, 2014, at 5:01 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 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.

It appears the option isn’t required, and that the default does what we would 
want as far as negotiating the best possible protocol. The only place things 
will be breaking is on the version of Python shipped by Debian where the 
constant used to set up the validation logic is no longer present in the SSL 
library. Let’s start by making the smallest change we can to fix that problem, 
and then move on.

As has been proposed, we can fix the Debian Python 2.7 issue by treating sslv3 
as sslv2 is handled in the code snippet above. That’s an easy patch for us to 
land, and I hope Thomas will update the patch he has already submitted based on 
feedback on that review.

After the short-term fix is merged, we can investigate deprecating the 
configuration option entirely. That change will require more work because we 
will be removing a configuration option. Someone will have to do the 
archaeology needed to understand why the option was added in the first place, 
so we don’t unwittingly risk breaking existing deployments. Was it added for 
completeness (because kombu supports it)? Was it added because some combination 
of kombu and rabbit needed the client to specify the setting because 
negotiation wasn’t implemented properly? Was there some other reason?

Doug

 
 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
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-23 Thread Robert Collins
On 23 November 2014 at 11:01, Jeremy Stanley fu...@yuggoth.org wrote:
 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

Thats my understanding too; while this code is targeted for kombu use,
I remain paranoid.

 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).

Fair enough.

 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.

Point taken. Sorry :)

-Rob



-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-22 Thread Donald Stufft

 On Nov 22, 2014, at 1:45 AM, Robert Collins robe...@robertcollins.net wrote:
 
 On 22 November 2014 08:11, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
 Death to SSLv3 IMO.
 
 Sure, we should avoid releasing new versions of things which assume
 SSLv3 support is present in underlying libraries/platforms (it's
 unclear to me why anyone even thought it was good to make that
 configurable to this degree in openstack-common, but it probably
 dates back to before the nova common split). But what we're talking
 about here is fixing a deployability/usability bug where the
 software is assuming the presence of something removed from a
 dependency on some platform. I'd rather not conflate it with
 knee-jerk SSLv3 Bad rhetoric which risks giving casual readers the
 impression there's some vulnerability here.
 
 Ceasing to assume the presence of SSLv3 support is a safe choice for
 the software in question. Forcing changes to stable branches for
 this should be taken on its merits as a normal bug, and not
 prioritized because of any perceived security impact.
 
 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.
 
 The lines two lower:
try:
_SSL_PROTOCOLS[sslv2] = ssl.PROTOCOL_SSLv2
except AttributeError:
pass
 
 Are even more concerning!
 
 That said, code like:
 https://github.com/mpaladin/python-amqpclt/blob/master/amqpclt/kombu.py#L101
 
 is truely egregious!
 
 :)
 

Yes this. SSLv3 isn’t a “Well as long as you have newer things enabled it’s
fine” it’s a “If you have this enabled at all it’s a problem”. As far as I
am aware without TLS_FALLBACK_SCSV a MITM who is willing to do active attacks
can force the connection over to the lowest protocol that a client and server
support. There is no way for the server to verify that the message sent from
the client that indicates their highest was not modified in transit.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-22 Thread Jeremy Stanley
On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote:
 Yes this. SSLv3 isn’t a “Well as long as you have newer things
 enabled it’s fine” it’s a “If you have this enabled at all it’s a
 problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM
 who is willing to do active attacks can force the connection over
 to the lowest protocol that a client and server support. There is
 no way for the server to verify that the message sent from the
 client that indicates their highest was not modified in transit.

IETF RFC 2246 disagrees with you on this. Please cite sources
(besides interactions with Web browsers that sidestep TLS version
negotiation a la POODLE). You're suggesting a vulnerability far
worse than e.g. CVE-2014-3511 in OpenSSL, which would definitely be
something I haven't seen disclosed to date. It's very easy to fall
into the protocol shaming trap, and I don't think it's at all
helpful.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-22 Thread Donald Stufft
I'm in my phone but rfc 2246 says that there are many ways in which an attacker 
can attempt to make an attacker drop down to the least secure option they both 
support. It's like the second or third paragraph of that section. 


 On Nov 22, 2014, at 4:00 PM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote:
 Yes this. SSLv3 isn’t a “Well as long as you have newer things
 enabled it’s fine” it’s a “If you have this enabled at all it’s a
 problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM
 who is willing to do active attacks can force the connection over
 to the lowest protocol that a client and server support. There is
 no way for the server to verify that the message sent from the
 client that indicates their highest was not modified in transit.
 
 IETF RFC 2246 disagrees with you on this. Please cite sources
 (besides interactions with Web browsers that sidestep TLS version
 negotiation a la POODLE). You're suggesting a vulnerability far
 worse than e.g. CVE-2014-3511 in OpenSSL, which would definitely be
 something I haven't seen disclosed to date. It's very easy to fall
 into the protocol shaming trap, and I don't think it's at all
 helpful.
 -- 
 Jeremy Stanley
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-22 Thread Donald Stufft
I refreshed my memory and I was wrong about the specific attack. However the 
point still stands that both the rfc and respected folks such as Thomas porin 
state that you should look at the version negotiation as a way to selectively 
enable new features not as a way to ensure that a connection uses a secure 
option when both a secure and an insecure option exist. 

http://crypto.stackexchange.com/a/10496


 On Nov 22, 2014, at 4:13 PM, Donald Stufft don...@stufft.io wrote:
 
 I'm in my phone but rfc 2246 says that there are many ways in which an 
 attacker can attempt to make an attacker drop down to the least secure option 
 they both support. It's like the second or third paragraph of that section. 
 
 
 On Nov 22, 2014, at 4:00 PM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote:
 Yes this. SSLv3 isn’t a “Well as long as you have newer things
 enabled it’s fine” it’s a “If you have this enabled at all it’s a
 problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM
 who is willing to do active attacks can force the connection over
 to the lowest protocol that a client and server support. There is
 no way for the server to verify that the message sent from the
 client that indicates their highest was not modified in transit.
 
 IETF RFC 2246 disagrees with you on this. Please cite sources
 (besides interactions with Web browsers that sidestep TLS version
 negotiation a la POODLE). You're suggesting a vulnerability far
 worse than e.g. CVE-2014-3511 in OpenSSL, which would definitely be
 something I haven't seen disclosed to date. It's very easy to fall
 into the protocol shaming trap, and I don't think it's at all
 helpful.
 -- 
 Jeremy Stanley
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-22 Thread Jeremy Stanley
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


signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-22 Thread Jeremy Stanley
On 2014-11-22 16:33:52 -0500 (-0500), Donald Stufft wrote:
 I refreshed my memory and I was wrong about the specific attack.
 However the point still stands that both the rfc and respected
 folks such as Thomas porin state that you should look at the
 version negotiation as a way to selectively enable new features
 not as a way to ensure that a connection uses a secure option when
 both a secure and an insecure option exist.
[...]

I don't disagree with those points, but if you read the source code
in question that's not what it's doing anyway. The problem at hand
is that we allow you to configure RPC over SSLv3 (that's an
attractive nuisance sure), but the way the config validation is
written it explodes violently on platforms which have stripped out
support for SSLv3 even if you didn't configure your system to use
SSLv3 (not a security bug, just a bug bug). TLS negotiation on the
other hand is being left entirely up to the system, so its behaviors
are determined and managed outside of OpenStack anyway.

Unfortunately now too many people are conditioned to fire off panic
replies when they see terms like SSLv3 or MD5 or DES or whatever
without evaluating the specifics of the situation. That makes it
very hard to talk about normal bugs, and causes vulnerability
managers to have to spend hours on PR damage control instead.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Doug Hellmann

On Nov 21, 2014, at 4:56 AM, Thomas Goirand z...@debian.org wrote:

 Hi,
 
 Trying to rebuild Neutron Juno in Sid, I get so many of these failures:
 
 Traceback (most recent call last):
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py,
 line 137, in setUp
super(OVS_Lib_Test, self).setUp()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 128, in setUp
self.setup_rpc_mocks()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 150, in setup_rpc_mocks
self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 48, in __init__
'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 24, in _import_opts
__import__(module)
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 420, in module
class Connection(object):
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 497, in Connection
sslv3: ssl.PROTOCOL_SSLv3
 AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
 
 Having a deeper look into the issue, I saw the following changelog in
 Python 2.7 (this was uploaded 3 days ago in Sid):
 
  * Allow building and testing without SSLv3 support (Kurt Roeckx).
Closes: #768611.
 
 Having a closer look at oslo.messaging reveals this in
 oslo/messaging/_drivers/impl_rabbit.py:
 
_SSL_PROTOCOLS = {
tlsv1: ssl.PROTOCOL_TLSv1,
sslv23: ssl.PROTOCOL_SSLv23,
sslv3: ssl.PROTOCOL_SSLv3
}
 
 Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
 fixed the build of Neutron.
 
 Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
 of openssl, removed support for SSLv3, because of potential security
 issues (downgrade attacks), which were revealed by the infamous POODLE bug.
 
 Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
 options in oslo.messaging.
 
 I thought this deserved explanations so that the review here can be
 understood better:
 https://review.openstack.org/136278

The patch drops support entirely, but as Brant points out that isn’t 
backwards-compatible. I’d be interested to hear from the security team about 
whether the security issues trump the backwards compatibility issues here or if 
we should maintain optional support (that is, allow v3 if we detect that we can 
use it because the symbol is present). 

Thomas, can you get one or two of the security team to comment on the patch?

Doug

 
 This should also be backported to the Icehouse and Juno releases. My
 package for Sid has already been updated with this patch, and I will ask
 for an unblock by the Debian release team, so that oslo.messaging
 migrates to Jessie. I'm about to also do the work for oslo.messaging
 1.4.1 in Experimental.
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Jeremy Stanley
On 2014-11-21 09:38:00 -0500 (-0500), Doug Hellmann wrote:
 The patch drops support entirely, but as Brant points out that
 isn’t backwards-compatible. I’d be interested to hear from the
 security team about whether the security issues trump the
 backwards compatibility issues here or if we should maintain
 optional support (that is, allow v3 if we detect that we can use
 it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on
 the patch?

The discussion in https://launchpad.net/bugs/1381365 is relevant to
this topic.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Donald Stufft

 On Nov 21, 2014, at 11:51 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2014-11-21 09:38:00 -0500 (-0500), Doug Hellmann wrote:
 The patch drops support entirely, but as Brant points out that
 isn’t backwards-compatible. I’d be interested to hear from the
 security team about whether the security issues trump the
 backwards compatibility issues here or if we should maintain
 optional support (that is, allow v3 if we detect that we can use
 it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on
 the patch?
 
 The discussion in https://launchpad.net/bugs/1381365 is relevant to
 this topic.
 -- 
 Jeremy Stanley
 

Death to SSLv3 IMO.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Thomas Goirand
On 11/21/2014 10:38 PM, Doug Hellmann wrote:
 
 On Nov 21, 2014, at 4:56 AM, Thomas Goirand z...@debian.org wrote:
 
 Hi,

 Trying to rebuild Neutron Juno in Sid, I get so many of these failures:

 Traceback (most recent call last):
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py,
 line 137, in setUp
super(OVS_Lib_Test, self).setUp()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 128, in setUp
self.setup_rpc_mocks()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 150, in setup_rpc_mocks
self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 48, in __init__
'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 24, in _import_opts
__import__(module)
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 420, in module
class Connection(object):
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 497, in Connection
sslv3: ssl.PROTOCOL_SSLv3
 AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'

 Having a deeper look into the issue, I saw the following changelog in
 Python 2.7 (this was uploaded 3 days ago in Sid):

  * Allow building and testing without SSLv3 support (Kurt Roeckx).
Closes: #768611.

 Having a closer look at oslo.messaging reveals this in
 oslo/messaging/_drivers/impl_rabbit.py:

_SSL_PROTOCOLS = {
tlsv1: ssl.PROTOCOL_TLSv1,
sslv23: ssl.PROTOCOL_SSLv23,
sslv3: ssl.PROTOCOL_SSLv3
}

 Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
 fixed the build of Neutron.

 Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
 of openssl, removed support for SSLv3, because of potential security
 issues (downgrade attacks), which were revealed by the infamous POODLE bug.

 Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
 options in oslo.messaging.

 I thought this deserved explanations so that the review here can be
 understood better:
 https://review.openstack.org/136278
 
 The patch drops support entirely, but as Brant points out that isn’t 
 backwards-compatible. I’d be interested to hear from the security team about 
 whether the security issues trump the backwards compatibility issues here or 
 if we should maintain optional support (that is, allow v3 if we detect that 
 we can use it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on the patch?
 
 Doug

Do you mean the Debian security team? Or the OpenStack one?

For Debian, what happened is that Kurt, who maintains OpenSSL in Debian,
simply disabled it. He sent a patch for Python to make build and work
without SSLv3 support in OpenSSL. So I believe that in Debian, we want
SSLv3 to be completely gone. It is my view as well that we shouldn't
continue to support it at all.

Also, SSLv3 is in oslo-incubator (in all branches, including master,
stable/juno and stable/icehouse). We should remove it completely from
there as well, or at least allow it to work without it in Python (that
is, without ssl.PROTOCOL_SSLv3 being defined).

I don't really mind if we continue to allow it, but at least we should
move fast to have oslo-incubator fixed. I will need to do something fast
for Icehouse in Sid/Jessie, as we're in freeze mode. Best would be to
have the issue resolved before the next point release (currently set for
May 14 2015).

Cheers,

Thomas Goirand (zigo)


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Doug Hellmann

On Nov 21, 2014, at 1:53 PM, Thomas Goirand tho...@goirand.fr wrote:

 On 11/21/2014 10:38 PM, Doug Hellmann wrote:
 
 On Nov 21, 2014, at 4:56 AM, Thomas Goirand z...@debian.org wrote:
 
 Hi,
 
 Trying to rebuild Neutron Juno in Sid, I get so many of these failures:
 
 Traceback (most recent call last):
 File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py,
 line 137, in setUp
   super(OVS_Lib_Test, self).setUp()
 File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 128, in setUp
   self.setup_rpc_mocks()
 File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 150, in setup_rpc_mocks
   self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
 File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 48, in __init__
   'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
 File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 24, in _import_opts
   __import__(module)
 File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 420, in module
   class Connection(object):
 File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 497, in Connection
   sslv3: ssl.PROTOCOL_SSLv3
 AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
 
 Having a deeper look into the issue, I saw the following changelog in
 Python 2.7 (this was uploaded 3 days ago in Sid):
 
 * Allow building and testing without SSLv3 support (Kurt Roeckx).
   Closes: #768611.
 
 Having a closer look at oslo.messaging reveals this in
 oslo/messaging/_drivers/impl_rabbit.py:
 
   _SSL_PROTOCOLS = {
   tlsv1: ssl.PROTOCOL_TLSv1,
   sslv23: ssl.PROTOCOL_SSLv23,
   sslv3: ssl.PROTOCOL_SSLv3
   }
 
 Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
 fixed the build of Neutron.
 
 Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
 of openssl, removed support for SSLv3, because of potential security
 issues (downgrade attacks), which were revealed by the infamous POODLE bug.
 
 Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
 options in oslo.messaging.
 
 I thought this deserved explanations so that the review here can be
 understood better:
 https://review.openstack.org/136278
 
 The patch drops support entirely, but as Brant points out that isn’t 
 backwards-compatible. I’d be interested to hear from the security team about 
 whether the security issues trump the backwards compatibility issues here or 
 if we should maintain optional support (that is, allow v3 if we detect that 
 we can use it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on the patch?
 
 Doug
 
 Do you mean the Debian security team? Or the OpenStack one?

Sorry, I meant the OpenStack team.

 
 For Debian, what happened is that Kurt, who maintains OpenSSL in Debian,
 simply disabled it. He sent a patch for Python to make build and work
 without SSLv3 support in OpenSSL. So I believe that in Debian, we want
 SSLv3 to be completely gone. It is my view as well that we shouldn't
 continue to support it at all.
 
 Also, SSLv3 is in oslo-incubator (in all branches, including master,
 stable/juno and stable/icehouse). We should remove it completely from
 there as well, or at least allow it to work without it in Python (that
 is, without ssl.PROTOCOL_SSLv3 being defined).

We’re in the process of removing sslutils from the incubator entirely. 
https://review.openstack.org/#/c/126505/

 
 I don't really mind if we continue to allow it, but at least we should
 move fast to have oslo-incubator fixed. I will need to do something fast
 for Icehouse in Sid/Jessie, as we're in freeze mode. Best would be to
 have the issue resolved before the next point release (currently set for
 May 14 2015).

Sure. See my comments on your current review for what I think we need to do to 
handle the backwards-compatibility issues more clearly.

Doug

 
 Cheers,
 
 Thomas Goirand (zigo)
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Jeremy Stanley
On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
 Death to SSLv3 IMO.

Sure, we should avoid releasing new versions of things which assume
SSLv3 support is present in underlying libraries/platforms (it's
unclear to me why anyone even thought it was good to make that
configurable to this degree in openstack-common, but it probably
dates back to before the nova common split). But what we're talking
about here is fixing a deployability/usability bug where the
software is assuming the presence of something removed from a
dependency on some platform. I'd rather not conflate it with
knee-jerk SSLv3 Bad rhetoric which risks giving casual readers the
impression there's some vulnerability here.

Ceasing to assume the presence of SSLv3 support is a safe choice for
the software in question. Forcing changes to stable branches for
this should be taken on its merits as a normal bug, and not
prioritized because of any perceived security impact.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Robert Collins
On 22 November 2014 08:11, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
 Death to SSLv3 IMO.

 Sure, we should avoid releasing new versions of things which assume
 SSLv3 support is present in underlying libraries/platforms (it's
 unclear to me why anyone even thought it was good to make that
 configurable to this degree in openstack-common, but it probably
 dates back to before the nova common split). But what we're talking
 about here is fixing a deployability/usability bug where the
 software is assuming the presence of something removed from a
 dependency on some platform. I'd rather not conflate it with
 knee-jerk SSLv3 Bad rhetoric which risks giving casual readers the
 impression there's some vulnerability here.

 Ceasing to assume the presence of SSLv3 support is a safe choice for
 the software in question. Forcing changes to stable branches for
 this should be taken on its merits as a normal bug, and not
 prioritized because of any perceived security impact.

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.

The lines two lower:
try:
_SSL_PROTOCOLS[sslv2] = ssl.PROTOCOL_SSLv2
except AttributeError:
pass

Are even more concerning!

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

is truely egregious!

:)

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev