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.
NSS now enables the TLS version 1.2 protocol by default
In order to satisfy current best security practices, the Transport Layer Security (TLS) 1.2 protocol has been enabled by default in NSS. This means that it is no longer necessary to explicitly enable it in applications that use NSS library defaults.
If both sides of TLS connection enable TLS 1.2, this protocol version is now used automatically.
We spoke in the past about making TLS 1.2 the default for RHEL6. We should do this now given the current environment and where the industry is moving.
We will likely need some bugs to fix confused clients. I will let QE and dev file those.
Comment 3Elio Maldonado Batiz
2015-11-18 22:58:13 UTC
If you intend to change the default TLS version for libcurl-based applications too, we need to patch also the curl package as we did in RHEL-7 (bug #1170339).
(In reply to Kamil Dudka from comment #5)
> If you intend to change the default TLS version for libcurl-based
> applications too, we need to patch also the curl package as we did in
> RHEL-7 (bug #1170339).
I will (re)use bug #1289205 for this. Please vote for it in case you want to increase the chance of having it included in RHEL-7.3.
(In reply to Kamil Dudka from comment #6)
> I will (re)use bug #1289205 for this. Please vote for it in case you want
> to increase the chance of having it included in RHEL-7.3.
I meant RHEL-6.8, of course...
Hi Elio,
This bug was flagged as requiring a Release Note. Could you please fill out the Doc Text field? I'll edit it into a RN and make sure it gets published.
Thank you.
Comment 27Elio Maldonado Batiz
2016-03-02 13:33:44 UTC
Please note that this bug is only about NSS defaults. All versions of NSS package since 3.15.2 support both TLSv1.2 and TLSv1.2-specific AES-GCM ciphersuites.
If you require ability to enable TLSv1.2 in PHP (as bug 1255920 would indicate), please contact customer support so that they work with you to provide the best solution available.
Sorry - I was not clear with my original post.
I can get a 1.2 connection by forcing tls with cURL or PHP, but it won't connect by default. Forcing isn't a very clean option as I'd have to check against a whitelist of endpoints (i.e PayPal) to decide when to force it and when not to. This is because other services don't support 1.2.
I do not have a large amount of knowledge regarding the connection between nss/curl/libcurl - so apologies if this is the wrong bug request to file this information.
(In reply to Mike Parkin from comment #30)
> I can get a 1.2 connection by forcing tls with cURL or PHP, but it won't
> connect by default. Forcing isn't a very clean option as I'd have to check
> against a whitelist of endpoints (i.e PayPal) to decide when to force it and
> when not to. This is because other services don't support 1.2.
Then you should use the CURL_SSLVERSION_TLSv1 option of libcurl to negotiate the highest available TLS 1.x version:
https://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html
If I am not mistaken, this is going to be the NSS default in RHEL-6.8 anyway.
(In reply to Kamil Dudka from comment #31)
> If I am not mistaken, this is going to be the NSS default in RHEL-6.8 anyway.
I should have looked first. According to attachment #1096374[details], NSS will allow SSL 3.0+ whereas CURL_SSLVERSION_TLSv1 means TLS 1.0+. Still I believe that TLS 1.0+ will work for you just fine without maintaining any whitelist.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-0820.html