Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
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
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
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
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
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
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
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
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
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
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
[openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
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
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
Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
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
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
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
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
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
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
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
