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.
Bug 1416715 - Backport TLSv1.3 support from upstream OpenSSL into RHEL 7.x (once at upstream available)
Summary: Backport TLSv1.3 support from upstream OpenSSL into RHEL 7.x (once at upstrea...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssl
Version: 7.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
: 1457354 (view as bug list)
Depends On:
Blocks: 1420851
TreeView+ depends on / blocked
 
Reported: 2017-01-26 10:38 UTC by Robert Scheck
Modified: 2022-03-13 14:11 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-11 15:39:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Robert Scheck 2017-01-26 10:38:46 UTC 
Description of problem:
https://mta.openssl.org/pipermail/openssl-announce/2017-January/000090.html
mentions that Akamai sponsors TLSv1.3 support in OpenSSL and also mentions a
key deadline of 2017-04-05 for the implementation (if I get things right).

Goal of this RHBZ is to somehow achieve TLSv1.3 support in OpenSSL at RHEL
7.x in a way, that e.g. mod_ssl can use it to serve HTTPS enabled websites
using TLSv1.3. This is explicitly filed against RHEL 7, because RHEL 8 does
not seem to be just around the corner.

How the "backport" is technically achieved is left open here, no idea what
plans OpenSSL has regarding 1.0.x branch or whether this would require work
on Red Hat side to manually backport this for RHEL customers.

Version-Release number of selected component (if applicable):
openssl-1.0.1e-60.el7.x86_64

How reproducible:
See above and below.

Actual results:
OpenSSL in RHEL 7.x without TLSv1.3 support.

Expected results:
OpenSSL in RHEL 7.x with TLSv1.3 support (once at upstream available).

Additional info:
Cross-filed case 01780093 on the Red Hat customer portal.
Comment 1 Tomas Mraz 2017-01-26 11:08:48 UTC 
I am afraid there are no plans for such backport. If at all we get TLSv1.3 into RHEL-7 openssl in my opinion it should be done via adding the 1.1.x somehow, preferably so the base RHEL is not affected which means SCL or something like that.

The backport would esentially be a new implementation as the code differences between 1.0.2 and 1.1.x are huge - one of them is the complete TLS state machine rewrite.
Comment 3 Robert Scheck 2017-01-29 01:27:01 UTC 
SCL is not really what I am interested in, because then e.g. packages in
EPEL can not consume it. Is there a realistic chance for adding a compat
layer to 1.1.x that provides 1.0.2-alike ABI/API additionally? If not, is
something like openssl110 as a parallel installable RPM maybe possible?
Comment 4 Tomas Mraz 2017-01-30 08:44:41 UTC 
Adding compat layer to 1.1.x would not help you as we could not switch the base package from 1.0.x regardless of it anyway.

Providing openssl110 which would be parallel installable would be technically possible but the -devel files would conflict as they do on current Fedora rawhide with openssl and openssl10. I cannot however promise any such package being added to RHEL. And there would still be a problem which dependent packages could be switched to the openssl110 - probably none of the base packages such as httpd would be eligible to that.
Comment 5 Robert Scheck 2017-01-31 11:07:55 UTC 
Conflict of the -devel files could be avoided (see openssl101e in EPEL 5),
but yes, would still leave us with the point that we would need SCL for a
httpd consuming latest OpenSSL, but at least this would enable EPEL to also
use the latest OpenSSL then.

Are there already any plans or ideas about how TLSv1.3 will be handled in
RHEL 7? RHEL 8 still seems to be far away and being stuck with TLSv1.2 is
IMHO not an option either.
Comment 6 Tomas Mraz 2017-01-31 16:29:06 UTC 
Unfortunately bugzilla is not a support forum and I definitely cannot share any details on how TLSv1.3 will be handled on RHEL-7 here.
Comment 7 Robert Scheck 2017-01-31 16:46:43 UTC 
Fully understood. We can switch this e.g. to the support ticket we opened,
but our request for OpenSSL with TLSv1.3 in RHEL 7.x still stays the same.
Comment 13 Tomas Mraz 2017-06-12 15:15:35 UTC 
*** Bug 1457354 has been marked as a duplicate of this bug. ***
Comment 30 Simo Sorce 2019-02-11 15:39:06 UTC 
This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.
Comment 31 Robert Scheck 2020-03-05 23:42:44 UTC 
For those coming around via search engines: There is now openssl11 in EPEL 7, see bug #1792741 for the package review and details. The package can be installed additionally, e.g. for linking new/own applications against OpenSSL 1.1 during build, or to use openssl11(1). The OpenSSL version is the same as in RHEL 8 in order to be able to cover security and bugfix updates until RHEL 7 reaches EOL in 2024. Obviously RHEL 7 (base) packages are still linked against OpenSSL 1.0, but EPEL 7 packages could consume OpenSSL 1.1 if needed.
Note You need to log in before you can comment on or make changes to this bug.