Opened 5 months ago

Last modified 5 months ago

#1048 new Bug / Defect

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: release 2.4.5
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 (5)

comment:1 Changed 5 months ago by Gert Döring

Priority: criticalminor

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...

comment:2 Changed 5 months ago by selvanair

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 5 months ago by selvanair

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:4 Changed 5 months ago by tincantech

CC

comment:5 Changed 5 months ago by Steffan Karger

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?

Note: See TracTickets for help on using tickets.