Created attachment 1419330 [details]
simple test server
Description of problem:
In order to use ECDHE_* cipher suites, OpenSSL < 1.1.0 require apps to call SSL_CTX_set_ecdh_auto(), while OpenSSL >= 1.1.0 deprecated this  in favour of automatic ECDH context setting with said function implemented as just noop macro .
This puts apps in less-than-ideal situation
- apps unavare of SSL_..._ecdh_auto() do not have PFS
- apps that always SSL_..._ecdh_auto() have dead code on more recent platforms (Fedora)
- apps that want SSL_..._ecdh_auto() just on RHEL needs to ifdef it
Each and every of them. IMO the correct solution to this is to backport 1.1.0 behaviour to RHEL's 1.0.2k so that every context has ECDH enabled by default
Version-Release number of selected component (if applicable):
openssl-1.0.2k-12.el7.x86_64 (RHEL 7.5)
Steps to Reproduce:
1. connect with client supporting just ECDHE_* cipher suites to program not using SSL_CTX_set_ecdh_auto() (e.g. openssl s_client to attached test server without -a option)
no ciphers overlap (or no ECDHE and by extension, no PFS)
openssl should provide PFS by default
example program hit by this issue is spice server.
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
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:
$ /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
address: 0.0.0.0:5800 [tls]
(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
$ 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.