EC2 and S3 token middleware create insecure connections

[Jamie Lennox]

EC2 and S3 token middleware are similar to auth_token_middleware receiving and authenticating ec2/s3 tokens. They both still use the httplib method of connecting to keystone and so doesn't validate any SSL certificates.

On top of this they appears to be completely untested.

They are not enabled by keystone's default pipeline and are thus most likely not used at all and should be either deprecated or moved into keystoneclient.

[Grant Murphy (gmurphy)]

This was reported in bug 1188189. ttx / fungi do we require an advisory for this? Or was it just an OSSN?

[Jamie Lennox (jamielennox)]

As pointed out by Grant in #1 this is essentially just a refinement of bug 1188189. But more keystone specific as these middleware are untested and most likely unused, I was looking to just see can we drop/deprecate them or do they require fixing?

[Thierry Carrez (ttx)]

At this point the fact that openstack-internal communications are not all properly encrypted is a known feature gap. Internal management traffic needs to be run over a trusted network as a result. This feature gap is being addressed (in the referenced bug). Once we reach the state where OpenStack internal management traffic can be run over a hostile network (and a release publish that deployment security as a feature), then we'll consider any regression to be a vulnerability and issue advisories for it.

As far as this bug goes, I would just open this bug and recommend dropping this untested "feature" completely.

[Jeremy Stanley (fungi)]

Right, duplicate or child of 1188189 I think. Security hardening, no advisory (but definitely worthy of shouty release notes once we get all these plugged).