[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: "Erik Anderson" <erikba@xxxxxxxxxxxxxxxxx>
  • Date: Fri, 14 Jan 2005 22:58:01 -0800

This conversation has been going back and forth now for a little while and I'm not sure that adding my voice to the mix will help at all, but here goes.

You wrote the following statement: "Because the documentation says that once a private key is known, all previous communications can now be decrypted." This statement is wildly confusing and is probably where most of the problems are coming from. Please consider it to be wrong. Long clarification follows.

There are are two ways to communicate in OpenVPN: "shared secret" and "TLS"

"Shared secret" is where both sides of the conversation have the exact same password. Shared secret communications can only be between two computers that share this one file, and losing the file allows all previous communications to be decrypted. OpenVPN operating in this manner effectively has one hand tied behind its back.

"TLS" assigns a PUBLIC and a PRIVATE key to each individual machine, so that they can identify themselves and secure the communications pipe. OpenVPN uses the private key to negotiate a kind of "shared secret" for communication between the machines. This shared secret changes once an hour, and losing either the private key or the shared secret will only allow you to decrypt at most an hours worth of traffic. This is perfect forward security, and you have it whenever you use TLS.

The TLS private key can OPTIONALLY be encrypted by a password. This allows you to "secure" the person using the machine as well as the machine itself. The machine authenticates itself by having a valid TLS private key, the person authenticates him/herself by being able to unlock the key.

Placing the password to the TLS private key in a file on the hard drive is being argued here as useless; the machine now has both pieces of the puzzle and the person using the machine doesn't need to know anything. It's equivalent, much simpler, and arguably more secure not to specify a password when you create the TLS private key in the first place.

Using a TLS private key without a password does not mean that you are suddenly using a simple shared secret encryption, you still have all the wonderful stuff that TLS has to offer. You have simply taken the human out of the picture, the computer is now trusted to establish and authenticate the connection on its own. If someone steals the machine, revoke that machine's certificate and move on.

----- Original Message ----- From: "Ray Lee" <ray-openvpn@xxxxxxxxxxxxx>
To: "Mathias Sundman" <mathias@xxxxxxxxxx>
Cc: <openvpn-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, January 14, 2005 3:48 PM
Subject: Re: [Openvpn-users] Re: "--askpass file" is evil!



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




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