Secure communication standard for IaaS infastructure

[markus-hentsch]

As a customer I expect the communication channels to and between infrastructure components of an SCS cloud to be secured appropriately, so that in-transit data is protected.
As a CSP I want to establish secure communication channels adhering to the corresponding SCS standard the users can rely on.

Contents

• Overview and classification of communication channels
• References to the OpenStack Security Guide where applicable
• TLS version and cipher restrictions

Definition of Done:

Please refer to scs-0001-v1 for details.

• Proposal has been written with name of the form scs-xxxx-v1-slug.md (only substitute slug)
• Proposal has the fields status, type, track set
• Proposal has been voted upon in the corresponding team
• Status has been changed into Draft, file renamed: xxxx replaced by document number
• If applicable: test script has been written (this item may be moved into a separate issue so long as the state is Draft)

[markus-hentsch]

Major communication channels that need to be secured:

#	Classification	Details	Solution
1	Database backend traffic	Replication and sync between database instances	SSL/TLS
2	Database frontend traffic	Communication between OpenStack services and databases	SSL/TLS
3	Message queue traffic	Message queue communication between OpenStack components as provided by oslo.messaging	SSL/TLS
4	Internal API communication	HTTP traffic to services registered as internal endpoints in the Keystone service catalog	SSL/TLS
5	External API communication	HTTP traffic to services registered as external endpoints in the Keystone service catalog	SSL/TLS
6	Nova VM migration	Nova VM migration data transfer traffic between compute nodes	QEMU-native TLS

Resources:

• 1, 2: OpenStack Security Guide: Database transport security
• 3: OpenStack Security Guide: Messaging transport security
• 4, 5: OpenStack Security Guide: Secure communication
• 6: Nova: Secure live migration with QEMU-native TLS

[markus-hentsch]

Most of the configuration adjustments proposed here cannot be verified via external tests unfortunately. Only the public-facing APIs can be checked for TLS by inspecting Keystone's service catalog, contacting each public endpoint and verifying its TLS handshake.

All the internal stuff would be up to dedicated audits with access to the infrastructure.

Speaking of TLS handshakes, I think we should also forbid using older/weak TLS versions and ciphers in the standard.

[markus-hentsch]

I began adding TLS specifics to the standard based on the official guidelines on ssl.com¹.

I think we should align this to the most commonly and broadly accepted current recommendations around TLS.

Footnotes

1. https://www.ssl.com/guide/tls-standards-compliance/ ↩

[artificial-intelligence]

I began adding TLS specifics to the standard based on the official guidelines on ssl.com1.

I think we should align this to the most commonly and broadly accepted current recommendations around TLS.

Footnotes

1. https://www.ssl.com/guide/tls-standards-compliance/ [↩](#user-content-fnref-1-cfaa4efba83e4b7037c3fc3cf637ce1e)

Might I ask why you choose this specific guide?

E.g. I think this guide is better: https://ssl-config.mozilla.org/ because it does not focus on compliance but on security.

[markus-hentsch]

Might I ask why you choose this specific guide?

E.g. I think this guide is better: https://ssl-config.mozilla.org/ because it does not focus on compliance but on security.

No particular reason. I was just looking for some form of official consensus on current SSL/TLS recommendations to base the standard on. I guess the Mozilla ones¹² would be a good alternative.

@martinmo had the same thought apparently: #548 (comment) :)

I will have a look.

Footnotes

1. https://infosec.mozilla.org/guidelines/web_security.html#transport-layer-security-tlsssl ↩

2. https://wiki.mozilla.org/Security/Server_Side_TLS ↩

[markus-hentsch]

I've had a look and it seems that sslyze does indeed support checking against the Mozilla recommendations directly. We could simplify the maintenance effort for this standard by referencing Mozilla's recommendations. However, this would mean referencing recommendations which are also a moving target themselves potentially (how often does Mozilla update this?).
Also not sure how this would relate to the standard versioning and what a CSP has to test against at a given point in time exactly (version-pin sslyze? always upgrade sslyze before execution? etc.).

I've put it on the agenda for the next IaaS call.

[markus-hentsch]

I've put it on the agenda for the next IaaS call.

We discussed this on the SIG Standardization / Certification call: SovereignCloudStack/minutes/sig-standardization/20240516.md#tracking-moving-targets-tls-recommendations-from-mozilla

---

I updated the standard and test script to use the Mozilla TLS recommendations instead after figuring out how that works with the SSLyze library.

Sadly, the library only ships the single most recent Mozilla TLS preset version at the time of the library version release¹. So, when executing, you cannot choose between the versions of the recommendations. This means the recommendation version is coupled to the library version in a non-obvious way (different version numbers, requiring manual lookup).

We should pin the SSLyze library version for the test together with the JSON of the recommendation.

Footnotes

1. https://github.com/nabla-c0d3/sslyze/tree/761892bf6a613726f272eb4e19b33faee2272b6f/sslyze/mozilla_tls_profile/ ↩