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

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


  • Subject: [Openvpn-users] Re: Re: "--askpass file" is evil!
  • From: Charles Duffy <cduffy@xxxxxxxxxxx>
  • Date: Fri, 14 Jan 2005 23:18:47 -0600

On Fri, 14 Jan 2005 15:48:33 -0800, Ray Lee wrote:

> On Sat, 2005-01-15 at 00:03 +0100, Mathias Sundman wrote:
>> 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."

That's static key mode that lacks PFS. An unencrypted TLS key still
provides perfect forward secrecy.

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

Why would you prefer a static username and password over a static TLS key?
I don't see the difference.

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

If the node is subverted, you centrally revoke the old TLS key and go on
with your life.

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

A compromised TLS key does not result in this kind of compromise.

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

We're not proposing a single Super Secret Key Of Doom. Rather, we're
proposing that every client have a distinct key pair signed by the same CA
(which is kept secure and *only* used to sign VPN clients' certificates),
and that the server check that the server likewise has a key that
corresponds with a certificate signed by that CA, without caring which
specific certificate that is (except for checking that it's not on a list
of revoked ones).

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

As above -- we're not proposing a shared key.



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