OpeonConnect fails with generic TLS Fatal Alert Error

Is this https://gitlab.com/openconnect/openconnect/issues/21 ?

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

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

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

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

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.

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

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

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

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