Openconnect fails to connect to VPN servers which blacklist TLS 1.0
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| openconnect (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
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:
"%COMPAT:
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:/
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://
100 /var/lib/
$ 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://
500 http://
100 /var/lib/
2.
500 http://
| Mike Miller (mtmiller) wrote | #1 |
| Dan Lenski (lenski) wrote | #2 |
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.