Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Cinder |
High
|
Ibad Khan | ||
| OpenStack Identity (keystone) |
High
|
Daniel Gollub | ||
| OpenStack Object Storage (swift) |
Undecided
|
Unassigned | ||
| OpenStack Security Advisory |
Undecided
|
Unassigned | ||
| OpenStack Security Notes |
High
|
Robert Clark | ||
| neutron |
Undecided
|
Daniel Gollub | ||
| oslo.vmware |
Medium
|
Davanum Srinivas (DIMS) | ||
| python-keystoneclient |
Medium
|
Jamie Lennox |
Bug Description
Grant Murphy from Red Hat reported usage of httplib.
"""
The following files use httplib.
keystone/
keystone/
keystone/
vendor/
AFAICT HTTPSConnection does not validate server certificates and
should be avoided. This is fixed in Python 3, however in 2.X no
validation occurs. I suspect this is also applicable to most OpenStack
modules that make HTTPS client calls.
Similar problems were found in ovirt:
https:/
With solutions for ovirt:
http://
http://
"""
CVE References
Thierry Carrez (ttx) wrote : | #1 |
Thierry Carrez (ttx) wrote : | #2 |
Note: at first glance some calls seem to be used for test connections which are likely to be local and/or not contain any useful information. We need to carefully review the various cases before calling this a vulnerability.
Changed in ossa: | |
status: | New → Incomplete |
Thierry Carrez (ttx) wrote : | #3 |
So, for Keystone:
* keystone/
* keystone/
I suspect most of the others will be in the same case (servers making HTTPS connections to other local servers) so the MiM risk is limited. To give another data point, most Swift internal server-to-server communications are not even encrypted.
Dolph Mathews (dolph) wrote : | #4 |
Regarding keystone.
Chuck Thier (cthier) wrote : | #5 |
So for Swift:
swift.common.
John Dickinson (notmyname) wrote : | #6 |
Marking as invalid in Swift since it's not used
Changed in swift: | |
status: | New → Invalid |
Thierry Carrez (ttx) wrote : | #7 |
For Cinder:
HTTPSConnection is used in Zadara driver to send commands to VPSA controller (if use_ssl = True), as well as in the Solidfire driver to communicate with SolidFire devices.
./cinder/
./cinder/
The third instance is in unit tests where it's not so much of a problem.
Changed in cinder: | |
status: | New → Confirmed |
Changed in keystone: | |
status: | New → Confirmed |
Thierry Carrez (ttx) wrote : | #8 |
For Nova:
plugins/
plugins/
nova/virt/
nova/api/
nova/scheduler/
(*) Interestingly, reading files uses urllib2.urlopen, which does not do cert verification either :)
Changed in nova: | |
status: | New → Confirmed |
Thierry Carrez (ttx) wrote : | #9 |
For Quantum:
quantum/
quantum/
quantum/
Changed in quantum: | |
status: | New → Confirmed |
Thierry Carrez (ttx) wrote : | #10 |
So all the occurences seem to be for serverside node-to-node communication that could be assumed to happen on private networks. That said, all those "use_ssl" give a false sense of security (about the same as communicating unencrypted). The inability to specify a ca_file should serve as a hint that it's not really safe, but that subtlety may be lost on most.
I'm not 100% certain to classify this as an exploitable vulnerability that warrants embargoed disclosure -- we could consider this as missing proper internal encryption features between internal nodes and remind people (through OSSN) to deploy over secure private management networks (as Swift already does). The only thing which makes this a potential vulnerability is that the "use_ssl" parameters where available may induce people into thinking they are safe while they are not...
Thoughts ?
summary: |
- Potentially insecure use of httplib.HTTPSConnection + Some server-side 'SSL' communication fails to check certificates (use of + HTTPSConnection) |
Jeremy Stanley (fungi) wrote : | #11 |
SSL/TLS capability likely still needs to remain available for compatibility with third-party systems, where administrators may be deploying canned configurations with all plaintext protocols disabled. I agree the short term fix is to disable any default unauthenticated encryption across the board, surround the config knobs for it with shouty disclaimers and possibly also log warning/info level messages when services are started running in this manner.
Long-term fix is of course to pathologically assume compromised/hostile internal networks, encrypt everywhere and perform peer validation using some pluggable mechanism (Kerberos, private CA, DNSSec+SSHFP, whatever) but I expect that's a very long way off.
Thierry Carrez (ttx) wrote : | #12 |
Indeed... The SSL support in there is more to support the case where that other service is configured to only accept SSL client connections... not to really encrypt internal traffic.
I'm leaning towards issuing an OSSN about this, and fix it over time with additional features. Adding Rob Clark to the discussion.
Dolph Mathews (dolph) wrote : | #13 |
keystoneclient.
Thierry Carrez (ttx) wrote : | #14 |
@Dolph: now /that/ is a clear vulnerability. Client to server connections should always be properly encrypted. Could you open a separate (private security) bug about that ?
Dolph Mathews (dolph) wrote : | #15 |
Well, generally keystoneclient.
Changed in python-keystoneclient: | |
status: | New → Confirmed |
Thierry Carrez (ttx) wrote : | #16 |
@Dolph: sorry I misread your comment (client vs. middleware). It's fine to keep on this bug.
Changed in keystone: | |
importance: | Undecided → Medium |
Changed in python-keystoneclient: | |
importance: | Undecided → Medium |
Robert Clark (robert-clark) wrote : | #17 |
We need to move away from this pervasive assumption that private networks are secure. You only have to look at the 6 different hypervisor vulnerabilities released in the last 2ish months to understand that people are starting to come after virt tech in a big way and a full IaaS stack has a hell of an attack surface.
NSA, HP and a bunch of others all design their networks assuming some hostile actor is already inside and use various methods to try and contain an attacker. If an option to enable SSL is made available to deployers then it should provide most of the protections that you'd expect. Now we all know that SSL is actually quite the pain to configure correctly and perhaps there are areas we can help make life easier for deployers there too.
I vote for keeping this embargoed. OpenStack as-is offers SSL on some connections. Deployers who've turned on SSL for x,y,z connections will have done so to meet assurance requirements they've decided upon for their deployment. If this issue is disclosed without a fix it leaves deployers in a difficult position.
If you believe there's warrant for a wider OSSN on this issue I'd be happy to arrange for one to be drafted.
Thierry Carrez (ttx) wrote : | #18 |
> We need to move away from this pervasive assumption that private networks are secure.
I can certainly relate to that. The question is, when does a missing important security feature become a vulnerability ?
Advertising encryption between components while not properly implementing it is definitely a vulnerability in my book (we issued OSSAs for that in the past, and have another in the pipe coming up). In the precise case of this bug it's slightly more blurry: "use_ssl" parameters are more to allow servers to connect to other services that are configured to only accept SSL, than to "encrypt internal communications". I agree that it can still be seen as "advertising encryption while not properly encrypting" though... so I'm OK with embargo/OSSA on this.
The remaining question is how to fix this in stable branches ? We are not supposed to introduce new configuration parameters in stable branches. We also need to not break anyone on upgrade, and there is no good default value for ca_file. Could we piggyback on a Python library that uses the local system cert store ?
Robert Clark (robert-clark) wrote : | #19 |
Python libs in general seem pretty dire at using the default store, I think perhaps M2Crypto does, but that's really just wrapping OpenSSL anyway...
Jeremy Stanley (fungi) wrote : | #20 |
It's a perennial debate in the Python community, the most recent thread on the python-dev ML being http://
The python-nss module is LGPL and could be leveraged to access the builtin default NSS certdata... the real questions are around maturity and cross-platform support if you're wanting something which can leverage system-level cert databases and platform-specific trustdb management tools.
But by turning on certificate verification in existing deployments you're going to instabreak people who enabled HTTPS to talk to some random third-party device which has an expired, self-signed, CN-mismatched or otherwise nonconformant certificate on it because they saw there was a crypto option and decided to turn the knob all the way up without understanding the benefits (or lack thereof in this case).
Thierry Carrez (ttx) wrote : | #21 |
So... It looks like something we can't "fix" as a simple security patch (as it would add a new feature and break on upgrade), but that we should definitely:
* implement as a new feature in an upcoming version (the sooner the better)
* document as unsafe in previous versions (OSSN ?)
Does that work for everyone ?
Jeremy Stanley (fungi) wrote : | #22 |
I agree that sounds like the most pragmatic approach. I don't see a reasonable way to "fix" this in stable releases without introducing new dependencies, adding config options, and potentially breaking existing production deployments. An OSSN and documentation improvements describing the actual intent for internal HTTPS support in these components seems like the only way to avoid having this embargoed more or less indefinitely.
Also, once the bug is an open/public hardening feature request it becomes much easier to pool the developer community to collectively solve instances of this much more quickly.
Thierry Carrez (ttx) wrote : | #23 |
Kurt, Robert, would that work for you ?
Robert Clark (robert-clark) wrote : | #24 |
Works for me, throw it on the OSSN queue.
Changed in ossn: | |
importance: | Undecided → High |
status: | New → In Progress |
assignee: | nobody → Robert Clark (robert-clark) |
Thierry Carrez (ttx) wrote : | #25 |
Ok, so we should:
* implement as a new feature in an upcoming version (the sooner the better)
* document as unsafe in previous versions (OSSN)
Any taker to work on that ?
Changed in ossa: | |
status: | Incomplete → Won't Fix |
tags: | added: security |
information type: | Private Security → Public |
Jamie Lennox (jamielennox) wrote : | #26 |
I've got a patch or two related to this waiting already
Changed in python-keystoneclient: | |
assignee: | nobody → Jamie Lennox (jamielennox) |
Robert Clark (robert-clark) wrote : | #27 |
Some SSL-Enabled connections fail to perform basic certificate checks
----
### Summary ###
In many places OpenStack components use Python 2.x HTTPSConnection to establish an SSL connection between endpoints. This does not provide many of the assurances one would expect when using SSL and leaves connections open to potential man-in-the-middle attacks
### Affected Services / Software ###
keystone/
keystone/
keystone/
vendor/
<<<<OTHERS NEED TO BE ADDED HERE>>>>>
### Discussion ###
A secure SSL session relies on validation of a X.509 certificate. Basic checks include:
* Is the certificate signed by a CA I recognize
* Has the CA revoked this certificate
* Does the common name on the certificate match the server I'm trying to reach
The HTTPSConnection class is used in a large number of locations and fails to check that certificates are signed by a valid authority. Without that check in place, the following checks (some highlighted above) are largely invalid.
The result is that an attacker who has access to the network traffic between two endpoints relying on HTTPSConnection can trivially create a certificate that will be accepted by HTTPSConnection as valid - allowing the attacker to intercept, read and modify traffic that should be encrypted by SSL.
### Recommended Actions ###
<<<< MORE INVESTIGATION REQUIRED here on short-long term options >>>>
### Contacts / References ###
This OSSN : https:/
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https:/
Changed in python-keystoneclient: | |
status: | Confirmed → In Progress |
Dolph Mathews (dolph) wrote : | #28 |
Jamie- can you provide a link to your patch/review here?
Jamie Lennox (jamielennox) wrote : | #29 |
It appears that the new Partial-Bug syntax doesn't do an automatic link anymore.
python-
https:/
Jeremy Stanley (fungi) wrote : | #30 |
It only adds the review link on patchset #1 (to avoid spamming bug subscribers with comments). You didn't mention this bug in your commit message until patchset #3 of that review.
Reviewed: https:/
Committed: http://
Submitter: Jenkins
Branch: master
commit 20e166fd8a943ee
Author: Jamie Lennox <email address hidden>
Date: Mon Aug 12 13:12:27 2013 +1000
Replace HttpConnection in auth_token with Requests
Requests is becoming the standard way of doing http communication, it
also vastly simplifies adding other authentication mechanisms. Use it in
the auth_token middleware.
This adds the ability to specify a CA file that will be used to verify a
HTTPS connections or insecure to specifically ignore HTTPS validation.
SecurityImpact
DocImpact
Partial-Bug: #1188189
Change-Id: Iae94329e7abd10
Robert Clark (robert-clark) wrote : | #32 |
Some SSL-Enabled connections fail to perform basic certificate checks
----
### Summary ###
In many places OpenStack components use Python 2.x HTTPSConnection to establish an SSL connection between endpoints. This does not provide many of the assurances one would expect when using SSL and leaves connections open to potential man-in-the-middle attacks
### Affected Services / Software ###
keystone/
keystone/
keystone/
vendor/
### Discussion ###
A secure SSL session relies on validation of a X.509 certificate. Basic checks include:
* Is the certificate signed by a CA I recognize
* Has the CA revoked this certificate
* Does the common name on the certificate match the server I'm trying to reach
The HTTPSConnection class is used in a large number of locations and fails to check that certificates are signed by a valid authority. Without that check in place, the following checks (some highlighted above) are largely invalid.
The result is that an attacker who has access to the network traffic between two endpoints relying on HTTPSConnection can trivially create a certificate that will be accepted by HTTPSConnection as valid - allowing the attacker to intercept, read and modify traffic that should be encrypted by SSL.
### Recommended Actions ###
Consider using an up to date version of the keystone client http://
### Contacts / References ###
This OSSN : https:/
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https:/
Robert Clark (robert-clark) wrote : | #33 |
Some SSL-Enabled connections fail to perform basic certificate checks
----
### Summary ###
In many places OpenStack components use Python 2.x HTTPSConnection to establish an SSL connection between endpoints. This does not provide many of the assurances one would expect when using SSL and leaves connections open to potential man-in-the-middle attacks
### Affected Services / Software ###
keystone/
keystone/
keystone/
vendor/
### Discussion ###
A secure SSL session relies on validation of a X.509 certificate. Basic checks include:
* Is the certificate signed by a CA I recognize
* Has the CA revoked this certificate
* Does the common name on the certificate match the server I'm trying to reach
The HTTPSConnection class is used in a large number of locations and fails to check that certificates are signed by a valid authority. Without that check in place, the following checks (some highlighted above) are largely invalid.
The result is that an attacker who has access to the network traffic between two endpoints relying on HTTPSConnection can trivially create a certificate that will be accepted by HTTPSConnection as valid - allowing the attacker to intercept, read and modify traffic that should be encrypted by SSL.
### Recommended Actions ###
Some projects have updated their code to be more secure, others have not. The OSSG suggest cloud deployers check the status of bug https:/
### Contacts / References ###
This OSSN : https:/
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https:/
Robert Clark (robert-clark) wrote : | #34 |
Posted to OpenStack ML 19-9-13
Changed in ossn: | |
status: | In Progress → Fix Released |
Changed in python-keystoneclient: | |
status: | In Progress → Fix Released |
Daniel Gollub (d-gollub) wrote : | #35 |
cinder: Replace HTTPSConnection in solidfire driver
https:/
Changed in cinder: | |
assignee: | nobody → Daniel Gollub (d-gollub) |
status: | Confirmed → In Progress |
Daniel Gollub (d-gollub) wrote : | #36 |
cinder: Replace httplib.
https:/
Fix proposed to branch: master
Review: https:/
Changed in keystone: | |
assignee: | nobody → Daniel Gollub (d-gollub) |
status: | Confirmed → In Progress |
Fix proposed to branch: master
Review: https:/
Changed in neutron: | |
assignee: | nobody → Daniel Gollub (d-gollub) |
status: | Confirmed → In Progress |
Daniel Gollub (d-gollub) wrote : | #39 |
For the record:
* quantum/
this one has an ongoing blueprint bsn-certificate
Fix proposed to branch: master
Review: https:/
John Griffith (john-griffith) wrote : | #41 |
So Daniel I have to say AWESOME job picking this up and running with it. I'm working on figuring out how to do this without breaking existing setups; although maybe somebody already has an idea off the top of their head.
I did want to clarify though, I think we need to make sure that everywhere this is proposed it doesn't break existing setups or upgrades. I'm not sure I was clear about that in the one version but it's going to be a critical piece of this. If we can automate the switch (which I think and hope we can) then at the very least we're going to need a very BOLD and EXPLICIT warning and instructions in the Release Notes and in the documents on how to keep from losing your cloud.
Changed in nova: | |
assignee: | nobody → Xurong Yang (idopra) |
Daniel Gollub (d-gollub) wrote : | #42 |
Random idea:
Maybe this is something which should be discussed/handled by the individual OpenStack distributors/
They could handle this inside their packages of cinder (or other components)? With pre-/post-scripts while upgrading the package?
All other automatic approaches were it disables SSL verification - or tolerates failing verification would let us end-up with the same security issue again - I guess.
I do not have a better idea either. But maybe we could use the Icehouse release and stress this fundamental change in Upgrade notes/instruction. And switch to SSL verification by default across all the identified OpenStack components.
Introducing some logic like: if the configured HTTPS URL holds an IP address instead of a DNS name, "very likely" SSL verification is not going to succeed so the code falls back to ssl_insecure=True .... or something like that - I would not recommend to do. Since it would silently hide the fact that the current setup is not as secure as one would think.
Not quite sure if just logging that SSL verification failed and continuing with ssl_insecure=True would "solve" it either in a correct fashion.
Maybe security- and release folks should decide to go once through this burden with the Icehouse release or not. And try to warn the admins ahead in Release Notes and Upgrade Instruction to verify if their setup would pass SSL verification - or not.
Fix proposed to branch: master
Review: https:/
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit 0f9652d92e175a1
Author: Daniel Gollub <email address hidden>
Date: Sun Feb 23 09:30:00 2014 +0100
Replace httplib.
SSL Verification is from now on enabled by default for the
TestOpenSta
httplib.
Intention is to reduce noise of audits/scanners which look for Python 2.x
httplib.
of httplib.
Change-Id: Ic0352cf453d5c4
Partial-Bug: 1188189
Changed in neutron: | |
assignee: | Daniel Gollub (d-gollub) → Kevin Benton (kevinbenton) |
Changed in neutron: | |
assignee: | Kevin Benton (kevinbenton) → Daniel Gollub (d-gollub) |
Changed in neutron: | |
assignee: | Daniel Gollub (d-gollub) → Kevin Benton (kevinbenton) |
Changed in neutron: | |
assignee: | Kevin Benton (kevinbenton) → Mark McClain (markmcclain) |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit 7255e056092f034
Author: Kevin Benton <email address hidden>
Date: Sun Feb 2 20:46:18 2014 -0800
BigSwitch: Add SSL Certificate Validation
This patch adds the option to use SSL certificate
validation on the backend controller using SSH-style
sticky authentication, individual trusted
certificates, and/or certificate authorities.
Also adds caching of connections to deal with
increased overhead of TLS/SSL handshake.
Default is now sticky-style enforcement.
Partial-Bug: 1188189
Implements: blueprint bsn-certificate
Change-Id: If0bab196495c49
Changed in neutron: | |
assignee: | Mark McClain (markmcclain) → Daniel Gollub (d-gollub) |
Changed in keystone: | |
milestone: | none → icehouse-rc1 |
importance: | Medium → High |
Changed in cinder: | |
importance: | Undecided → High |
milestone: | none → icehouse-rc1 |
Changed in keystone: | |
assignee: | Daniel Gollub (d-gollub) → Dolph Mathews (dolph) |
Changed in keystone: | |
assignee: | Dolph Mathews (dolph) → Brant Knudson (blk-u) |
Changed in keystone: | |
assignee: | Brant Knudson (blk-u) → Daniel Gollub (d-gollub) |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit 5bd4c2984d32962
Author: Daniel Gollub <email address hidden>
Date: Wed Feb 26 06:56:13 2014 +0100
Replace httplib.
httplib.
Implementation got adapted to make use of the requests module instead.
SSL Verification is from now on enabled by default.
Can be disabled via an additional introduced configuration option:
`keystone_
SecurityImpact
DocImpact
Partial-Bug: 1188189
Change-Id: Ie6a6620685995a
Changed in keystone: | |
status: | In Progress → Fix Committed |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
Changed in cinder: | |
milestone: | icehouse-rc1 → none |
tags: | added: icehouse-backport-potential |
Changed in neutron: | |
assignee: | Daniel Gollub (d-gollub) → Akihiro Motoki (amotoki) |
Changed in neutron: | |
assignee: | Akihiro Motoki (amotoki) → Daniel Gollub (d-gollub) |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit 264b4a2523c1656
Author: Daniel Gollub <email address hidden>
Date: Sun Mar 2 09:33:38 2014 +0100
Replace HTTPSConnection in NEC plugin
Replace HTTPSConnection in NEC plugin PFC driver with Requests.
SSL Verification is from now on enabled by default.
This changes the default behaviour and is the primary intention of this
change: verify SSL certificates.
This might break existing configuration/
used by the NEC PFC driver would not pass the verification.
SecurityImpact
DocImpact
Partial-Bug: 1188189
Change-Id: I1e5fdc9c2ed5b8
Fix proposed to branch: milestone-proposed
Review: https:/
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: milestone-proposed
commit 8fd51240983f4c2
Author: Daniel Gollub <email address hidden>
Date: Sun Mar 2 09:33:38 2014 +0100
Replace HTTPSConnection in NEC plugin
Replace HTTPSConnection in NEC plugin PFC driver with Requests.
SSL Verification is from now on enabled by default.
This changes the default behaviour and is the primary intention of this
change: verify SSL certificates.
This might break existing configuration/
used by the NEC PFC driver would not pass the verification.
SecurityImpact
DocImpact
Partial-Bug: 1188189
Change-Id: I1e5fdc9c2ed5b8
(cherry picked from commit 264b4a2523c1656
Changed in keystone: | |
milestone: | icehouse-rc1 → 2014.1 |
Change abandoned by Duncan Thomas (<email address hidden>) on branch: master
Review: https:/
Reason: Abandoning change: No update for more than 14 days
Sean Dague (sdague) wrote : | #51 |
This is definitely still in nova in a few places. I kind of thing this should be an RC bug to actually clean up the rest of this.
Changed in nova: | |
importance: | Undecided → High |
assignee: | Xurong Yang (idopra) → nobody |
importance: | High → Critical |
milestone: | none → juno-rc1 |
Nathanael Burton (mathrock) wrote : | #52 |
Sean, I agree. Here's one that's almost through gerrit after *only* seven months of review for a tiny change.
Michael Still (mikal) wrote : | #53 |
So, for this to remain RC for nova I need a list of patches that need review. If we don't have that basically now, then we're going to need to drop this from rc1.
(That doesn't mean its important, just that I don't think we can hold rc1 waiting for it).
Changed in nova: | |
milestone: | juno-rc1 → none |
Sean Dague (sdague) wrote : | #54 |
The generic version of this isn't getting fixed in Nova, so openning the following bugs:
https:/
https:/
https:/
https:/
For the specific instances where we need to fix this
Related fix proposed to branch: master
Review: https:/
Sean Dague (sdague) wrote : | #56 |
Nova bugs will be tracked in the separate bugs listed above, so removing Nova from this bug.
no longer affects: | nova |
haruka tanizawa (h-tanizawa) wrote : | #57 |
Is there any in progress work for neutron ?
Changed in oslo.vmware: | |
status: | New → Fix Committed |
importance: | Undecided → Medium |
assignee: | nobody → Davanum Srinivas (DIMS) (dims-v) |
Changed in oslo.vmware: | |
status: | Fix Committed → Fix Released |
Jeremy Stanley (fungi) wrote : | #58 |
Now that the solidfire driver has switched from httplib to requests in the current development cycle (see https:/
John Griffith (john-griffith) wrote : | #59 |
@Jeremy
I'll look at making the switch, frankly the overwhelming response I had received from the field was that is was a "don't care", that being said it's certainly a supported capability that I can adjust. Even if I make it an option that for now defaults to False I think it at least addresses the heart of the matter here.
Robert Clark (robert-clark) wrote : | #60 |
It's sad that we can't have something more secure by default.
Jeremy Stanley (fungi) wrote : | #61 |
While I agree that secure defaults are preferable, even if only to provide a good example to operators and prove that we as a project are doing all we can to keep them and their users safe, from what I've seen in the field most will be disinterested in running a CA or purchasing and tracking certificates for the various bits of hardware to which these drivers are communicating.
The additional complexity and liability of spontaneous breakage from certificate expiration often outweighs concerns over attacks by malicious entities infiltrating an isolated management network in ways which internal server-to-server and driver-to-hardware HTTPS might mitigate.
I appreciate the degree to which our developers already make security a priority in our software, and recognize that sometimes user demands for other fixes and features pragmatically outweigh some particular security improvements in the absence of specific developers focused on driving and implementing the latter.
Sean McGinnis (sean-mcginnis) wrote : | #62 |
No longer any instances of this in cinder.
Changed in cinder: | |
status: | In Progress → Invalid |
tags: | removed: icehouse-backport-potential |
Changed in neutron: | |
status: | In Progress → Fix Released |
Xing Yang (xing-yang) wrote : | #63 |
In Cinder, the following drivers are using six.moves.
Location: cinder/
Location: cinder/
Location: cinder/
Location: cinder/
Location: cinder/
Location: cinder/
See reference of six.moves.
Re-opening the bug.
Changed in cinder: | |
status: | Invalid → Triaged |
Chris Suttles (killface007) wrote : | #64 |
Current status:
find cinder/
cinder/
24 from six.moves import http_client
128 connection = http_client.
cinder/
28 from six.moves import http_client
63 Supplies an additional 'makefile' method which http_client requires
74 class HTTPSConnection
86 http_client.
222 response in XML. Uses Python's build-in http_client. x509 may be a
282 except http_client.
cinder/
23 from six.moves import http_client
821 connection = http_client.
cinder/
31 from six.moves import http_client
90 connection = http_client.
108 except http_client.
111 connection = http_client.
131 if response.status == http_client.
140 except http_client.
151 and response.status == http_client.
158 'response': http_client.
160 if response.status == http_client.
164 elif retcode == 0 and response.status is http_client.
166 elif retcode == 0 and response.status is http_client.
180 response.status in [http_client.OK, http_client.
181 http_client.
211 [http_client.OK, http_client.
233 [http_client.OK, http_client.
234 http_client.
253 [http_client.OK, http_client.
254 http_client.
264 [http_client.OK, http_client.
265 http_client.
290 [http_client.OK, http_client.
291 http_client.
307 [http_client.OK, http_client.
308 http_client.
312 return self._execute(
317 [http_client.OK, http_client.
341 [http_client.OK, http_client.
342 http_client.
361 [http_client.OK, http_client.
362 http_client.
368 [http_client.OK, http_client.
369 ...
Chris Suttles (killface007) wrote : | #65 |
Eek, I didn't realize that would be such a big wall of text.
It looks like this has been stagnant for a while and the requirements are pretty simple, so I am going to reassign this to myself and start working through the drivers that are using six.moves.
Changed in cinder: | |
assignee: | Daniel Gollub (d-gollub) → Chris Suttles (killface007) |
Chris Suttles (killface007) wrote : | #66 |
I'm sorry to bail on this after grabbing it @d-gollub. I spent some time on this, but got stuck on updating tests. I reached out in a couple related tickets but got no replies. I'd hand this back but I don't have permission to do so.
Changed in cinder: | |
assignee: | Chris Suttles (killface007) → nobody |
Changed in cinder: | |
assignee: | nobody → sawangpong (sawangpongm) |
assignee: | sawangpong (sawangpongm) → nobody |
Ibad Khan (ik-ibadkhan) wrote : | #67 |
It's been time since @killface007 had updated this.
Right now only QNAP Storage drivers use six.moves.
cinder/
34 from six.moves import http_client
979 connection = http_client.
983 connection = http_client.
987 http_client.
1006 connection = http_client.
1010 connection = http_client.
1013 connection = http_client.
Rest of the files refer only HTTP codes, which I presume is safe.
Changed in cinder: | |
assignee: | nobody → Ibad Khan (ik-ibadkhan) |
Fix proposed to branch: master
Review: https:/
Changed in cinder: | |
status: | Triaged → In Progress |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: master
commit 431b4284bf12dfd
Author: Ibadulla Khan <email address hidden>
Date: Fri Jan 26 19:08:35 2018 +0530
QNAP Drivers - Move from httplib to requests
Use driver_
enable or disable SSL verfication.
NOTE: IPv6 isn't supported by QNAP driver.
Change-Id: Iba886fd0bd4010
Closes-Bug: 1658766
Partial-Bug: 1188189
Instances of httplib. HTTPSConnection were also found in Cinder, keystone, nova, quantum and swift for sure.