[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Re: "--askpass file" is evil!


  • Subject: Re: [Openvpn-users] Re: "--askpass file" is evil!
  • From: Mathias Sundman <mathias@xxxxxxxxxx>
  • Date: Sat, 15 Jan 2005 00:59:53 +0100 (CET)

On Fri, 14 Jan 2005, Ray Lee wrote:

On Sat, 2005-01-15 at 00:03 +0100, Mathias Sundman wrote:
If they are headless, who is going to type the passphrase?

Well yes, that's the problem I'm trying to deal with.

Why not just use a non-encrypted private key?

Because the documentation says that once a private key is known, all previous communications can now be decrypted, versus TLS where it provides "perfect forward security." I'd like to negotiate a session based on a username and password which is auth'd on the server side via script (which in my specific situation checks the pair against a database.)

With a non-encrypted private key, I did not mean static pre-shared keys, I ment a private key/certificate keypair that is not encrypted. That is TLS mode with PFS.


If you are going to put the the passphrase in a file, how do you plan to
protect it better than the private key itself?

It's not about the ability to protect it better than the private key. It's the ability to minimize damage if a node is subverted.

It is useful to have the ability to centrally revoke the
username/password combo for a specific headless box, rather than having
all communications, past and future -- on every node on the VPN network
rather than one -- subverted.

If you setup a CA you can centrally revoke a certificate for a particual box. You do not have to issue new certs for each box.


I can understand that username/password auth can be useful if you want to authenticate against an already existing user database, but like I said, you still have the option of using non-encrypted private keys/certificates to solve the other problems you mention.

(It's likely I'm misunderstanding something about how this works in
practice. So, bear with me while I trot out my ignorance :-).)

If it isn't better secured,
you gain nothing from encrypting the key in first place.

Eh. You might be right, but see above. While the boxes are pretty secure (perfect security is a clay brick with no power cord), I'm not comfortable using a single Super Secret Key Of Doom for the entire VPN network.

Right, and you don't have to. See above.

If you really must use a passphrase protected key, then yes you will have
to recompile from source.

<shrug> It's not the recompile I object to; I'm perfectly capable of changing a rules file and rebuilding a .deb. (Though tracking the immediate upstream is always a bit tedious.)

It's just that I figured somebody else must have tried to do this
before. Between that, and not understanding why getting a password from
--auth-user-pass <fileanme> was disabled and secret keys weren't, I came
to the conclusion that I was, quite frankly, missing something obvious
when it comes to Best Practices for deployment.

You probably missed what I described above. Static pre-shared keys should almost never be used for multi-client setups, for the reasons you have given, you cannot then lock-out a single client.


So you shold use TLS mode, and then you have the option of either using a non-encrypted or an encrypted private key. The purpose of encrypting the key is if someone is able to steel it, he shouldn't be able to use it without knowing the passphrase required to decrypt it.

If you then save the passphrase in a file on the harddrive together with the key, you have gained nothing, as the passphrase file is a easy to steal then.

The reason why --auth-user-pass was disabled was because it was to simple for a normal roadwarrior user to circumvent the use of a passphrase protected private key, by simply saving the passphrase in a file and use the --auth-user-pass option.

Static keys is ment to be saved in a file on disk, not typed like a passphrase is ment to be.

(Why, by the way, is a shared key more secure than a username/password
combo coming from a file? Perhaps if that were answered, I'd have a
better idea of where I'm misunderstanding the process...)

Probably not, but a non-encypted private key is.

Now, if you still want to use username/password auth, I can see your problem. You might be able to make a script that runs openvpn and passes the username and password to stdin when openvpn asks for it.

--
_____________________________________________________________
Mathias Sundman                  (^)   ASCII Ribbon Campaign
OpenVPN GUI for Windows           X    NO HTML/RTF in e-mail
http://www.nilings.se/openvpn    / \   NO Word docs in e-mail


------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users