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

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


  • Subject: Re: [Openvpn-users] "--askpass file" is evil!
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Fri, 3 Dec 2004 13:59:51 -0700 (MST)

On Fri, 3 Dec 2004, Terry Dooher wrote:

> Storing a passphrase in a file, especially for roadwarriors is tantamount to 
> writing it on a sticky note. It defeats the whole point of their being a 
> knowledge aspect to the authentication. Locking a door with two keys instead 
> of one isn't much use if both keys are on the same ring.
> 
> Even given compile-time options, wouldn't it be possible for the client to 
> then download and install their own copy of OpenVPN with these options 
> enabled? Lazy/ignorant users can find ways around client restrictions like 
> this, especially as OpenVPN still needs to be run with admin privs.
> 
> You could trust that anyone clued-up enough to be able to reinstall their own 
> copy would understand the security issues involved, but trust isn't really a 
> luxury most of us have.
> 
> None of this is a complaint with OpenVPN, of course, the same issues apply to 
> anything that involves an identification system.

Incidentally, there's a clever method of making it more difficult for end 
users to download or build their own copy of OpenVPN instead of using the 
build you want them to use (which, for example, might have been built 
with password saving disabled).

In ssl.h, note the definition of KEY_EXPANSION_ID.

/* Used in the TLS PRF function */
#define KEY_EXPANSION_ID "OpenVPN"

If you change the "OpenVPN" string to something else, it will perturb the 
TLS PRF function used for --key-method 2 key generation (it won't have 
any effect on --key-method 1 though).

The net result is that a given build of OpenVPN can only connect to 
another build if the KEY_EXPANSION_ID strings are identical -- so it's 
sort of like a password in a sense.

One could change this string on both the client and server and it would
then prevent someone from replacing the client or server executable with a
default OpenVPN build.

Note of course that as security goes, this is not strong-crypto-grade
security.  It's more like weak-DRM-grade, which means that it will easily
fall to reverse engineering.  But I'd have to think that your average
non-geek road warrior is not going to go through so much trouble just to
be able to avoid typing in their passwords repeatedly.

One could take this concept further by hardcoding the KEY_EXPANSION_ID
derivation to a given machine to create an OpenVPN client configuration 
which would fail if copied to another machine.

This could be done by embedding a constant string in your OpenVPN build
which is XORed with the ethernet MAC address of the machines's primary NIC
to generate the KEY_EXPANSION_ID.  Now if someone tried to copy their
OpenVPN config files and keys to another machine, they would no longer be
able to connect because the other machine's ethernet MAC address would be
different, and so the wrong KEY_EXPANSION_ID would be generated.  This, of
course, is nothing more than weak DRM.

Now before anyone jumps in and says that this should be a standard feature
in OpenVPN, realize that all currently known DRM techniques depend on
security by obscurity.  If such a method were added to OpenVPN, i.e. to
hardcode a build of OpenVPN to only operate on a designated machine,
someone would surely post a "crack" to allow you to type in a fake MAC
address and fool OpenVPN into thinking it's a real MAC address.

The bottom line is that for DRMing the KEY_EXPANSION_ID to be even
marginally effective from a security perspective, each site would need to
do its own custom programming of the KEY_EXPANSION_ID derivation so that
it would be difficult for a single "crack" to defeat it.

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users