OpeonConnect fails with generic TLS Fatal Alert Error

Bug #1822467 reported by J.P.
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
openconnect (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Works in Ubuntu 18.04, fails in 18.10 and the upcoming 19.04. Appears to be a problem with a cipher no longer included, maybe? See here, as it's not just ubuntu that is having this issue:

https://www.reddit.com/r/Fedora/comments/a6hc0c/help_networkmanger_w_openconnect_gives_a_tls_error/

I've removed information about the VPN host. I can disclose that it is a Cisco AnyConnect VPN service.

OpenConnect output:

POST https://vpn-host.tld/
Attempting to connect to server xxxxxx:443
Connected to xxxxxx:443
SSL negotiation with vpn-host.tld
SSL connection failure: A TLS fatal alert has been received.
Failed to open HTTPS connection to vpn-host.tld

gnutls-cli output:

$ gnutls-cli -V vpn-host.tld
Processed 128 CA certificate(s).
Resolving 'vpn-host.tld:443'...
Connecting to 'xxxxxx:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed

$ gnutls-cli -d 2 vpn-host.tld
Processed 128 CA certificate(s).
Resolving 'vpn-host.tld:443'...
Connecting to 'xxxxxx:443'...
|<2>| added 6 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list
|<2>| Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite 13.03 (GNUTLS_CHACHA20_POLY1305_SHA256)
|<2>| Keeping ciphersuite 13.01 (GNUTLS_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite 13.04 (GNUTLS_AES_128_CCM_SHA256)
|<2>| Keeping ciphersuite c0.2c (GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.a9 (GNUTLS_ECDHE_ECDSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.ad (GNUTLS_ECDHE_ECDSA_AES_256_CCM)
|<2>| Keeping ciphersuite c0.0a (GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite c0.2b (GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.ac (GNUTLS_ECDHE_ECDSA_AES_128_CCM)
|<2>| Keeping ciphersuite c0.09 (GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite c0.30 (GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.a8 (GNUTLS_ECDHE_RSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.14 (GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite c0.2f (GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.13 (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9d (GNUTLS_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite c0.9d (GNUTLS_RSA_AES_256_CCM)
|<2>| Keeping ciphersuite 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9c (GNUTLS_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.9c (GNUTLS_RSA_AES_128_CCM)
|<2>| Keeping ciphersuite 00.2f (GNUTLS_RSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9f (GNUTLS_DHE_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.aa (GNUTLS_DHE_RSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.9f (GNUTLS_DHE_RSA_AES_256_CCM)
|<2>| Keeping ciphersuite 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9e (GNUTLS_DHE_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.9e (GNUTLS_DHE_RSA_AES_128_CCM)
|<2>| Keeping ciphersuite 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1)
|<2>| Advertizing version 3.4
|<2>| Advertizing version 3.3
|<2>| Advertizing version 3.2
|<2>| Advertizing version 3.1
|<2>| HSK[0x5649deb82390]: sent server name: 'vpn-host.tld'
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed

J.P. (jptrosclair-6)
affects: kinit (Ubuntu) → openconnect (Ubuntu)
Revision history for this message
dwmw2 (dwmw2) wrote :
Revision history for this message
Dan Lenski (lenski) wrote :

@dwmw2, did you delete issue #21? Or make it confidential? I can't see it even when logged in to Gitlab.

Revision history for this message
dwmw2 (dwmw2) wrote :

Er, the latter. On request from the reported, after he attached a tcpdump. I've deleted that and made it public again. And also granted you permissions on the gitlab project so you should be able to see it anyway (amongst other things).

Revision history for this message
J.P. (jptrosclair-6) wrote :

I've read through the bug report linked above and have tried building OpenConnect with +SHA256 added with no luck. I may be missing something else that was done to get it working. I do know if I build against gnutls 3.5.18 it does work so it does look like the priority string change going to 3.5.19 is likely the problem as discovered in that bug report and I'm doing something wrong building it, I guess.

$ git status
HEAD detached at 5a3f242e

$ ./openconnect --version
OpenConnect version v8.02-9-g5a3f242e
Using GnuTLS. Features present: PKCS#11, HOTP software token, TOTP software token, System keys, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp

$ grep default_prio gnutls.c
  const char *default_prio;
  default_prio = DEFAULT_PRIO ":%COMPAT";
  default_prio = "NORMAL:-VERS-SSL3.0:+SHA256:%COMPAT";
     default_prio, vpninfo->pfs?":-RSA":"", vpninfo->no_tls13?":-VERS-TLS1.3":"");

$ strings /usr/lib/x86_64-linux-gnu/libopenconnect.so.5.5.0 | grep ^NORMAL
NORMAL:-VERS-SSL3.0:%COMPAT

$ strings .libs/libopenconnect.so.5.5.0 | grep ^NORMAL
NORMAL:-VERS-SSL3.0:+SHA256:%COMPAT

$ ./openconnect vpn-host.tld
POST https://vpn-host.tld/
Connected to nnnnnnnnn:443
SSL negotiation with vpn-host.tld
SSL connection failure: A TLS fatal alert has been received.
Failed to open HTTPS connection to vpn-host.tld
Failed to obtain WebVPN cookie

Build the same openconnect against gnutls 3.5.18 and it works:

$ export PKG_CONFIG_PATH=/opt/gnutls-3.5.18/lib/pkgconfig/
$ ./configure
$ make
$ ./openconnect vpn-host.tld
POST https://vpn-host.tld/
Connected to nnnnnnnnn:443
SSL negotiation with vpn-host.tld
Connected to HTTPS on vpn-host.tld

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openconnect (Ubuntu):
status: New → Confirmed
Revision history for this message
Jake Palmer (jakep82) wrote :

Any solution to this that doesn't involve building from source? I have this problem in Ubuntu 19.10. Openconnect works fine in 18.04, but I get a TLS error in anything newer.

Revision history for this message
J.P. (jptrosclair-6) wrote :

On Fedora latest stable enabling legacy crypto policies solves this for me. I’m on my phone and haven’t spent a lot of time googling how to do this for Ubuntu but here’s the fedora docs for reference:

https://fedoraproject.org/wiki/Changes/StrongCryptoSettings

Revision history for this message
J.P. (jptrosclair-6) wrote :
Download full text (4.5 KiB)

I'm not sure this "fixable" on Ubuntu with the standard build of openconnect, at least not by messing with system default priorities for gnutls. Correct me if I'm wrong but I've done some digging this morning and comparing the openconnect build on ubuntu 19.10 against the fedora build the main difference with regards to the priority strings is that the fedora build is specifically checking for a system or openconnect default policy:

@OPENCONNECT,SYSTEM:%COMPAT

Which I believe allows you to override via system level policies for the priority string, hence the update-crypto-policies noted in the link above. On Ubuntu 19.10, this is the policy string I see in libopenconnect.so.5.5.0:

NORMAL:-VERS-SSL3.0:%COMPAT

If it had a similar policy string, for example @SYSTEM or @OPENCONNECT, you could theoretically (I haven't tested) override OpenConnect's default using /etc/gnutls/config. I tested this priority string, which is what Fedora sets when enabling legacy crypto, and gnutls-cli does not complain when connecting to the AnyConnect host I have this issue with.

$ cat /etc/gnutls/config
[priorities]
SYSTEM=NORMAL:+3DES-CBC:+ARCFOUR-128

$ gnutls-cli --priority @SYSTEM --list
Cipher suites for @SYSTEM
TLS_AES_256_GCM_SHA384 0x13, 0x02 TLS1.3
TLS_CHACHA20_POLY1305_SHA256 0x13, 0x03 TLS1.3
TLS_AES_128_GCM_SHA256 0x13, 0x01 TLS1.3
TLS_AES_128_CCM_SHA256 0x13, 0x04 TLS1.3
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2
TLS_ECDHE_ECDSA_CHACHA20_POLY1305 0xcc, 0xa9 TLS1.2
TLS_ECDHE_ECDSA_AES_256_CCM 0xc0, 0xad TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a TLS1.0
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 0xc0, 0x2b TLS1.2
TLS_ECDHE_ECDSA_AES_128_CCM 0xc0, 0xac TLS1.2
TLS_ECDHE_ECDSA_AES_128_CBC_SHA1 0xc0, 0x09 TLS1.0
TLS_ECDHE_ECDSA_3DES_EDE_CBC_SHA1 0xc0, 0x08 TLS1.0
TLS_ECDHE_ECDSA_ARCFOUR_128_SHA1 0xc0, 0x07 TLS1.0
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2
TLS_ECDHE_RSA_CHACHA20_POLY1305 0xcc, 0xa8 TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14 TLS1.0
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA1 0xc0, 0x13 TLS1.0
TLS_ECDHE_RSA_3DES_EDE_CBC_SHA1 0xc0, 0x12 TLS1.0
TLS_ECDHE_RSA_ARCFOUR_128_SHA1 0xc0, 0x11 TLS1.0
TLS_RSA_AES_256_GCM_SHA384 0x00, 0x9d TLS1.2
TLS_RSA_AES_256_CCM 0xc0, 0x9d TLS1.2
TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 TLS1.0
TLS_RSA_AES_128_GCM_SHA256 0x00, 0x9c TLS1.2
TLS_RSA_AES_128_CCM 0xc0, 0x9c TLS1.2
TLS_RSA_AES_128_CBC_SHA1 0x00, 0x2f TLS1.0
TLS_RSA_3DES_EDE_CBC_SHA1 0x00, 0x0a TLS1.0
TLS_RSA_ARCFOUR_128_SHA1 0x00, 0x05 TLS1.0
TLS_DHE_RSA_AES_256_GCM_SHA384 ...

Read more...

Revision history for this message
Dan Lenski (lenski) wrote :

It's not an immediate fix for anyone, but we are working on a patch set which will allow the user to override the ciphersuite priority string from the command line, so that future issues related to ciphersuite incompatibility don't require recompilation to fix.

https://gitlab.com/openconnect/openconnect/-/merge_requests/71

Revision history for this message
J.P. (jptrosclair-6) wrote :

Just a thought, but in the case of using the NetworkManager plugin where I'm not certain you can easily modify the command line args (I've not looked into this at all)- I wonder if Ubuntu setting the priority similar to what Fedora is doing and providing a default gnutls configuration for OpenConnect that mirrored the default priority OpenConnect uses wouldn't be ideal. Seems like the most compatible solution to get the same behavior out the NetworkManager function or using it from the command line.

Or if there is a way for OpenConnect to support this directly without creating issues for other downstream consumers of the project:

https://www.gnutls.org/manual/html_node/Application_002dspecific-priority-strings.html

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.