Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

This is a suggestion for a future enhancement.

Occassionaly, old TLS protocol versions might be considered low security, and the use of new TLS versions might be desired in deployments, deviating from the defaults that we ship in RHEL for compatibility reasons.

As of today, IIUC, the curl library is hardcoded to allow only the TLS protocol versions that are embedded as defaults in NSS.

It would be helpful, if yum/dnf/curl allowed a mechanism to override such defaults.

I suspect the ideal place to implement this flexibility is curl.

I understand that the curl command line utility already provides parameters like --tlsv1.2, but if I understand correctly, when using curl as a library, it's impossible to request specific TLS protocol versions.

Is my understanding correct?

If yes, I'd like to suggest to implement a configuration file, or an environment variable, that is used by yum/dnf, or by curl, to override the defaults of the used crypto library (currently NSS).

I'd like to suggest, please discuss if the best place is curl or yum/dnf, and when you made a decision, please file an (upstream) bug against the right component (or advice where I should report it).

Thanks!

Kamil, what's your opinion?

(In reply to Kai Engert (:kaie) from comment #0)
> I understand that the curl command line utility already provides parameters
> like --tlsv1.2, but if I understand correctly, when using curl as a library,
> it's impossible to request specific TLS protocol versions.
> 
> Is my understanding correct?

The command line switches --tlsv1, --tlsv1.0, --tlsv1.1 and --tlsv1.2 are mapped to the corresponding constants that are passed to the CURLOPT_SSLVERSION option of libcurl API:

https://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html

The interface does not allow for setting min/max TLS version independently of each other.  The CURL_SSLVERSION_TLSv1 constant means TLS 1.x whereas each of the CURL_SSLVERSION_TLSv1_* constants asks for an exact version of TLS.

> If yes, I'd like to suggest to implement a configuration file, or an
> environment variable, that is used by yum/dnf, or by curl, to override the
> defaults of the used crypto library (currently NSS).

(lib)curl does not override the NSS default unless it is explicitly asked to do so.  I believe that the correct place to maintain system-wide crypto policy is NSS because, if some settings is good enough for libcurl-based applications, it usually fits also the applications that use NSS directly.