[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: Ray Lee <ray-openvpn@xxxxxxxxxxxxx>
  • Date: Fri, 14 Jan 2005 15:48:33 -0800

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.)

> 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.

(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.

> 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.

(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...)

Thanks for your answers.

Ray Lee



-------------------------------------------------------
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