Bug 1565165 - Enable ECDH context by default as 1.1.0 does (to avoid RHEL-only calls of SSL_CTX_set_ecdh_auto())
Summary: Enable ECDH context by default as 1.1.0 does (to avoid RHEL-only calls of SSL...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssl
Version: 7.7-Alt
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-09 14:19 UTC by David Jaša
Modified: 2019-02-11 15:41 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-11 15:41:42 UTC
Target Upstream Version:


Attachments (Terms of Use)
simple test server (3.54 KB, text/plain)
2018-04-09 14:19 UTC, David Jaša
no flags Details

Description David Jaša 2018-04-09 14:19:51 UTC
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 [1] in favour of automatic ECDH context setting with said function implemented as just noop macro [2].

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

[1] https://git.openssl.org/?p=openssl.git;a=blob;f=CHANGES;h=7199f3d1961738a6e8709ba1c8de277b62c0304e;hb=refs/heads/OpenSSL_1_1_0-stable#l871
[2] https://git.openssl.org/?p=openssl.git;a=commit;h=2ecb9f2d18614fb7b7b42830a358b7163ed43221

Version-Release number of selected component (if applicable):
openssl-1.0.2k-12.el7.x86_64 (RHEL 7.5)

How reproducible:
always

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)
2.
3.

Actual results:
no ciphers overlap (or no ECDHE and by extension, no PFS)

Expected results:
openssl should provide PFS by default

Additional info:
example program hit by this issue is spice server.

Comment 1 Tomas Mraz 2018-04-09 16:04:01 UTC
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.

Comment 2 David Jaša 2018-04-11 14:10:16 UTC
(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)

Comment 3 Tomas Mraz 2018-04-11 15:06:29 UTC
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().

Comment 4 Simo Sorce 2019-02-11 15:41:42 UTC
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.


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