[Hardening] F-01: Failure to Initialize a Secure Transport Layer (TLS) During Out-of-the-Box Setup.

[davift]

The required feature described as a wish

Description: TLS is not enabled by default on the Management server or System VMs. This insecure default persists until explicitly remediated by the administrator.

Affected Component: Management UI / API, SSVM, CPVM

Impact: An attacker with network access can trivially intercept or sniff management traffic, including administrator credentials (password and 2FA codes), session tokens, API keys, and sensitive configuration data.

Steps to Reproduce:

• Deploy ACS following the official documentation.
• Navigate to http://:8080/ (no HTTPS redirect occurs).
• Attempt to connect to https://:8443/ and confirm that the connection fails.
• Capture traffic with Wireshark or tcpdump during a login session.
• Observe that credentials and session tokens are transmitted in cleartext.

Recommended Remediation: Enable TLS by default during installation. A self-signed certificate can be automatically generated and configured without any additional effort on the user's part.

[github-actions]

🎯 Triage report

Reports that CloudStack's Management server and System VMs (SSVM, CPVM) do not have TLS/HTTPS enabled by default out-of-the-box, exposing credentials, session tokens, and API keys to network sniffing. This is a hardening/security-by-default request rather than a code defect in a specific feature.

📊 Assessment

Dimension	Value	Reasoning
Type	type:security	Describes an insecure default configuration with a credential-exposure impact.
Component	component:management-server	Management UI/API is the primary affected surface; SSVM/CPVM also mentioned but no dedicated component label fits both.
Severity	n/a (no Severity label applied)	Real-world exploitability requires network access/MITM position; impact is significant but this is a "hardening" request, not a specific exploitable bug in running code, so severity is left to maintainer judgment.
Labels	type:security, component:management-server	See above.
Coding agent	Not suitable	Enabling TLS-by-default with auto-generated self-signed certs touches installer/packaging, systemvm templates, and security defaults — requires design decisions and testing across supported OS/hypervisor combos.

🔗 Similar issues

• Provide mechanism to disable TLS versions/algorithms for CloudStack server services #3155 (related, closed) — "Provide mechanism to disable TLS versions/algorithms for CloudStack server services", adjacent TLS-configuration topic but not the same ask.

No open duplicate was found.

💡 Notes and suggestions

• This appears to be part of a series of "[Hardening] F-xx" reports from the same author (see also [Hardening] F-17: Weak Default Password on System VMs. #14075); maintainers may want to track these together, e.g. via a tracking issue or common label.
• Relevant prior art: CloudStack docs already describe manually configuring HTTPS for the Management server (keystore/cert setup) — the ask here is to make this the default rather than opt-in.
• Any implementation would need to consider: self-signed cert generation during cloudstack-setup-management/installer, browser trust warnings from self-signed certs, backward compatibility for existing deployments relying on plain HTTP, and the SSVM/CPVM systemvm template.
• Recommend maintainers confirm whether this should be tracked as a new-feature/enhancement vs. filed as a security advisory through the project's private security process (see SECURITY.md), since it describes an exploitable weakness in default configuration.

Generated by Daily Issue Triage · sonnet50 110.8K · ◷

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9