This should already be the way the parameter works. If versions older than the configured one can connect, then this is a bug. Do you have a way to reproduce this?

We already configure the listeners with this ssl_version and that works perfectly.
The issue here is when configuring TLS for the REST API (port 8989), when you use the admin_ssl_cert, admin_ssl_key, admin_ssl_ca_cert. The 8989 port SSL config causes 3 high vulnerabilities due to the fact that it lest older less secure ciphers through. Need a way to limit ciphers accepted by port 8989 similar to how you can configure this for the listeners.

Until we have a fix for this (preferably in 2.4.x and later) we cannot configure SSL for the 8989 REST API port.

I apologize, I completely missed the REST API in the title and only saw the ssl_version which is a listener/server parameter.

Should be doable by using the MHD_OPTION_HTTPS_PRIORITIES option to pass the cipher configuration string to gnutls.

Where are we on this? Is this being looked at since it is critical for Nokia to allow the 8989 port to be configured with TLS. However when doing that we are being flagged with 3 high vulnerabilities due to the fact that older unsecure ciphers are being accepted.

Update please? We are still facing vulnerabilities in maxscale due to allowing older cyphers into the 8989 port in maxscale.

New feature requests are initially put into an icebox for future consideration. When the next version is planned, the requests are prioritized and assigned to an engineer. The status and fix version can be found at the top of the ticket.

TLS version is determined by the OS that runs MaxScale. Newer distros will not allow the deprecated TLSv1.0 and TLSv1.1 (without setting legacy overrides) but older systems running older versions of OpenSSL for example may still contain those protocols in their default policies. Either way this is an OS level configuration. MaxScale and by extension microhttpd will use whatever the system is capable of.

An upgrade to a newer OS, an upgrade to a newer SSL package, or a change of the OS level crypto policy is likely in order:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

http://manpages.ubuntu.com/manpages/focal/man8/update-crypto-policies.8.html

MaxScale can be configured to use a specific TLS version (ssl_version) but this does not change the protocols allowed by micohttpd nor does it eliminate the systemwide risk of running obsolete protocols in general.

https://mariadb.com/docs/security/encryption/in-transit/enable-tls-maxscale/

Maxscale has an ssl_cipher but it only applies to listeners and servers. This issue was specifically for REST API.
https://mariadb.com/kb/en/mariadb-maxscale-24-mariadb-maxscale-configuration-guide/#ssl_cipher

mpflaum By default, no explicit ciphers are defined and the system defaults are used. Remove the offending ciphers from the system for a more secure solution. Again this is more of an OS problem than a MaxScale problem. A configuration change in MaxScale does not solve the security problem of including TLSv1.0 or TLSv1.1 in the SSL crypto library.

This isn't configurable on the OS level and must be implemented in MaxScale. This is identical to the existing ssl_version parameter but instead of applying to database connections it would to apply to the REST API. In hindsight this is something that should've been implemented at the same time the TLS support for the REST API was implemented.

Thanks, Marcus, that is exactly what I have been arguing for. Can this be re-opened and fixed? We cannot enable 8989 port TLS until this is resolved since it flags more vulnerabilities than not enabling it at all (surprisingly).

Marcus, can this fix also be done to maxscale-2.4? We are currently on maxscale-2.4 since we cannot move to 2.5 until a maxscale_exporter is developed to work with maxscale when the maxinfo lister has been removed.