Description of problem:
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):
See above and below.
OpenSSL in RHEL 7.x without TLSv1.3 support.
OpenSSL in RHEL 7.x with TLSv1.3 support (once at upstream available).
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.
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.
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.
*** Bug 1457354 has been marked as a duplicate of this bug. ***
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.