The DSM WebAPI client disabled TLS certificate verification for all
HTTPS connections (InsecureSkipVerify: true), then sent the configured
DSM account and password to the endpoint. An attacker able to intercept,
redirect, or impersonate the DSM HTTPS endpoint could therefore obtain
the DSM credentials stored in the CSI client config / Kubernetes secret
(CWE-295 Improper Certificate Validation, OWASP A3:2017 Sensitive Data Exposure)
TLS certificate verification is now enabled by default. The client trusts
the system CA pool, so certificates signed by a public CA work without
extra configuration. Three optional client-info fields are added:
- tlsCACert: PEM CA cert to trust (for DSM self-signed certs);
merged with the system CA pool.
- tlsServerName: override the name checked during verification,
e.g. when connecting by IP.
- insecureSkipVerify: explicit opt-out that restores the old behavior;
logs a warning on every connection.
The new fields are propagated through all DSM construction sites
(service, synocli, and the HA GetAnotherController path).
BREAKING CHANGE: deployments using `https: true` against a DSM with a
self-signed certificate (the DSM default) will fail to connect after
upgrade until they set `tlsCACert`, `tlsServerName`, or (discouraged)
`insecureSkipVerify: true`.
Adds TLS tests covering default-reject, valid-CA accept, wrong-CA reject,
insecureSkipVerify opt-in, and the tlsServerName DNS-SAN scenarios.
benzheng
Yordi PauptitandGitHub
chihyuwu
Yordi Pauptit
GautierLeblanc