Hi All, Just to expand on the comments Samuli included below:
From a GUI client like Viscosity’s perspective number 1) from Vasily's email is the option we’d take, and ultimately something we were planning on implementing and contributing a patch for down the line anyway (i.e. something similar to the existing --management-external-key option). While this means clients like Viscosity and Tunnelblick will need to implement the interaction with the Keychain directly, this isn’t any different to the existing password Keychain approach both clients have when using --management-query-passwords anyway). I can also see such offloading being utilised on other platforms, and for integration with other security tools as well. However I can understand that there may be some cases where it’s desirable to have headless Keychain support, for example, a sys admin may like to have a headless OpenVPN connection kick in at boot time. Will these users mind if they have to use the file system instead of the Keychain? I believe Tunnelblick supports a headless mode, and Viscosity probably will down the line too: is this sufficient for users wanting Keychain storage, or is direct support a reasonable expectation? I’m afraid I’m not in a position to be able to answer these questions: probably the best users to ask are those using the MacPorts build, along with those deciding on the desired scope of the community OpenVPN project. Ultimately it looks like a lot of effort has gone into the Keychain patch, and if someone is willing to maintain the Keychain integration going forward (Apple does like to deprecate things) I don’t have any objection to it being included in some way (after a code review). While with a GUI like Viscosity may not make direct use of it, it may still be handy to others. Cheers, James -- James Bekkema SparkLabs Developer http://www.sparklabs.com http://www.twitter.com/sparklabs supp...@sparklabs.com > On 6 Jan 2015, at 8:08 pm, Samuli Seppänen <sam...@openvpn.net> wrote: > > > -----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----- > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
