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