Re: [Openvpn-devel] request for input re: OpenVPN API

[Mike M. <Mik...@se...>]

Hi Charles,

You raise good points below. The web services client wouldn't be 
controlling the connection in the way that you envision. It would be 
more of a message passing service (explaining why a connection failed, 
rather than just showing up in the grid as some unexplained connection 
failure, as happens now) allowing the remote client to react to server 
messages. The remote client would also be able to examine state of 
various VPN servers in order to automatically choose which one to use, 
and set the correct parameters for its client. Because the Grid uses 
automatic service discovery and connection, it would have to be able to 
modify its connection parameters to be in sync with the needs of 
whichever server it is choosing to connect to. The VPN servers would 
already have to be running, and able to take connection requests from 
the client. They would not be relinquishing control. They would simply 
be working in tandem with web service management software at their 
location. This type of connection management communication would be 
taking place over the Grid's Web services, which should be secure using 
the GSI. If necessary, and this may indeed be the route to go if the 
former option proves not secure, the interface could reside at the 
client end, and, as you say, the VPN control channel could be used. But 
I think the former example would be more useful. For example, a 
requesting web service could toggle the hold function, and resume a 
sleeping connection when it is required.

Mike

Charles Duffy wrote:
> Mike Martin wrote:
>   
>> It would need to last indefinitely, and be managed by a remote client, 
>> using Web Services, with minimal human intervention
>>     
>
> A tool such as runit, with some wrappers, can provide the most immediate 
> layer of management -- at least with regard to ensuring that the VPN 
> stays up when it's expected to, triggering restarts when intended, etc.
>
>   
>> If parameters change over time, messages outlining changes must be 
>> passed to the remote client in specific Web Services format. e.g. I f a 
>> certificate expires, or is not found because if a change in directory 
>> structure,  the remote client must be made aware of the cause of the 
>> failure, so steps can be taken to correct it without having to dig down 
>> for the information. We may be talking about a large number of 
>> connections spread over a huge distributed computing environment, so 
>> human intervention may not be an option.
>>     
>
> The best solution to that isn't necessarily going to be very specific to 
> OpenVPN. My company has a tool we designed and built in-house (actually 
> very simple in terms of LOC count) which maintains configuration files 
> on servers on customer sites, based off of templates and a tree of data 
> representing the server's current and intended state. Writing a 
> web-services frontend to the engine as a whole would be child's play, 
> and further would provide far more power than trying to build a separate 
> API for each individual component being managed. (However, I would be 
> very hesitant to write such a frontend which accepted commands or 
> updates not passing through the VPN proper, as this would reduce my 
> security model's strength to the weaker of the VPN and the control 
> channel -- which given the depth of countermeasures protecting the VPN 
> [such as a tls-auth key, client and server keys, unprivileged users and 
> groups, and the use of a chroot jail] would quite certainly be the latter).
>
>   
>> There may be long periods without traffic. The hold command would likely 
>> be used here.
>>     
>
> Hmm. Let me try to get a bigger picture.
>
> You have a web service which is used to control a VPN connection. This 
> control presumably may include not only starting, stopping and otherwise 
> modifying the immediate state of the service but also making 
> configuration changes -- which presumably may include modifying keys, 
> remote addresses, etc.
>
> Because this control includes being able to remotely start the VPN from 
> a halted state, you need to have a control channel which is separate 
> from the VPN proper. Because this control channel may need to pass 
> sensitive data or commands when the VPN is down, it needs to have 
> security characteristics at least as strong as those of the VPN itself.
> Because it needs to be able to write to the areas of the drive where 
> OpenVPN's configuration data and keys are stored, the process also has 
> permissions which allow it to be substantially dangerous if subverted -- 
> more such permissions than OpenVPN itself, which is unable to change its 
> own configuration.
>
> I'm not entirely sold on the purpose of running both the control channel 
> and the VPN as externally accessible services. Certainly, the VPN 
> provides more functionality -- but if it's only being used for specific, 
> well-defined data streams (which seems to be the case if you can turn it 
> on only when you expect data to be passed), why not secure that content 
> via the same mechanism you use for the control channel? That way you 
> only expose a single route of attack -- rather than two -- and generally 
> suffer quite a bit less complexity. If the control channel is 
> established via a mechanism such as SSH rather than a web service, quite 
> a bit of flexibility is provided there as well (as SSH's ability to run 
> arbitrary tunnels, act as a SOCKS proxy, etc. can be leveraged).
>
>
>
> If my concerns reflect some misunderstanding of your proposal, 
> clarification would be appreciated.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
>