Opened 6 years ago
Closed 3 years ago
#1048 closed Bug / Defect (worksforme)
TLS error: The server has no TLS ciphersuites in common with the client. Your --tls-cipher setting might be too restrictive.
Reported by: | jobber777 | Owned by: | Steffan Karger |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Crypto | Version: | OpenVPN 2.4.5 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
Problem with connect from Windows client openvpn V2.4.5
Server
OpenSSL 1.1.0f 25 May 2017
OpenVPN conf
proto tcp local 46.148.16.1 port 443 dev tun2 ca /root/sample-keys/ca.crt cert /root/sample-keys/server-ec.crt key /root/sample-keys/server-ec.key tls-auth /root/sample-keys/ta.key 0 dh /root/sample-keys/dh2048.pem server 10.1.0.0 255.255.0.0 topology subnet ecdh-curve secp256k1 persist-key persist-tun user root group nogroup status /root/sample-keys/openvpn-udp-status.log 2 verb 4 push "redirect-gateway def1" keepalive 20 120 script-security 2
Server log
Thu Mar 29 21:09:43 2018 us=452791 OpenVPN 2.4.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 1 2018 Thu Mar 29 21:09:43 2018 us=452919 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08 Thu Mar 29 21:09:43 2018 us=454399 Diffie-Hellman initialized with 2048 bit key Thu Mar 29 21:09:43 2018 us=455621 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Mar 29 21:09:43 2018 us=456022 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Mar 29 21:09:43 2018 us=456389 TLS-Auth MTU parms [ L:1623 D:1182 EF:68 EB:0 ET:0 EL:3 ] Thu Mar 29 21:09:43 2018 us=463121 TUN/TAP device tun2 opened Thu Mar 29 21:09:43 2018 us=463274 TUN/TAP TX queue length set to 100 Thu Mar 29 21:09:43 2018 us=463368 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Thu Mar 29 21:09:43 2018 us=463433 /sbin/ip link set dev tun2 up mtu 1500 Thu Mar 29 21:09:43 2018 us=478753 /sbin/ip addr add dev tun2 10.1.0.1/16 broadcast 10.1.255.255 Thu Mar 29 21:09:43 2018 us=495497 Data Channel MTU parms [ L:1623 D:1450 EF:123 EB:406 ET:0 EL:3 ] Thu Mar 29 21:09:43 2018 us=497751 Could not determine IPv4/IPv6 protocol. Using AF_INET Thu Mar 29 21:09:43 2018 us=500428 Socket Buffers: R=[87380->87380] S=[16384->16384] Thu Mar 29 21:09:43 2018 us=500822 Listening for incoming TCP connection on [AF_INET]46.148.16.14:443 Thu Mar 29 21:09:43 2018 us=501234 TCPv4_SERVER link local (bound): [AF_INET]46.148.16.14:443 Thu Mar 29 21:09:43 2018 us=507497 TCPv4_SERVER link remote: [AF_UNSPEC] Thu Mar 29 21:09:43 2018 us=507908 GID set to nogroup Thu Mar 29 21:09:43 2018 us=508343 UID set to root Thu Mar 29 21:09:43 2018 us=509004 MULTI: multi_init called, r=256 v=256 Thu Mar 29 21:09:43 2018 us=527945 IFCONFIG POOL: base=10.1.0.2 size=65532, ipv6=0 Thu Mar 29 21:09:43 2018 us=530924 MULTI: TCP INIT maxclients=1024 maxevents=1028 Thu Mar 29 21:09:43 2018 us=531549 Initialization Sequence Completed Thu Mar 29 21:09:53 2018 us=999756 MULTI: multi_create_instance called Thu Mar 29 21:09:54 2018 us=1413 Re-using SSL/TLS context Thu Mar 29 21:09:54 2018 us=2515 Control Channel MTU parms [ L:1623 D:1182 EF:68 EB:0 ET:0 EL:3 ] Thu Mar 29 21:09:54 2018 us=2697 Data Channel MTU parms [ L:1623 D:1450 EF:123 EB:406 ET:0 EL:3 ] Thu Mar 29 21:09:54 2018 us=2778 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server' Thu Mar 29 21:09:54 2018 us=2828 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client' Thu Mar 29 21:09:54 2018 us=3118 TCP connection established with [AF_INET]95.213.164.4:50838 Thu Mar 29 21:09:54 2018 us=5420 TCPv4_SERVER link local: (not bound) Thu Mar 29 21:09:54 2018 us=5929 TCPv4_SERVER link remote: [AF_INET]95.213.164.4:50838 Thu Mar 29 21:09:54 2018 us=985344 95.213.164.4:50838 TLS: Initial packet from [AF_INET]95.213.164.4:50838, sid=92f00a1d f06d3447 Thu Mar 29 21:09:55 2018 us=58107 95.213.164.4:50838 TLS error: The server has no TLS ciphersuites in common with the client. Your --tls-cipher setting might be too restrictive. Thu Mar 29 21:09:55 2018 us=58811 95.213.164.4:50838 OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher Thu Mar 29 21:09:55 2018 us=59324 95.213.164.4:50838 TLS_ERROR: BIO read tls_read_plaintext error Thu Mar 29 21:09:55 2018 us=59824 95.213.164.4:50838 TLS Error: TLS object -> incoming plaintext read error Thu Mar 29 21:09:55 2018 us=60320 95.213.164.4:50838 TLS Error: TLS handshake failed Thu Mar 29 21:09:55 2018 us=60881 95.213.164.4:50838 Fatal TLS error (check_tls_errors_co), restarting Thu Mar 29 21:09:55 2018 us=61264 95.213.164.4:50838 SIGUSR1[soft,tls-error] received, client-instance restarting
client Windows 7 x64 openvpn V2.4.5, openssl OpenSSL 1.1.0f 25 May 2017
conf
client key-direction 1 remote 46.148.16.1 443 tcp resolv-retry infinite dev tun persist-key persist-tun ecdh-curve secp256k1 nobind verb 4 pull register-dns block-outside-dns keepalive 20 120 remote-cert-tls server script-security 2 <ca> ///// </ca> <cert> ///////// </cert> <key> //////////// </key> <tls-auth> ///////// </tls-auth>
but connect from Linux client OpenVPN v 2.4.5 with this config success
Thu Mar 29 21:34:24 2018 us=18703 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server' Thu Mar 29 21:34:24 2018 us=19235 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client' Thu Mar 29 21:34:24 2018 us=19589 TCP connection established with [AF_INET]46.148.16.14:53400 Thu Mar 29 21:34:24 2018 us=20133 TCPv4_SERVER link local: (not bound) Thu Mar 29 21:34:24 2018 us=20729 TCPv4_SERVER link remote: [AF_INET]46.148.16.14:53400 Thu Mar 29 21:34:24 2018 us=21725 46.148.16.14:53400 TLS: Initial packet from [AF_INET]46.148.16.14:53400, sid=fa825a40 8d8e2ccf Thu Mar 29 21:34:24 2018 us=110349 46.148.16.14:53400 VERIFY OK: depth=1, C=KG, ST=NA, L=BISHKEK, O=OpenVPN-TEST, emailAddress=me@myhost.mydomain Thu Mar 29 21:34:24 2018 us=111167 46.148.16.14:53400 VERIFY OK: depth=0, C=KG, ST=NA, O=OpenVPN-TEST, CN=Test-Client-EC, emailAddress=me@myhost.mydomain Thu Mar 29 21:34:24 2018 us=155535 46.148.16.14:53400 peer info: IV_VER=2.4.5 Thu Mar 29 21:34:24 2018 us=156102 46.148.16.14:53400 peer info: IV_PLAT=linux Thu Mar 29 21:34:24 2018 us=156540 46.148.16.14:53400 peer info: IV_PROTO=2 Thu Mar 29 21:34:24 2018 us=156952 46.148.16.14:53400 peer info: IV_NCP=2 Thu Mar 29 21:34:24 2018 us=157384 46.148.16.14:53400 peer info: IV_LZ4=1 Thu Mar 29 21:34:24 2018 us=158115 46.148.16.14:53400 peer info: IV_LZ4v2=1 Thu Mar 29 21:34:24 2018 us=158561 46.148.16.14:53400 peer info: IV_LZO=1 Thu Mar 29 21:34:24 2018 us=158969 46.148.16.14:53400 peer info: IV_COMP_STUB=1 Thu Mar 29 21:34:24 2018 us=159377 46.148.16.14:53400 peer info: IV_COMP_STUBv2=1 Thu Mar 29 21:34:24 2018 us=159695 46.148.16.14:53400 peer info: IV_TCPNL=1 Thu Mar 29 21:34:24 2018 us=161159 46.148.16.14:53400 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit EC, curve: secp256k1 Thu Mar 29 21:34:24 2018 us=161502 46.148.16.14:53400 [Test-Client-EC] Peer Connection Initiated with [AF_INET]46.148.16.14:53400 Thu Mar 29 21:34:24 2018 us=162019 Test-Client-EC/46.148.16.14:53400 MULTI_sva: pool returned IPv4=10.1.0.2, IPv6=(Not enabled) Thu Mar 29 21:34:24 2018 us=162453 Test-Client-EC/46.148.16.14:53400 MULTI: Learn: 10.1.0.2 -> Test-Client-EC/46.148.16.14:53400 Thu Mar 29 21:34:24 2018 us=162770 Test-Client-EC/46.148.16.14:53400 MULTI: primary virtual IP for Test-Client-EC/46.148.16.14:53400: 10.1.0.2 Thu Mar 29 21:34:25 2018 us=236965 Test-Client-EC/46.148.16.14:53400 PUSH: Received control message: 'PUSH_REQUEST' Thu Mar 29 21:34:25 2018 us=237074 Test-Client-EC/46.148.16.14:53400 SENT CONTROL [Test-Client-EC]: 'PUSH_REPLY,redirect-gateway def1,route-gateway 10.1.0.1,topology subnet,ping 20,ping-restart 120,ifconfig 10.1.0.2 255.255.0.0,peer-id 0,cipher AES-256-GCM' (status=1) Thu Mar 29 21:34:25 2018 us=237147 Test-Client-EC/46.148.16.14:53400 Data Channel: using negotiated cipher 'AES-256-GCM' Thu Mar 29 21:34:25 2018 us=237214 Test-Client-EC/46.148.16.14:53400 Data Channel MTU parms [ L:1551 D:1450 EF:51 EB:406 ET:0 EL:3 ] Thu Mar 29 21:34:25 2018 us=237322 Test-Client-EC/46.148.16.14:53400 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Mar 29 21:34:25 2018 us=237375 Test-Client-EC/46.148.16.14:53400 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Change History (6)
comment:1 Changed 6 years ago by
Priority: | critical → minor |
---|
comment:2 Changed 6 years ago by
Your server appears to be using an ec cert with curve secp256k1 causing the "no matching ciphers" error as client does not announce that curve as supported. Unlike 1.0, OpenSSL 1.1.0 includes only a limited set of ec curves in client-hello. In particular, secp256k1 is not included.
The curve itself is supported by OpenSSL 1.1.0 (just not in the defaults). I would have thought that the option --ecdh-curve
would have enabled it, but, for some reason, it appears to be parsed only on the server, not on the client.
comment:3 Changed 6 years ago by
Just found #963 is related to this. As Steffan explains there --ecdh-curve is only used for key-exchange so not relevant here.
So it does appear we need an option to set non-default curves in the ssl-context.
comment:5 Changed 6 years ago by
First of all: using more standard curves will cause you less trouble. The OpenSSL naming here doesn't really help; you probably wanted to use P-256, which is confusingly named 'prime256v1' in openssl (while P-384 is named 'secp384r1').
To figure out if using secp256k1 as an ecdh curve is indeed the problem: does it work if you remove the ecdh-curve
line from the server config, or change that to ecdh-curve prime256v1
?
comment:6 Changed 3 years ago by
Milestone: | release 2.4.5 |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
As far as I understand, a number of bugfixes related to EC curve selection and configuration went into OpenVPN, and bugfixes went into OpenSSL itself.
So, if this still happens with 2.4.10 or 2.5.1, linked against OpenSSL 1.1.1* please re-open.
Otherwise, closing as "overtaken by events".
quite likely the linux client is built with openssl 1.0.x, while the windows client is using openssl 1.1.0 (as of 2.4.5, earlier versions were built with 1.0.x) - which has different security profiles.
Since your client logs are missing, this is guesswork, though...