-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> Hi, > > On Fri, Dec 12, 2014 at 19:24 +0100, Arne Schwabe wrote: >>> On Mon, Dec 08, 2014 at 14:52 +0300, Vasily Kulikov wrote: >>>> This patch adds support for using certificates stored in the Mac OSX >>>> Keychain to authenticate with the OpenVPN server. This works with >>>> certificates stored on the computer as well as certificates on hardware >>>> tokens that support Apple's tokend interface. The patch is very similar >>>> to, and also based on, the Windows Crypto API certificate functionality >>>> that currently exists in OpenVPN. > ... >>>> Signed-off-by: Vasily Kulikov <seg...@openwall.com> >>>> -- >>> Any comments? > > Some ideas about keychain implementation out of OpenVPN core. > > I see 4 possible alternatives here: > 1) implement keychain rsa offloading in Tunnelblick > 2) make my patch use plugin interface > 3) implement external daemon that communicated with openvpn process via > management interface > 4) the same as 3) but make openvpn able to handle more than 1 > management client > > There are problems with all these alternatives: > (1) is limited to Tunnelblick users and doesn't work for users who start > openvpn from the terminal or use any other GUI > (2) implies plugin interface is expanded to handle two new actions: 'user > certificate request' and 'rsa-sign request' > (3) implies management interface is expanded to handle 'user certificate > request'; also it doesn't work with Tunnelblick or any other tool that > communicates with openvpn via management interface as MI currently > supports only a single client > (4) needs 'user certificate request' addition and expanding management > interface to support more than a single client > > So, (1) is a no-go as it works only with Tunnelblick; (3) is a no-go as > it breaks Tunnelblick and probably someone else. We stay with only two > interface expantions: plugin interface or management interface. Either > (a) add 'user certificate request' to plugin interface or (b) add 'user > certificate request' to management interface and support more than a > single client. > > I'm not sure which way is better. Do you have any plans/objections on > these interfaces expantion? Maybe I missed some critical limitations of > the interfaces and they must not be used this way? If no strict > objections I'd prefer to implement it via plugin interface as my patch > would need to change only several hooks registration and handling > functions in this case. > > Thanks, > Hi, I've discussed this topic with James Bekkema, a Viscosity developer who was unfortunately unable to attend the previous IRC meeting. He suggested the following: "I also noticed some confusion as to how OpenVPN was able to access the local user’s Keychain in the IRC chat log: while I haven’t looked in detail at the patch, I suspect this is due to how Tunnelblick is launching OpenVPN with elevated permissions. Tunnelblick uses a SUID helper to have effective root permissions, and so OpenVPN in inheriting the user’s environment. For clients using a more secure (i.e. launchd) elevation approach (such as OpenVPN Connect, Viscosity, etc.) this approach won’t work (assuming it is indeed what is going on) which may make it a bit useless." "My recommendation would be to expand upon the support already in place for getting identity details over the management interface for Android devices. That way the actual accessing of the Keychain can be performed by a process running as the end user, without any signing issues etc. coming into play. It looks like this was pretty much the conclusion drawn from the meeting ." Best regards, - -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlSrpiIACgkQwp2X7RmNIqOioACgx+xqO+Z7cVJZtGClgWdK0nDh eCMAn2Emks41PQCbKsaA9pt5U19DGhSS =63NW -----END PGP SIGNATURE-----
