Re: [Openvpn-users] Push an entire config (was: Connection resetting on very large file transfers)

[Mathias Sundman <mathias@xxxxxxxxxx>]

On Thu, 2 Sep 2004, James Yonan wrote:

> > Would it be possible to push an entire config, and
> > have the client just reconnect to use the settings?
>
> This is an interesting idea.  The problem is one of security.  You are 
> allowing the server to generate a complete config file and send it to 
> the client.  This goes far beyond the more restrictive semantics of 
> --push/--pull and creates a scenario where a compromised server would 
> have no problem "owning" a connecting client's machine.  Since OpenVPN 
> config files can execute shell commands, there's an obvious danger in 
> allowing them to be imported.
>
> Of course the other side of the equation is that allowing the server to 
> update the client side config file is a powerful usability feature, and 
> one that might make sense in some environments.  I can still see other 
> problems though:

Guess it's hard to maintain the same security if this is implemented, but 
if we make this step optional I think it's worth the security reduction in 
advance of the gained flexibility.

If the OpenVPN server is compromized you probably have other big problems 
anyway!

I think that if the client has a working config, he should be able to 
connect just like today without being forced to update his config. He 
could be notified that there is a new config to download, but should be 
able to choose whether he wants it or not.


> (1) What if you push a bad config file update to the client, and now it
> can't reconnect?
>
> (2) What if you push a config file update to the client which changes a
> connection parameter such as the cipher type.  Now you have to orchestrate
> the switchover so that the client will try to reconnect with another
> server which also uses the same cipher type.  Essentially it is a
> switchover/bootstrap problem akin to changing the configuration on-the-fly
> of a live, distributed system.

Despite the extra work to develop wouldn't the best thing be to implement 
a "pre-connecting" step, where the client connects to the server with a
hard-coded chiper and using only very small packets so MTU is not an 
issue.

It can authticate it self to the server with the same cert as used with 
the "main channel", and then query the server for the config file.

When this is done it can establish the real connection with the config.

If a bad config is pushed to the client (1), he will now still be able to 
reconnect to get a new config when the administrator has fixed the 
problem.

(2) is not an issue with this setup either.


I think this could even be created as a stand alone application that is 
run before starting openvpn if we don't want to add this complexity to 
openvpn itself.

--
_________________________________________________________
Mathias Sundman              (^)   ASCII Ribbon Campaign
NILINGS AB                    X    NO HTML/RTF in e-mail
Tel: +46-(0)8-666 32 28      / \   NO Word docs in e-mail