RFC: New TLS configuration options in smart-proxy (tls_ciphers, tls_min_version)

Background

smart-proxy currently controls TLS behavior through two settings: ssl_disabled_ciphers (accepts a list of cipher names to remove from a hardcoded list) and tls_disabled_versions (accepts a list of TLS versions to disable). These settings do not integrate with RHEL’s system-wide crypto-policies (PROFILE=SYSTEM), meaning foreman-proxy does not automatically respect the organization’s security settings on managed RHEL hosts.

Proposed Changes

Two new settings are introduced in config/settings.yml:

tls_ciphers — accepts any OpenSSL cipher string, including PROFILE=SYSTEM:

When unset, smart-proxy auto-detects: if the openssl config exists, it defaults to PROFILE=SYSTEM, otherwise it falls back to OpenSSL’s built-in defaults.

tls_min_version — sets the minimum TLS protocol version. Valid values are '1.2' and '1.3' as versions 1.0 and 1.1 are disabled by default.

Breaking Changes

The following settings are removed in this release:

Removed setting Replacement
ssl_disabled_ciphers Use tls_ciphers to specify the allowed cipher list
tls_disabled_versions Use tls_min_version to set the minimum version

You can track the progress of this feature in Fixes #39405 - Add tls_min_version and tls_ciphers settings by adamlazik1 · Pull Request #947 · theforeman/smart-proxy · GitHub.

2 Likes

As far as I know Ubuntu/Debian does not have the concept of RHEL’s system-wide crypto-policies (PROFILE=SYSTEM), how will it work on those systems? Just the same without the option for PROFILE=SYSTEM?

And with the containerization will this also honor the system-wide crypto-policy when the Smart Proxy runs as container?

Debian indeed doesn’t have crypto-policies: crypto-policies - Debian Package Tracker existed, but that never made it into a release. That indeed makes it a bit awkward.

Would it make sense to fall back to the current list of hardcoded ciphers when no config option is provided? Would HIGH be a better default?

That is intended yes. Internally we track it as a separate but related effort.

1 Like

I think HIGH is a better fallback as we are sure Smart Proxy is compiled against OpenSSL (GnuTLS uses different values) and we only need compatibility in our ecosystem which should be up to date or at least quite similar.

What level of configuration would be OK in our existing installer? Do we need options for this or is it OK to just drop the old ones? For RPMs it should work out of the box but for Debian it may need some options.