Hi Dave, On Fri, Jul 20, 2018 at 09:54:35AM -0700, Dave Hansen wrote: > TL;DR: openconnect on Ubuntu 14.04 fails to connect to Intel VPN servers > that blacklist TLS 1.0. Where should this get fixed? On the Ubuntu side, we would tend to defer to openconnect upstream regarding what the correct way is to fix this to minimize risk of regression. But provided we have that guidance, this is potentially appropriate to have fixed in Ubuntu 14.04 via the stable release update process: https://wiki.ubuntu.com/StableReleaseUpdates Generally speaking, packages which need to be updated in order to remain compatible with changes to protocols on the Internet at large (such as in this case, changes to the baseline TLS version that clients must negotiate in order to be considered secure) qualify for SRU. If this is going to enable compatibility with some server endpoints that have moved on for security reasons (such as the Intel VPN servers), but break compatibility with other still-extant server endpoints that don't support current security protocols (such as the F5 firewalls, if they're still out there and have this bug), we would want to think deeply about making such a choice given that affected users also have the option to upgrade to newer versions of Ubuntu without impacting users who rely on the less-secure-but-stable support for pre-TLS1.1 endpoints. At this point I would suggest opening a bug report against the package so this question can be weighed there. https://bugs.launchpad.net/ubuntu/+source/openconnect/+filebug > --- > I'm running a rather vintage Ubuntu 14.04 which ships a rather > unmodified 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 _appears_ to be forcing things down to TLS 1.0 and not using TLS > 1.1/1.2 despite libgnutls26 supporting the later TLS protocols. 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. > > Intel has stopped supporting TLS 1.0 on its VPN endpoints, leaving me > unable to connect. 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. > > So, yes, this is a vintage distribution, but it's _supposed_ to be > supported, and it _can_ connect to these VPN servers if the > "-VERS-TLS-ALL" is removed from the openconnect priority string. > > Further, this code still seems to be around in openconnect, at least > when compiled against old versions of gnutls: > > https://github.com/openconnect/openconnect/blob/master/gnutls.c#L2202 > > Is this something Ubuntu can fix in their openconnect? Or is it > something we should also be fixing in the upstream openconnect? > > -- > Ubuntu-motu mailing list > Ubuntu-motu at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek at ubuntu.com vorlon at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20180725/ec407cfe/attachment.sig>
