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 1276310 (rhel7-openssl1.0.2) - RFE: Need OpenSSL 1.0.2
Summary: RFE: Need OpenSSL 1.0.2
Keywords:
Status: CLOSED ERRATA
Alias: rhel7-openssl1.0.2
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssl
Version: 7.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 7.4
Assignee: Tomas Mraz
QA Contact: Stefan Dordevic
Mirek Jahoda
URL:
Whiteboard:
: 1155180 1220789 1322148 1353273 1388051 1394948 1409925 1418253 (view as bug list)
Depends On:
Blocks: 1155180 1184416 1283248 1288151 1289208 1298243 1327548 1335930 rhel7-remove-legacy-cas 1371038 1375274 1377248 1386350 1409927 1420851 1446211 1452029
TreeView+ depends on / blocked
 
Reported: 2015-10-29 12:21 UTC by Zuzana Svetlikova
Modified: 2021-12-10 14:33 UTC (History)
90 users (show)

Fixed In Version: openssl-1.0.2k-1.el7
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
_openssl_ rebased to version 1.0.2k The _openssl_ package has been updated to upstream version 1.0.2k, which provides a number of enhancements, new features, and bug fixes, including: * Added support for the Datagram Transport Layer Security TLS (DTLS) protocol version 1.2. * Added support for the automatic elliptic curve selection for the ECDHE key exchange in TLS. * Added support for the Application-Layer Protocol Negotiation (ALPN). * Added Cryptographic Message Syntax (CMS) support for the following schemes: RSA-PSS, RSA-OAEP, ECDH, and X9.42 DH. Note that this version is compatible with the API and ABI in the *OpenSSL* library version in previous releases of Red Hat Enterprise Linux 7.
Clone Of:
Environment:
Last Closed: 2017-08-01 18:16:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1202751 0 high CLOSED Rebase FreeRADIUS to 3.0.12 or later minor release 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 2740151 0 None None None 2016-11-02 17:30:16 UTC
Red Hat Product Errata RHBA-2017:1929 0 normal SHIPPED_LIVE openssl bug fix and enhancement update 2017-08-01 18:08:01 UTC

Internal Links: 1202751

Description Zuzana Svetlikova 2015-10-29 12:21:50 UTC
Description of problem:
Node.js v4.2 depends on OpenSSL 1.0.2 which is not present in RHEL

Version-Release number of selected component (if applicable):

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.

Actual results:
Current version of OpenSSL in RHEL is 1.0.1e

Expected results:
OpenSSL 1.0.2

Additional info:
This bug applies to both RHEL6.8 and RHEL7.2

Comment 6 Mattias Geniar 2016-02-15 10:52:55 UTC
As an additional motivation to implementing OpenSSL 1.0.2, the Chromium team is about to make HTTP/2 connections require ALPN instead of the now deprecated NPN method [1].

In order to support ALPN in OpenSSL, we need at least OpenSSL 1.0.2. RHEL 7 now ships with 1.0.1 [2].

How reproducible:
As of May 15th, when Chromium launches this change in the Chrome browser, HTTPS-enabled website will not be able to support HTTP/2 on all RHEL servers.

Steps to reproduce:
Browse to any HTTP/2 enabled site as of May 15th [3]

Actual results:
Current version of OpenSSL in RHEL is 1.0.1.

Expected results:
OpenSSL 1.0.2 minimum.

Additional info:
This bug/improvement/feature applies to all supported RHEL versions.

[1] http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html
[2] https://ma.ttias.be/chrome-drops-npn-support-for-http2-alpn-only/
[3] ie: https://ma.ttias.be

Comment 7 Mike Parkin 2016-03-29 21:27:04 UTC
Not sure if this is remotely feasible but can I politely request if this can be brought forward to RHEL 7.3 please? 

As the days go by, more and more of the internet is moving to HTTPS everywhere. This is promoting good security practice and keeping the internet a safer place.

Having such an old version of OpenSSL is preventing users from moving to HTTP2 over HTTPS.

Comment 8 Mike Parkin 2016-03-29 21:42:56 UTC
Afaik the httpd server (apache) does not support NPN, only ALPN is supported for HTTPS.

Comment 9 Tomas Mraz 2016-03-30 11:18:59 UTC
*** Bug 1322148 has been marked as a duplicate of this bug. ***

Comment 17 Joe Orton 2016-05-13 12:26:53 UTC
FYI, since there are comments about NPN and ALPN above; the Red Hat Software Collections 2.2 Beta release is now shipping with httpd 2.4.18 with mod_http2 enabled, and mod_ssl is patched to support NPN.

We've done some primitive testing with this, but as comments indicate above, people planning HTTP/2 deployments will have to decide whether to wait for ALPN support in RHEL7 OpenSSL.

Comment 18 Carl George 2016-05-13 13:37:00 UTC
I could be mistaken, but I don't believe that patching mod_ssl to support NPN is going to help Chrome/Chromium users when they deprecate support for NPN.

Comment 19 Joe Orton 2016-05-13 14:12:29 UTC
Correct, hence my comment about waiting for ALPN.

Comment 20 Jason Bradley Nance 2016-06-07 20:50:15 UTC
The version of Tomcat Native that ships with Tomcat 8 now requires OpenSSL 1.0.2+ as well.

Comment 21 GeorgeL 2016-06-11 20:05:50 UTC
(In reply to Mike Parkin from comment #7)
> Not sure if this is remotely feasible but can I politely request if this can
> be brought forward to RHEL 7.3 please? 

Indeed RHEL 7.3 would be great :)

Comment 22 Tomas Mraz 2016-07-12 09:25:14 UTC
*** Bug 1353273 has been marked as a duplicate of this bug. ***

Comment 23 Giovanni Tirloni 2016-08-11 18:50:20 UTC
Today I was setting up a server with HTTP/2 and HTTPS and discovered I can't because RHEL includes OpenSSL 1.0.1e and nginx needs at least 1.0.2 for ALPN.

Are the any workarounds short of recompiling OpenSSL and nginx from scratch (and possibly a bunch of other dependencies) until RHEL 7.4 is released (maybe by the end of 2017 only)?

It would be useful to know Red Hat's final decision on this so we can look for more permanent solutions.

Comment 24 Bernardo Donadio 2016-08-13 00:01:10 UTC
I'm not sure about the RHEL roadmap, but the following Gist may provide a kind of streamlined solution to compiling OpenSSL 1.0.2h and using it only on nginx (also compiled): https://gist.github.com/moneytoo/ab3f34e4fddc2110675952f8280f49c5

Comment 26 Andreas Schnederle-Wagner 2016-09-09 07:23:49 UTC
We would also be very interested in having openssl 1.0.2 with ALPN support to be able to offer native Apache HTTP/2 to our Customers ...

Comment 27 David Morton 2016-09-15 21:07:59 UTC
Chrome usage is approaching 75% of all browsers. ( http://www.w3schools.com/browsers/ )
nginx is used by more than 30% of all websites and growing rapidly. ( https://w3techs.com/technologies/details/ws-nginx/all/all )
In order to support http/2, nginx requires OpenSSL version 1.0.2.  

In the meantime, we all are using ubuntu to support http2.  I'm hoping that the Redhat/Centos distros catch up soon to this critical performance issue for the entire web.

From nginx's website:

'Users of the Google Chrome web browser are seeing some sites that they previously accessed over HTTP/2 falling back to HTTP/1. This is because of a policy change in the most recent update to Chrome, released in late May, which removes support for NPN, one method for upgrading a connection to HTTP/2.

The only way Chrome users can continue using HTTP/2 to access these websites is by switching to a different browser. Website administrators can restore HTTP/2 support for Chrome users by upgrading their OpenSSL installation to the recently released 1.0.2 version. Unfortunately, this requires either a major operating system upgrade or using a private build of NGINX.'

References:
https://www.nginx.com/blog/supporting-http2-google-chrome-users/
https://bugs.chromium.org/p/chromium/issues/detail?id=587472
https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html

Comment 29 David Morton 2016-09-24 14:56:50 UTC
** OpenSSl Support for Version 1.0.1 ceases on 2016-12-31 **

According to openssl:

"Support for version 1.0.1 will cease on 2016-12-31. No further releases of 1.0.1 will be made after that date. Security fixes only will be applied to 1.0.1 until then."

https://www.openssl.org/policies/releasestrat.html
https://access.redhat.com/solutions/1530413
- I don't have access to this one yet.

Comment 30 Andreas Schnederle-Wagner 2016-09-27 17:52:55 UTC
Would you consider backporting ALPN Support into openssl 1.0.1 for RHEL 7?
Guess this would be sufficient until you move to openssl 1.0.2 in RHEL 7.4 ...

Comment 31 baijianpeng 2016-10-04 11:04:52 UTC
I noticed that it is already 11 months after the first post on this topic. The user request is very clear and very reasonable: ONLY openssl 1.0.2+ can support ALPN for Nginx to enable http/2 . Why RedHat team has not accept and implement this idea yet?

I hope you upgrade the openssl from 1.0.1e to 1.0.2j ASAP. 

WE REALLY NEED IT!

Thank you.

Comment 34 Giovanni Tirloni 2016-10-07 13:27:40 UTC
Since this bug is tracking RHEL 7.4, is does not look like OpenSSL 1.0.2 will make its way into RHEL 7.3 at this time (beside, the beta is already out), unless the code to provide ALPN is backported (as it has been suggested).

To which I have another question: OpenSSL 1.1.0 is being added to Fedora Rawhide and is likely to be included in Fedora 26 in six months or so. Would it mean Red Hat could be considering having OpenSSL 1.1.0 on RHEL 7.4 too?

Comment 35 Tomas Mraz 2016-10-07 13:44:05 UTC
OpenSSL 1.1.0 definitely will not be in RHEL-7.4. As for future RHEL-7 updates I cannot tell. However if it ever gets there it will have to be an optional component as we cannot drop support for 1.0.x in RHEL-7.

Comment 38 Vedran Miletić 2016-12-11 15:56:59 UTC
(In reply to Giovanni Tirloni from comment #23)
> Today I was setting up a server with HTTP/2 and HTTPS and discovered I can't
> because RHEL includes OpenSSL 1.0.1e and nginx needs at least 1.0.2 for ALPN.
> 
> Are the any workarounds short of recompiling OpenSSL and nginx from scratch
> (and possibly a bunch of other dependencies) until RHEL 7.4 is released
> (maybe by the end of 2017 only)?
> 
> It would be useful to know Red Hat's final decision on this so we can look
> for more permanent solutions.

+1

Any news? EOL for 1.0.1, 31st of December[1], is in less than three weeks. Upgrade to 1.0.2 would be enough for nginx HTTP/2.

[1] https://www.openssl.org/policies/releasestrat.html

Comment 39 Robert Scheck 2016-12-11 17:21:16 UTC
Honestly, I'm not sure if everybody commenting on this bug report really knows
https://access.redhat.com/security/updates/backporting - which says, that Red
Hat backports security fixes to releases/branches where upstream is no longer
caring. I am explicitly commenting with that here, because some of the comments
make me believe different - but I might be wrong.

I am not a Red Hat employee, but from my perspective rebasing happens only
rarely in RHEL due to the possibility to break compatibilities enterprises
care about. Aside of that, I would seriously wonder if Red Hat releases some
New Year's Eve present, given that's (if at all) something for a RHEL 7.x+1.

This leaves us with the point that Red Hat will take care about the security
of OpenSSL even after 1.0.1 reached EOL at upstream, but also that rebasing/
feature requests should not only be raised on this bug report, but via sales
reps and/or GSS tickets if my personal understanding about how RHEL and its 
processes work is not totally wrong.

Comment 40 Vedran Miletić 2016-12-11 20:54:56 UTC
(In reply to Robert Scheck from comment #39)
> Honestly, I'm not sure if everybody commenting on this bug report really
> knows
> https://access.redhat.com/security/updates/backporting - which says, that Red
> Hat backports security fixes to releases/branches where upstream is no longer
> caring. I am explicitly commenting with that here, because some of the
> comments
> make me believe different - but I might be wrong.
> 
> I am not a Red Hat employee, but from my perspective rebasing happens only
> rarely in RHEL due to the possibility to break compatibilities enterprises
> care about. Aside of that, I would seriously wonder if Red Hat releases some
> New Year's Eve present, given that's (if at all) something for a RHEL 7.x+1.
> 
> This leaves us with the point that Red Hat will take care about the security
> of OpenSSL even after 1.0.1 reached EOL at upstream, but also that rebasing/
> feature requests should not only be raised on this bug report, but via sales
> reps and/or GSS tickets if my personal understanding about how RHEL and its 
> processes work is not totally wrong.

Indeed, 1.0.1[a-z] and 1.0.2[a-z] are not 100% API/ABI compatible [1]. In that case, I wouldn't mind a separate OpenSSL 1.0.2 package in EPEL and nginx recompiled with it.

[1] https://abi-laboratory.pro/tracker/timeline/openssl/

Comment 41 Jason Bradley Nance 2016-12-11 23:07:47 UTC
@Robert, speaking as the original requester of this (it was opened on my behalf in response to a customer portal ticket) I can say that I'm fully aware of the backporting policy.  The path expected in this case (at least for RHEL 7) is either Software Collections or a "non-default" (not sure on the proper term) package such as was done in the past with OpenSSL 0.9.8 (openssl98-*).

@Vedran, EPEL does not package software which replaces or otherwise conflicts with packages provided in RHEL (this is why you don't see newer version of things like PHP in EPEL).  Hence the Software Collections path.

Comment 44 Carl George 2016-12-12 15:23:51 UTC
To reinforce Robert's point, take a look back at Heartbleed.  RHEL 6 originally had OpenSSL 1.0.0 (not affected), but in Red Hat decided to rebase it to 1.0.1e in RHEL 6.5.  This unintentionally introduced the Heartbleed code.  That's an example of why Red Hat doesn't typically do major version updates.

Comment 45 Andreas Schnederle-Wagner 2016-12-12 15:35:09 UTC
In order to relativize Robert's Statement, one must note that this Report is (initially) about adding ALPN Support to OpenSSL as it's for different reasons - not about EOL of 1.0.1 or RHEL Backporting Policy! (even if there are some Comments about this)

Also please note that there is already a RFE (Request for Enhancement) with RHEL Engineering Team - see https://access.redhat.com/solutions/2740151

So everybody who wants/needs ALPN/1.0.2 should follow instructions within KCS #2740151 - would lead to faster Solution than posting here (I guess)

Comment 47 Tomas Mraz 2017-01-04 09:14:37 UTC
*** Bug 1409925 has been marked as a duplicate of this bug. ***

Comment 48 Richard Marko 2017-01-12 23:15:42 UTC
1.0.2 also fixes dual certificate issues when using ECDSA/RSA certs in Apache https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile

1.1 would be nice to have due to ChaCha20 support.

Comment 49 Tomas Mraz 2017-01-13 09:27:11 UTC
1.1 is completely API and ABI incompatible and thus not possible to be used by existing Red Hat Enterprise Linux releases.

Comment 50 Quentin Barnes 2017-01-13 17:48:06 UTC
(In reply to Tomas Mraz from comment #49)
> 1.1 is completely API and ABI incompatible and thus not possible to be used
> by existing Red Hat Enterprise Linux releases.

I think you missed the point.  The point is to just supply the 1.0.2 library (and devel package) as part of RHEL.  Not to supply 1.0.2 _and_ link RHEL system utilities with it.

With Linux, there is no problem supplying multiple, incompatible versions of the same library simultaneously (like is already done with openssl in RHEL 6 and 7).

Comment 51 Jason Bradley Nance 2017-01-13 21:23:11 UTC
(In reply to Quentin Barnes from comment #50)
> (In reply to Tomas Mraz from comment #49)
> > 1.1 is completely API and ABI incompatible and thus not possible to be used
> > by existing Red Hat Enterprise Linux releases.
> 
> I think you missed the point.  The point is to just supply the 1.0.2 library
> (and devel package) as part of RHEL.  Not to supply 1.0.2 _and_ link RHEL
> system utilities with it.
> 
> With Linux, there is no problem supplying multiple, incompatible versions of
> the same library simultaneously (like is already done with openssl in RHEL 6
> and 7).

^^ This, plus Software Collections is an option, too.  Both of these options have been mentioned multiple times in this thread.

If you're going to try and strip out enough of 1.0.2 to make it API/ABI compatible with 1.0.1 that likely won't satisfy the requirements of this BZ, which is to have an OpenSSL 1.0.2 that applications like recent NodeJS and Tomcat native can compile against.

Not sure why customers/consumers are being trolled.  If anything the response should have been "this BZ is requesting 1.0.2, if you want 1.1 please open a new BZ".

Comment 52 Tomas Mraz 2017-01-16 09:06:24 UTC
The 1.0.2 is API/ABI compatible with 1.0.1 and we are working on rebasing the RHEL openssl package to this branch. We are not working on including 1.1 into base RHEL because it would not be usable by the base RHEL applications and utilities. That's what I wanted to say. I do not see any trolling here.

If there will be 1.1 in SCL is a different question and I'd just suggest reporting such request via regular Red Hat support channels https://www.redhat.com/support and not via bugzilla as it is not a support tool/channel.

Comment 53 Greg Rettew 2017-01-17 15:48:12 UTC
When you compile 1.0.2j -- is it possible to compile it with the des-cbc ciphers removed to get rid of the sweet32 issue?  Or supply 2 libraries with the system (which we could symlink to the one that has the 64bit DES CBC ciphers deleted).  

The problem for us is this is PCI compliance issue, not at the application level, but from the OS.

Comment 54 Tomas Mraz 2017-01-17 16:15:39 UTC
(In reply to Greg Rettew from comment #53)
I have to repeat that bugzilla is not a support tool. If you have any concerns about SWEET32, please contact the regular Red Hat support channels.

Comment 55 Tomas Mraz 2017-02-01 14:45:17 UTC
*** Bug 1418253 has been marked as a duplicate of this bug. ***

Comment 56 Rodrigo Gomes 2017-02-04 06:01:52 UTC
Is someone from Red Hat looking at this?
This is a problem on a world scale, We urgently need openssl 1.0.2.

Comment 58 Vedran Miletić 2017-02-10 15:14:49 UTC
Is the SRPM somewhere where non-subscribers can find it?

Comment 60 Pavlos Parissis 2017-03-17 15:19:49 UTC
I would like to mention that users of HAProxy 1.7 version and higher need openssl 1.0.2 version in order to utilize a certain functionality of HAProxy, which can offer RSA and ECC SSL certificates based on what the client supports.
ECC SSL certificates are very popular these days due to the performance/latency benefits they offer.

So, having openssl 1.0.2 version available in RedHat 7.4 version will make a lot of customer happy.

Comment 61 Tomas Mraz 2017-04-03 14:16:09 UTC
*** Bug 1155180 has been marked as a duplicate of this bug. ***

Comment 62 Tomas Mraz 2017-04-03 14:16:59 UTC
*** Bug 1220789 has been marked as a duplicate of this bug. ***

Comment 63 Tomas Mraz 2017-04-03 14:25:46 UTC
*** Bug 1352941 has been marked as a duplicate of this bug. ***

Comment 64 Tomas Mraz 2017-04-03 14:27:56 UTC
*** Bug 1356178 has been marked as a duplicate of this bug. ***

Comment 65 Tomas Mraz 2017-04-03 14:30:56 UTC
*** Bug 1386347 has been marked as a duplicate of this bug. ***

Comment 66 Tomas Mraz 2017-04-03 14:31:34 UTC
*** Bug 1388051 has been marked as a duplicate of this bug. ***

Comment 67 Tomas Mraz 2017-04-03 14:34:01 UTC
*** Bug 1394948 has been marked as a duplicate of this bug. ***

Comment 68 Tomas Mraz 2017-04-03 14:34:41 UTC
*** Bug 1411238 has been marked as a duplicate of this bug. ***

Comment 70 errata-xmlrpc 2017-08-01 18:16:10 UTC
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://access.redhat.com/errata/RHBA-2017:1929

Comment 71 Bill Nottingham 2017-09-14 20:00:30 UTC
Just to note - while this is noted to be API/ABI compatible, it's only one-way compatible due to the introduction of new symbol versions.

Comment 72 Tomas Mraz 2017-09-15 07:30:25 UTC
Sure, however I think this is somewhat implicit.


Note You need to log in before you can comment on or make changes to this bug.