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.

Description of problem:
curl CLI commands supports TLS 1.0 as a highest SSL/TLS version for HTTPS connections. Given its ubiquity and need to move to TLS 1.1 or better, TLS 1.2 in light of recent advances in cryptography, this issue should be resolved rather quickly...

Version-Release number of selected component (if applicable):
curl-7.19.7-37.el6_4.x86_64
nss-softokn-freebl-3.14.3-9.el6.x86_64
nss-util-3.15.1-3.el6.x86_64
nss-3.15.1-15.el6.x86_64
openssl-1.0.1e-16.el6_5.x86_64

How reproducible:
always

Steps to Reproduce:
1. start network capture on https
2. curl https://test.example.com/
3. look at ClientHello packet

Actual results:
ClientHello is of version TLS 1.0
HandshakeProtocol is of verion TLS 1.0

Expected results:
ClientHello version should be kept at TLS 1.0 to maintain backward compatibility
HandshakeProtocol version should be the maximum that the underlying library supports

Additional info:

*** This bug has been marked as a duplicate of bug 1012136 ***

Bug #1012136 isn't public so I don't know what discussion went on in there, but this bug report is about curl using TLSv1.2 by default instead of TLSv1.0. The changelog for curl on el6 only shows it got the --tlsv1.1 and --tlsv1.2 options for bug #1012136 which doesn't really address this bug.

Can someone comment on making curl use TLSv1.2 by default like el7 does (bug #1170339)?

As far as I know, there is currently no plan to make curl use TLS 1.2 by default on RHEL-6.  You can either use the --tlsv1 option of curl to negotiate the highest version of TLS supported by both client and server,  or update to RHEL-7, where this behavior is used by default.