On Tue, Jul 24, 2018 at 6:21 PM, Daniel Lenski <dlenski at gmail.com> wrote: > On Fri, Jul 20, 2018 at 9:54 AM, Dave Hansen <dave at sr71.net> 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? > > This seems to be a common feature of newer Cisco servers. I tried > handshaking with a bunch of Cisco servers with "gnutls-cli --priority > LEGACY:-VERS-TLS-ALL:+VERS-TLS1.0", and all the newer ones fail. > >> Further, this code still seems to be around in openconnect, at least >> when compiled against old versions of gnutls: > > I looked at the history of this section of the code, and it's not > apparent to me why these version-specific priority strings were added > to openconnect. Perhaps Nikos or David can comment? Made they had to > do with some unexpected corner case in a particular GnuTLS version? > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/084e1d82f2fb5ad639810da2a64890ba4ede1896 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> regards, Nikos