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

[Dan Williams <dcbw redhat com>]

On Wed, 2010-01-20 at 21:26 -0300, Federico Heinz wrote:
> 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.

Honestly I don't care.  I'm fine with some code in the NM-openvpn UI to
check the certificate file and determine if a private key password is
required or not.  I believe DER-format keys are always unencrypted
(because they simply don't have the ability to specify the information
necessary for decryption) but we can easily figure out of PEM format
keys are encrypted or not by looking for the DEK-Info and Proc-Type tags
in the OpenSSL header.  We need remember to scan more than 10K or so of
the file in case the private key is at the bottom of a bunch of
certificates.

Dan