Denis Vlasenko wrote:
On Saturday 03 July 2004 23:01, James Yonan wrote:management 127.0.0.1 20001 This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port. It's important, of course, that the management port always be local, since we are using it to potentially pass passwords and other sensitive data that should never actually touch a real network interface. Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc.Please don't do too much of that. I've seen this auth featuritis creeping in ntp and ups tools(!). Results ain't pretty... Reconfiguration of openvpn can always be done by editing config file and restarting openvpn daemon. Simple. Elegant. No additional coding - no risk of introducing bugs. This can be done via systray app, too.
I can understand your concerns, and mostly you are right. However, there is one quite important scenario - at least as I see it - where you need the core daemon and the GUI running in different accounts: whenever the key or secret has to be looked away from the user while it shall still be possible for her/him to start/stop VPN connections. One reason for this may be that the key is bound to the device and not the user. The other one is security. Through this separation, malicious programs running in the context of the user can not so easily access the secret.
And for those who don't trust this new interface (which will surely need a careful implementation): what about adding a configure switch and putting the respective code in some #ifdefs?
Jan
smime.p7s
Description: S/MIME Cryptographic Signature
