Bug 1324045

Summary:	yum/dnf/curl should consume an environment variable that configures min/max allowed TLS protocol version
Product:	Red Hat Enterprise Linux 7	Reporter:	Kai Engert (:kaie) (inactive account) <kengert>
Component:	yum	Assignee:	Valentina Mukhamedzhanova <vmukhame>
Status:	CLOSED WORKSFORME	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	ffesti, james.antill, kdudka, kengert, ksrot
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-06 16:08:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Kai Engert (:kaie) (inactive account) 2016-04-05 12:14:35 UTC

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!

Comment 2 Kai Engert (:kaie) (inactive account) 2016-04-05 12:17:44 UTC

Kamil, what's your opinion?

Comment 4 Kamil Dudka 2016-04-06 15:49:42 UTC

(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.