Bug 1276310 (rhel7-openssl1.0.2)

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

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.

Afaik the httpd server (apache) does not support NPN, only ALPN is supported for HTTPS.

*** Bug 1322148 has been marked as a duplicate of this bug. ***

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.

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.

Correct, hence my comment about waiting for ALPN.

The version of Tomcat Native that ships with Tomcat 8 now requires OpenSSL 1.0.2+ as well.

(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 :)

*** Bug 1353273 has been marked as a duplicate of this bug. ***

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.

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

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

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

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

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

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.

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?

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.

(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

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.

(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/

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

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.

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)

*** Bug 1409925 has been marked as a duplicate of this bug. ***

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.

1.1 is completely API and ABI incompatible and thus not possible to be used by existing Red Hat Enterprise Linux releases.

(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).

(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".

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.

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.

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

*** Bug 1418253 has been marked as a duplicate of this bug. ***

Is someone from Red Hat looking at this?
This is a problem on a world scale, We urgently need openssl 1.0.2.

Is the SRPM somewhere where non-subscribers can find it?

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.

*** Bug 1155180 has been marked as a duplicate of this bug. ***

*** Bug 1220789 has been marked as a duplicate of this bug. ***

*** Bug 1352941 has been marked as a duplicate of this bug. ***

*** Bug 1356178 has been marked as a duplicate of this bug. ***

*** Bug 1386347 has been marked as a duplicate of this bug. ***

*** Bug 1388051 has been marked as a duplicate of this bug. ***

*** Bug 1394948 has been marked as a duplicate of this bug. ***

*** Bug 1411238 has been marked as a duplicate of this bug. ***

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

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.

Sure, however I think this is somewhat implicit.