I do not think downstream patching openssl behavior is really necessary. The applications that want to support 1.0.2 properly should simply call the SSL_CTX_set_ecdh_auto() otherwise they would depend on RHEL-specific behavior.

(In reply to Tomas Mraz from comment #1)
> I do not think downstream patching openssl behavior is really necessary. The
> applications that want to support 1.0.2 properly should simply call the
> SSL_CTX_set_ecdh_auto() otherwise they would depend on RHEL-specific
> behavior.

I think that this view is not adequate for current conditions:
- security requirements have tightened since el7 release, PFS should be standard now
- RHEL 7 still didn't reach half of it's active life yet and it contains whole lot of openssl-based apps* whose upstreams don't need to change. Will we request all their maintainers to check if they have SSL_CTX_set_ecdh_auto(), or will it be better to change library to make ECDH* stuff work by default?

IOW, openssl is a utility library for most of its users and even adding of a single unnecessary line to 100s of programs may be greater load with greater security implications than change to a library that'd fix the issue for all its users at once.

* It seems interesting that openssl-based clients don't need to call SSL_CTX_set_ecdh_auto() as of RHEL 7.5 as can be verified by:
# yum install openssl virt-viewer
$ openssl s_server -key SEVER_KEY -cert SERVER_CERT -accept 5950 -cipher ECDHE-RSA-AES256-GCM-SHA384
// other terminal
$ remote-viewer [--spice-ca-cert CA_FILE] remote-viewer spice://NAME_OR_IP/?tls-port=5950

--> connection succeeds without need to call SSL_CTX_set_ecdh_auto() in client code

The situation is particularly nasty in one aspect: if you set cipher suites just to ECDHE_* and you don't call SSL_CTX_set_ecdh_auto(), there'll be no cipher overlap with no warning of openssl in the server app:
// server
$ /usr/libexec/qemu-kvm -monitor stdio -vga qxl -spice tls-port=5950,password=123,x509-dir=/etc/pki/libvirt-spice,tls-ciphers=ECDHE-RSA-AES256-GCM-SHA384
(qemu) info spice
Server:
     address: 0.0.0.0:5800 [tls]
    migrated: false
        auth: spice
    compiled: 0.12.8
  mouse-mode: server
Channels: none
(qemu) 139929495890752:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1435:

(process:17125): Spice-WARNING **: reds-stream.c:469:reds_stream_ssl_accept: SSL_accept failed, error=1

// client
$ remote-viewer spice://$(hostname)/?tls-port=5950 

(remote-viewer:17216): GSpice-WARNING **: main-1:0: SSL_connect: error:00000001:lib(0):func(0):reason(1)

These applications did not properly work with ECDH with openssl upstream for many years. And there are other Linux based OSes that are even commercially supported that also still contain openssl 1.0.2.

No, if application wants to support 1.0.2, it must call SSL_CTX_set_ecdh_auto().

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.