HTTPS connection and authentication are not supported between swift-proxy and swift-account-server/swift-container-server/swift-object-server.

[Yikun Jiang]

HTTPS connection and authentication are not supported between swift-proxy and swift-account-server/swift-container-server/swift-object-server.

The issue description as following:
All the components of swift-proxy, swift-account-server, swift-container-server, swift-object-server can be deployed in multi-node. All the services of swift-store can be access without authentication, swift-proxy as a client, it communicates to the swift-store though clear http connection. If an attacker in internal-base network, he can get the transfered information easily, he also can attack the swift-store services with rest-api-command.

The base-cvss-score of the issue is 6.3.

[Tristan Cacqueray (tristan-cacqueray)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

This seems like a known behavior already documented in the security guide: https://docs.openstack.org/security-guide/object-storage.html#first-thing-to-secure-the-network . Issues around management network are usually triaged as class C1 according to VMT's taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).

[John Dickinson (notmyname)]

This is a known fact of operating Swift clusters, documented in the security guide Tristan linked and also as a proposal for improvement upstream (documented publicly at https://wiki.openstack.org/wiki/Swift/ideas/network_security).

If Swift is deployed on an untrusted network, operators could set up a separate tunneling system without changing Swift or use a VPN. However in practice, TLS connections between proxy and storage nodes can significantly negatively impact data throughput.

Furthermore, the bug reporter is correct that there is no authorization for the Swift storage nodes. If one can make a network connection to them, one can request and access any data on that server.

Since there are ways to mitigate network security concerns, this isn't something that has been prioritized upstream over other work. However, I do agree that out-of-the-box encrypted communications between servers in a Swift cluster is definitely nice to have.

For now, all internal-to-the-cluster network traffic (proxy<->storage and storage<->storage), including all consistency engine traffic, must be deployed on a limited-access network. In the case of multi-region deployments, this includes setting up a VPN between the regions and setting firewall rules (or taking other measures) if the traffic may be seen by entities not part of the Swift cluster.

I do not consider this a security bug that needs an embargo.

[Jeremy Stanley (fungi)]

Based on John's input above, this is more a class D report (security hardening opportunity) with no need for embargo nor advisory. Triaging accordingly.

[Alistair Coles (alistair-coles)]

I agree with John's analysis i.e. this is publically known. Marking as a wishlist bug for swift.