Re: Openconnect and old gnutls on Ubuntu 14.04
On 07/25/2018 10:02 AM, Steve Langasek wrote: > 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 Thanks for the help, everybody! Here's the Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1783610 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On Wed, Jul 25, 2018, 1:03 PM Steve Langasek wrote: > > 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. It's useful to consider the total set of possible consequences of Nikos's proposed fix, to change "-VERS-TLS-ALL:+VERS-TLS1.0" to "-VERS-SSL3.0". This would have the following effects 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 hard 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. Dan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
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@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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On 07/24/2018 01:01 PM, Nikos Mavrogiannopoulos wrote:
>> Am I misreading the code?
>>
>> If compiled with !DEFAULT_PRIO and we miss both the gtls_ver(3,2,9) and
>> gtls_ver(3,0,0) checks, won't we do
>> "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"... from the else{} block below?
>>
>> I read that as "when using old gnutls versions and !DEFAULT_PRIO", use
>> this string.
>>
>>> #ifdef DEFAULT_PRIO
>>> default_prio = DEFAULT_PRIO ":%COMPAT";
>>> #else
>>> if (gtls_ver(3,2,9)) {
>>> default_prio = "NORMAL:-VERS-SSL3.0:%COMPAT";
>>> } else if (gtls_ver(3,0,0)) {
>>> default_prio = "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:" \
>>>
>>> "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION" \
>>> ":-CURVE-ALL:-ECDHE-RSA:-ECDHE-ECDSA";
>>> } else {
>>> default_prio = "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"
>>> \
>>>
>>> "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION";
>>> }
>>> #endif
> Hmm, that is true, but ubuntu doesn't use that code.
My version is this, verbatim:
> err = gnutls_priority_set_direct(vpninfo->https_sess,
> "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"
> #if GNUTLS_VERSION_MAJOR >= 3
> "-CURVE-ALL:"
> #endif
>
> "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION",
> NULL);
Which is a bit more arcane way to do _some_ of the same stuff, like
adding "-CURVE-ALL:" for gnults >= 3.
> If it did it could have made sense to update it, but looks like dead
> code as since 5f0eb81daa0df5668eedd8e48eaeea065c92d9ad openconnect
> can no longer build with a version of gnutls < 3 (which doesn't have
> DTLS).
Right, Ubuntu (14.04) doesn't have the first two cases, only the third.
But, I was basically asking (despite being an ancient version of
openconnect) whether this affects upstream openconnect.
The "gtls_ver(3,0,0)" in upstream openconnect still has this hunk in its
string, though: "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:". Does that cause
any issues on gnutls versions >=3.0.0, but <3.2.9?
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On Tue, Jul 24, 2018 at 9:50 PM, Dave Hansen wrote:
> On 07/24/2018 12:22 PM, Nikos Mavrogiannopoulos wrote:
>>> 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?
>> This has been fixed in upstream openconnect since 2014, and we cannot
>> fix items in the past (unless David has skills which we don't know
>> about). That's up to your distribution to fix and a potential fix
>> could be to change "-VERS-TLS-ALL:+VERS-TLS1.0" to "-VERS-SSL3.0"
>> (i.e., allow everything except SSL3.0).
>
> Am I misreading the code?
>
> If compiled with !DEFAULT_PRIO and we miss both the gtls_ver(3,2,9) and
> gtls_ver(3,0,0) checks, won't we do
> "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"... from the else{} block below?
>
> I read that as "when using old gnutls versions and !DEFAULT_PRIO", use
> this string.
>
>> #ifdef DEFAULT_PRIO
>> default_prio = DEFAULT_PRIO ":%COMPAT";
>> #else
>> if (gtls_ver(3,2,9)) {
>> default_prio = "NORMAL:-VERS-SSL3.0:%COMPAT";
>> } else if (gtls_ver(3,0,0)) {
>> default_prio = "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:" \
>>
>> "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION" \
>> ":-CURVE-ALL:-ECDHE-RSA:-ECDHE-ECDSA";
>> } else {
>> default_prio = "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"
>> \
>>
>> "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION";
>> }
>> #endif
Hmm, that is true, but ubuntu doesn't use that code. If it did it
could have made sense to update it, but looks like dead code as since
5f0eb81daa0df5668eedd8e48eaeea065c92d9ad openconnect can no longer
build with a version of gnutls < 3 (which doesn't have DTLS).
regards,
Nikos
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On Fri, Jul 20, 2018 at 9:54 AM, 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? 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 Dan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On Tue, Jul 24, 2018 at 6:21 PM, Daniel Lenski wrote: > On Fri, Jul 20, 2018 at 9:54 AM, 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? > > 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: 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. regards, Nikos -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On 07/24/2018 12:22 PM, Nikos Mavrogiannopoulos wrote:
>> 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?
> This has been fixed in upstream openconnect since 2014, and we cannot
> fix items in the past (unless David has skills which we don't know
> about). That's up to your distribution to fix and a potential fix
> could be to change "-VERS-TLS-ALL:+VERS-TLS1.0" to "-VERS-SSL3.0"
> (i.e., allow everything except SSL3.0).
Am I misreading the code?
If compiled with !DEFAULT_PRIO and we miss both the gtls_ver(3,2,9) and
gtls_ver(3,0,0) checks, won't we do
"NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"... from the else{} block below?
I read that as "when using old gnutls versions and !DEFAULT_PRIO", use
this string.
> #ifdef DEFAULT_PRIO
> default_prio = DEFAULT_PRIO ":%COMPAT";
> #else
> if (gtls_ver(3,2,9)) {
> default_prio = "NORMAL:-VERS-SSL3.0:%COMPAT";
> } else if (gtls_ver(3,0,0)) {
> default_prio = "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:" \
>
> "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION" \
> ":-CURVE-ALL:-ECDHE-RSA:-ECDHE-ECDSA";
> } else {
> default_prio = "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:"
> \
>
> "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION";
> }
> #endif
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On Tue, Jul 24, 2018 at 14:50:03 -0700, Dave Hansen wrote: > Right, Ubuntu (14.04) doesn't have the first two cases, only the third. > But, I was basically asking (despite being an ancient version of > openconnect) whether this affects upstream openconnect. > > The "gtls_ver(3,0,0)" in upstream openconnect still has this hunk in its > string, though: "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:". Does that cause > any issues on gnutls versions >=3.0.0, but <3.2.9? The current configure script requires gnutls >= 3.2.10, so this branch is now also dead code. https://gitlab.com/openconnect/openconnect/commit/39eb59e3dc5a -- mike signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
On Fri, Jul 20, 2018 at 6:54 PM, 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? > > --- > > 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? This has been fixed in upstream openconnect since 2014, and we cannot fix items in the past (unless David has skills which we don't know about). That's up to your distribution to fix and a potential fix could be to change "-VERS-TLS-ALL:+VERS-TLS1.0" to "-VERS-SSL3.0" (i.e., allow everything except SSL3.0). regards, Nikos -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Openconnect and old gnutls on Ubuntu 14.04
TL;DR: openconnect on Ubuntu 14.04 fails to connect to Intel VPN servers that blacklist TLS 1.0. Where should this get fixed? --- 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
