Bug 1421241

I'm updating NetworkManager-openvpn, see if this build helps when it's done.

https://koji.fedoraproject.org/koji/taskinfo?taskID=17729210

Dan Williams (dcwb) should already have received a heads-up about these potential issues in late november/early december 2016 regarding this issue.  I understood they already had fixed this.

--tls-remote have been deprecated since v2.3.0 (released January 2013) and already at that point had the much improved replacement in-place since that time.  The syntax of --verify-x509-name is different, but more flexible and supports UTF-8 characters properly.  See the man page for more information.

For the record, I am running NetworkManager-openvpn-1.2.6-1.el7.x86_64 (Scientific Linux 7.3) ... and I see it uses --verify-x509-name instead of --tls-remote.

Recent versions of the plugin support --verify-x509-name.

Since openvpn removed an option, NetworkManager-openvpn can do nothing here automatically.


Maybe the GUI should now be updated to make it more obvious that tls-remote is defunct. But in the end, there is no solution and users are forced to modify their existing configurations.

upstream: https://bugzilla.gnome.org/show_bug.cgi?id=776045

*** Bug 1421499 has been marked as a duplicate of this bug. ***

*** Bug 1421592 has been marked as a duplicate of this bug. ***

The nm-openvpn plug-in could disable the --tls-remote variant in the UI and in existing configuration convert it to the new syntax.

IIRC ... the eqvivalent of

      --tls-remote host.example.com 

should be

      --verify-x509-name host.example.com name

The 'name' type should match against the CN field of the X.509 subject.

The only difference here compared against --tls-remote is that there are no character replacements, where some less used characters (typically outside a-z, A-Z and 0-9) are changed to _ (underscore).  I believe the majority of users uses normal hostnames in the server CN, so this could ease the migration.

Further the plug-in could issue a warning if --tls-remote is used and an underscore is found in the match value.

(In reply to David Sommerseth from comment #6)
> The nm-openvpn plug-in could disable the --tls-remote variant in the UI and
> in existing configuration convert it to the new syntax.

yes, the nm-connection-editor UI should be improved to strongly discourage the tls-remote option, possibly with a warning that it might make your connection non-working.

The upstream bug is still open to improve here, but these changes only make the issue more discoverable to the user. The user is still required to manually fix the connection.


> IIRC ... the eqvivalent of
> 
>       --tls-remote host.example.com 
> 
> should be
> 
>       --verify-x509-name host.example.com name
> 
> The 'name' type should match against the CN field of the X.509 subject.
> 
> The only difference here compared against --tls-remote is that there are no
> character replacements, where some less used characters (typically outside
> a-z, A-Z and 0-9) are changed to _ (underscore).  I believe the majority of
> users uses normal hostnames in the server CN, so this could ease the
> migration.

... so it's not really equivalent :)

Apparently it was desired by openvpn 2.4 to break configurations with --tls-remoted, otherwise it could just have kept the option. Which raises the question why the nm-openvpn should behave any different here.

But yes, probably this should be done. A user just doesn't care for the reasons his configuration breaks. (as always: patches welcome).


> Further the plug-in could issue a warning if --tls-remote is used and an
> underscore is found in the match value.

(In reply to Thomas Haller from comment #7)
> (In reply to David Sommerseth from comment #6)
[...snip...]
> > The only difference here compared against --tls-remote is that there are no
> > character replacements, where some less used characters (typically outside
> > a-z, A-Z and 0-9) are changed to _ (underscore).  I believe the majority of
> > users uses normal hostnames in the server CN, so this could ease the
> > migration.
> 
> ... so it's not really equivalent :)

Fair point :)

> Apparently it was desired by openvpn 2.4 to break configurations with
> --tls-remoted, otherwise it could just have kept the option. Which raises
> the question why the nm-openvpn should behave any different here.

To be fair, the --tls-remote feature was deprecated officially in OpenVPN v2.3.1, released March 27, 2013 (just re-checked commit logs - we removed it in v2.3.0 and introduced a compatibility wrapper in v2.3.1).  And it has been labelled with "DEPRECATED" in the man page since that release, even saying "It will be removed in either in OpenVPN v2.4 or v2.5".  Plus we also reminded people about this being removed all back to v2.4_beta1 (released Nov 17, 2016).  I also got in touch with Dan Williams around the same time, to ensure nm-openvpn would be able to tackle this situation.

But in retrospect, we could probably have made even more noise about this.  This is something we need to discuss in the OpenVPN developers community.

With that said, OpenVPN v2.4 carries 240+ configuration options.  So we do need to remove deprecated features from time to time; we already have way too many options.  But on the other hand, we do feel that giving a few years of adoption time is fairly generous.

> But yes, probably this should be done. A user just doesn't care for the
> reasons his configuration breaks. (as always: patches welcome).

:)  Yeah, users just want things to work.

(In reply to Thomas Haller from comment #7)
> But yes, probably this should be done. A user just doesn't care for the
> reasons his configuration breaks. (as always: patches welcome).

patches for review on upstream bug:

https://bugzilla.gnome.org/show_bug.cgi?id=776045#c3

I have only glared at the code, and I do not have too much experience inside the nm-openvpn plug-in source code and no build setup for NetworkManager stuff.  But this looks like a very reasonable approach.  When there is an EL7 build available, I can definitely test this for you (currently running Scientific Linux 7.3 x86_64, which is a RHEL 7.3 clone).

Just one comment to a sentence in your commit message:
"[...} or ever worse, that it wronlgy accepts a server that should be rejected."

I don't dare to say this is completely wrong, but I really struggle to imagine a way this could be abused.

A typical attack vector would be a MITM attack, where the client connects to a different server without being aware of it.  For this to work out, the server must provide to the client a server certificate signed by the same CA as the real OpenVPN server, otherwise OpenVPN will reject the server regardless.  So just here it will be a big challenge.  Secondly, the CN field of the certificate the MITM server provides need to consider a remapping which is not happening.  Such an attack scenario sounds more like to be of more academic interest than a realistic attack vector.  But I might overlook something.

On the other side, you are right that some servers which provides a value typically *not* being a normal host name in the CN field might get the connection rejected.  So if the CN value is "VPN Server (1)", the old remapping would end up with "VPN_Server__1_" (which would be the value used with --tls-remote).  But with a typical normal host name, this should not be an issue at all.

And to be honest, the --tls-remote feature worked poorly in use cases where the CN was not a typical host name.  Just mix in UTF-8 and other "national characters" and you're got a challenge.  These are some of the areas --verify-x509-name tries to fix.

(In reply to David Sommerseth from comment #11)

I think a false-positive of rejecting a server that would have been accepted by --tls-remote is acceptable. The user really should fix the configuration.

I would be more concerned about a scenario where tls-remove would have rejected the server, but the verify-x509-name workaround doesn't.
If you say, "I really struggle to imagine a way this could be abused", that is a good thing, although I am not 100% sure that such a case cannot happen (and neither you "dare to say"). That's why I'd leave that remark there.

As a workaround, I rpm -Uvh --oldpackage openvpn-2.3.12-1.fc26.x86_64.rpm NetworkManager-openvpn-1.2.6-1.fc26.x86_64.rpm NetworkManager-openvpn-gnome-1.2.6-1.fc26.x86_64.rpm
from:
https://koji.fedoraproject.org/koji/buildinfo?buildID=793933
https://koji.fedoraproject.org/koji/buildinfo?buildID=806543
and I'm now able to get back in my corporate vpn.

Workaround merged upstream: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=37d6dc4c521ebce71313e9ea757f90cd7eefc7d2

(In reply to Peter Gervase from comment #13)
> As a workaround, I rpm -Uvh --oldpackage openvpn-2.3.12-1.fc26.x86_64.rpm

If you installed the "broken" openvpn package and need to downgrade immediately, the easiest way to do that is "sudo dnf distro-sync --disablerepo=updates-testing" (you might specify just those packages you want to downgrade).

(In reply to Thomas Haller from comment #14)
> Workaround merged upstream:
> https://git.gnome.org/browse/network-manager-openvpn/commit/
> ?id=37d6dc4c521ebce71313e9ea757f90cd7eefc7d2

It has been twelve days since this fix went upstream. If there isn't an imminent upstream release, can we please get a downstream build with this patch ASAP? Those of us on Rawhide really need this working again...

(In reply to Stephen Gallagher from comment #16)
> (In reply to Thomas Haller from comment #14)
> > Workaround merged upstream:
> > https://git.gnome.org/browse/network-manager-openvpn/commit/
> > ?id=37d6dc4c521ebce71313e9ea757f90cd7eefc7d2
> 
> It has been twelve days since this fix went upstream. If there isn't an
> imminent upstream release, can we please get a downstream build with this
> patch ASAP? Those of us on Rawhide really need this working again...

btw, you can also fix your configuration not to use the deprecated option. That is what "openvpn" wants you to do.

But sure, I agree a rawhide build should be done.

NetworkManager-openvpn-1.2.8-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-3870a93455

NetworkManager-openvpn-1.2.8-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3870a93455

NetworkManager-openvpn-1.2.8-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.