iOS ECDSA config works on iPad but not iPhone (same versions, same config)

[seb101]

Hi,

I've got a weird error. I just upgraded my whole infrastructure to run ECDSA certs, they are working on my PC client and on my iPad clients running iOS 11.4.1 and OVPN Connect 3.2, however it refuses to work on my iPhone also running iOS 11.4.1 and OVPN Connect 3.2.

When the iPad Client connects I get:

Code: Select all

Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: 85.255.**.**:53133 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit EC, curve: secp521r1
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: 85.255.**.**:53133 [vpn-client-ipad] Peer Connection Initiated with [AF_INET]85.255.**.**:53133
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: vpn-client-ipad/85.255.**.**:53133 MULTI_sva: pool returned IPv4=192.168.200.2, IPv6=(Not enabled)
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: vpn-client-ipad/85.255.**.**:53133 MULTI: Learn: 192.168.200.2 -> vpn-client-ipad/85.255.**.**:53133
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: vpn-client-ipad/85.255.**.**:53133 MULTI: primary virtual IP for vpn-client-ipad/85.255.**.**:53133: 192.168.200.2
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: vpn-client-ipad/85.255.**.**:53133 PUSH: Received control message: 'PUSH_REQUEST'
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: vpn-client-ipad/85.255.**.**:53133 SENT CONTROL [vpn-client-ipad]: 'PUSH_REPLY,compress lz4,persist-key,persist-tun,topology subnet,redirect-gateway def1,route-gateway dhcp,route 192.168.200.0 255.255.255.0,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,dhcp-option DOMAIN lan,route-gateway 192.168.200.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.200.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: vpn-client-ipad/85.255.**.**:53133 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Sep 10 20:01:45 2018 daemon.notice openvpn(vpnserver)[28496]: vpn-client-ipad/85.255.**.**:53133 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

When the iPhone client connects I get:

Code: Select all

Mon Sep 10 20:03:03 2018 daemon.notice openvpn(vpnserver)[28496]: 85.255.**.**:4195 TLS: Initial packet from [AF_INET]85.255.**.**:4195, sid=25dadaba 5b388ecf
Mon Sep 10 20:03:03 2018 daemon.err openvpn(vpnserver)[28496]: 85.255.**.**:4195 TLS error: The server has no TLS ciphersuites in common with the client. Your --tls-cipher setting might be too restrictive.
Mon Sep 10 20:03:03 2018 daemon.err openvpn(vpnserver)[28496]: 85.255.**.**:4195 OpenSSL: error:1408A0C1:lib(20):func(138):reason(193)
Mon Sep 10 20:03:03 2018 daemon.err openvpn(vpnserver)[28496]: 85.255.**.**:4195 TLS_ERROR: BIO read tls_read_plaintext error
Mon Sep 10 20:03:03 2018 daemon.err openvpn(vpnserver)[28496]: 85.255.**.**:4195 TLS Error: TLS object -> incoming plaintext read error
Mon Sep 10 20:03:03 2018 daemon.err openvpn(vpnserver)[28496]: 85.255.**.**:4195 TLS Error: TLS handshake failed

Their configs are identical.

Is there a different in the builds of the app between the iPhone and iPad platform?

[seb101]

Correction - this does not specifically relate to ECDSA. I've just reverted back to RSA based certs and it is still giving the same error with the new server config.

The TLS setting is: tls_cipher 'TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384'

Is it possible certain ciphers on the device can be blocked by policy?

Is there any way to get a more detailed debug log out of the iOS client?

[seb101]

If I disable the restrictive tls-cipher option the iPhone negotiates DHE-RSA-AES256-SHA

iPad (same OVPN and same iOS) on the otherhand still negotiates ECDHE-RSA-AES256-GCM-SHA384

Confused.

[ordex]

weird, especially because both apps bundle the same mbedTLS library.