Openconnect fails to connect to VPN servers which blacklist TLS 1.0

[DaveHansen]

Summary:

Intel has stopped supporting TLS 1.0 on its VPN endpoints, which is apparently a new default configuration for some Cisco VPN servers. This configuration is incompatible with the Ubuntu 14.04.5 openconnect and my openconnect now fails to connect.

Details:

I'm running a fully-updated Ubuntu 14.04.5 which ships openconnect 5.02 package. It uses the following as a priority string for the TLS session:

 "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"
 "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION

This string forces the TLS version to 1.0 and will not use TLS 1.1/1.2 despite libgnutls26 support for 1.1/1.2. I confirmed the attempt to use TLS 1.0 in a packet capture. gnutls-cli,
using the same gnutls library was confirmed in a packet capture to be using TLS 1.2.

This leaves me unable to connect to the VPN servers. The failure message that comes back out of the console from openconnect is something along these lines:

> SSL connection failure: A TLS packet with unexpected length was received.

The packet capture shows a TCP RST packet coming back from the server to
trigger these messages.

I _can_ connect to these VPN servers if the "-VERS-TLS-ALL" is removed from the openconnect priority string and the binary is recompiled.

This code still seems to be around in the current upstream openconnect, although it may be dead code because of the deprecation of upstream openconnect support for old versions of gnutls.

https://github.com/openconnect/openconnect/blob/master/gnutls.c#L2202

So, there may not be an upstream fix for this issue other than removing the code since.

In an openconnect-devel@ discussions, Nikos Mavrogiannopoulos <email address hidden> provided some of the background for why this particular TLS priority string was placed in OpenConnect:

> I think this was at a time which a popular firewall (F5) was
> terminating TLS connections in an apparent random way. It was often
> seen that it would terminate some gnutls connections but not openssl.
> I'm only speculating here but my understanding was that David was
> trying to make gnutls' handshake look as close as possible to the
> openssl's from that time (when gnutls was added in openconnect,
> openssl didn't have tls1.2 or it was way too new), to avoid these
> failures. It was later found out that this firewall would terminate a
> TLS connection if the first message (hello) was between 256 and 512
> bytes. When gnutls added counter measures about that (with the %COMPAT
> keyword), openconnect was also updated. That should have been with the
> changelog entry:
> <li>Enable elliptic curves with GnuTLS 3.2.9+, where there is a
> workaround for certain firewalls that fail with client hellos between
> 256 and 512 bytes.</li>

$ lsb_release -rd
Description: Ubuntu 14.04.5 LTS
Release: 14.04
$ apt-cache policy openconnect
openconnect:
  Installed: 5.02-1
  Candidate: 5.02-1
  Version table:
 *** 5.02-1 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status
$ apt-cache policy libgnutls26
libgnutls26:
  Installed: 2.12.23-12ubuntu2.8
  Candidate: 2.12.23-12ubuntu2.8
  Version table:
 *** 2.12.23-12ubuntu2.8 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.12.23-12ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

[Mike Miller (mtmiller)]

The upstream fix for this has included moving on to depending strictly on later versions of GnuTLS.

I just want to point out that this version of OpenConnect was deliberately built against GnuTLS 2.12, even though GnuTLS 3.2.11 was available in both the Debian and Ubuntu archives at the time. I believe that should not be changed. If this can be fixed by patching openconnect, but continuing to link with libgnutls26 2.12.23, then great.

The reason for avoiding libgnutls28 in 14.04 is because libgmp10 5.1.3 was licensed under GPLv2 only. Only at version 6 was GMP dual licensed under LGPL, which allows the combination of libopenconnect, libgnutls28, and libgmp10 to be distributed wholly under LGPL. GMP 6 happened to come out around spring 2014, too late to be included in Ubuntu 14.04.

[Dan Lenski (lenski)]

Copying from what I wrote on the openconnect-devel mailing list…

Nikos's proposed fix is to change "-VERS-TLS-ALL:+VERS-TLS1.0" to
"-VERS-SSL3.0".

It's useful to consider the total set of possible effects of this change on Ubuntu 14.04's openconnect:

1) Good: Fixes the incompatibility reported here, allowing it to
connect to gateways that require TLS1.1 or TLS1.2.
2) Neutral: No effect on ancient gateways that only support SSLv3
(insecure, already locked out).
3) Neutral: No effect on ancient gateways that only support TLS1.0
(still possible to connect).
4) Bad: May prevent connections to TLS-version-intolerant (aka
"broken") servers and middleboxes which support TLS1.0 but fail to
correctly negotiate down to it when presented with TLS1.1/1.2
ClientHellos.

The upside (1) is pretty obvious and clear, because lots of newer
gateways simply refuse TLS1.0 these days.

The downside (4) is harder to estimate… I don't think there are too many
TLS1.0-only version-intolerant middleboxes out there these days
because they would be breaking pretty much all the modern clients with
the misfortune to go through them. And I don't think I've ever seen a
report on the mailing list of a TLS1.0-only version-intolerant Cisco
ASA.

Basically, this change would vastly improve compatibility with newer gateways that refuse TLS1.0… and it would *only* reduce compatibility with really obsolete middleboxes that are intolerant to TLS1.1 and newer. I doubt that many such middleboxes still exist on the public Internet, because they would be breaking most modern clients.

So I'm in favor.