Bug #9744
closed
fatal error if ECDH Curve not default
100%
Description
If you select ECDH Curve server option other than default, <ecdh_curve>Oakley-EC2N-4</ecdh_curve> as example, you got:
Sep 11 13:56:58 pf4 openvpn77881: OpenVPN 2.4.7 amd64-portbld-freebsd12.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jul 18 2019
Sep 11 13:56:58 pf4 openvpn77881: library versions: OpenSSL 1.1.1a-freebsd 20 Nov 2018, LZO 2.10
Sep 11 13:56:58 pf4 openvpn78203: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 11 13:56:58 pf4 openvpn78203: SSL_CTX_set_tmp_ecdh: cannot add curve
Sep 11 13:56:58 pf4 openvpn78203: Exiting due to fatal error
no such problem on pfSense 2.4.4-p3
2.5.0-DEVELOPMENT (amd64)
built on Tue Sep 10 19:08:55 EDT 2019
FreeBSD 12.0-RELEASE-p10
Updated by Jim Pingle over 5 years ago
- Target version set to 2.5.0
That's internal to OpenVPN/OpenSSL. The GUI presents the curves it claims to support exactly (From /usr/local/sbin/openvpn --show-curves) and it's using the correct config syntax. So from the looks of it, we're doing everything properly. If support wasn't there it would have complained much earlier and with a different error.
Updated by Viktor Gurov over 5 years ago
Jim Pingle wrote:
That's internal to OpenVPN/OpenSSL. The GUI presents the curves it claims to support exactly (From
/usr/local/sbin/openvpn --show-curves) and it's using the correct config syntax. So from the looks of it, we're doing everything properly. If support wasn't there it would have complained much earlier and with a different error.
OpenVPN 2.4.7 issue - same on Debian 10 and clean FreeBSD 12
no error with secp* curves:
secp112r1
secp112r2
secp128r1
secp128r2
secp160k1
secp160r1
secp160r2
secp192k1
secp224k1
secp224r1
secp256k1
secp384r1
secp521r1
and OpenVPN successfully run if you use random name for ecdh-curve option, i.e.:
ecdh-curve abc12345
Updated by Jim Pingle over 5 years ago
Looks like https://community.openvpn.net/openvpn/ticket/1177
The initial title of the bug mentions FIPS but later in a comment they correct that to OpenSSL 1.1.1
Updated by Jim Pingle about 5 years ago
- Assignee set to Jim Pingle
If it works with the secp* curves then maybe we should filter the list like we have done for HTTPS and IPsec. At least until OpenVPN fixes that bug. Though the exact same method won't work as the OpenVPN CA/Cert functions are a bit more involved. We may still be able to leverage the same mechanism somehow, though.
Updated by Jim Pingle about 5 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset bc3e78ab3dd4bffb89cb8d2533199e37f92fcbf2.
Updated by Viktor Gurov about 5 years ago
last test result with pfSense 2.5.0.a.20191121.2127 (OpenVPN 2.4.8) and Debian 10.2 client (OpenVPN 2.4.7)
server start failed error:
Exiting due to fatal error SSL_CTX_set_tmp_ecdh: cannot add curve
client TLS error:
TLS Error: TLS handshake failed TLS Error: TLS object -> incoming plaintext read error TLS_ERROR: BIO read tls_read_plaintext error OpenSSL: error:141F7065:SSL routines:final_key_share:no suitable key share
secp112r1 - server start failed
secp112r2 - server start failed
secp128r1 - server start failed
secp128r2 - server start failed
secp160k1 - server started, client TLS error
secp160r1 - server started, client TLS error
secp160r2 - server started, client TLS error
secp192k1 - server started, client TLS error
secp224k1 - server started, client TLS error
secp224r1 - server started, client TLS error
secp256k1 - server started, client TLS error
secp384r1 - server started, client connected
secp521r1 - server started, client connected
also tested with prime256v1 - server started, client connected
so, OpenVPN ECDH curves = IPsec curves
Updated by Jim Pingle about 5 years ago
I pushed an update in ca3cddbec4 to change the OpenVPN curve list to match IPsec
Updated by Viktor Gurov about 5 years ago
Jim Pingle wrote:
I pushed an update in ca3cddbec4 to change the OpenVPN curve list to match IPsec
tested on 2.5.0.a.20191210.1722
Resolved
Updated by Jim Pingle about 5 years ago
- Status changed from Feedback to Resolved