Re: PATCH: passwordless TLS openvpn fails to connect with "no VPN secrets"

[Federico Heinz <fheinz vialibre org ar>]

On 20/01/2010, Dan Williams wrote:
> On Mon, 2009-12-21 at 02:10 -0300, Federico Heinz wrote:
> > The openVPN plugin for NetworkManager fails to connect to a passwordless TLS
> > server, complaining of "no VPN secrets". This happened because the code
> > assumes that only static-key servers use no secrets, which isn't true. Only
> > password and password+TLS require secrets.
> > https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/453807
> We'd need a bit more than that unfortunately.  First, openvpn assumes
> that the TLS private key will have a password protecting it, in which
> case the patch isn't required.

Indeed, this is true: if the key is password-protected, the connection
succeeds.

> Second, if we do want to allow unencrypted private keys (a security hole)

The security hole is relative, and it depends on the details of how the key is
stored. A password does not provide much security beyond that of storing the
file in an ecryptfs-encrypted directory, for instance.

In any case, if you do decide that you don't want to enable non-encrypted keys,
then at least the program should fail with a more informative message. The
current "No secrets" message is hard to decypher for a normal user, something
along the lines of "Private key needs to be password-protected" would be much
more helpful. Better yet, the UI should not let the enter a plain text key in
the dialog, instead of allowing such a "misconfiguration" and then refusing to
use it.

> then we'd need code to verify that the private key the user has picked is
> indeed unencrypted before letting the UI enable the OK button.  Any chance
> you'd be willing to work on that patch?  Most of the code to do that is lying
> around since nm-applet needs to do the same thing for 802.1x TLS.

I might, but first I'd hate to do the work to have it later rejected because
the guardians of the project decided to do it differently (not accepting
plaintext keys at all, for instance). If there is a clear decision about what
the desired behaviour is, I'll look into it.

	Fede