-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Here's the summary of the previous IRC meeting. - --- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Monday 29th Dec 2014 Time: 20:00 CET (19:00 UTC) Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2014-12-29> Next meeting has not been scheduled but will be on the same weekday and time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY cron2, jamesyonan, mattock. plaisthos, segoon and syzzer participated in this meeting. - --- Discussed the "Add Mac OS X keychain support" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/9320> Agreed that it's best to keep this functionality outside OpenVPN core. In practice this means integrating the functionality with the de facto OpenVPN GUI for MacOS X, Tunnelblick. Segoon, the patch author, will take a stab it this new approach. .-- Briefly discussed the "Make OpenVPN set routes on Windows Vista and later" patchset: <http://thread.gmane.org/gmane.network.openvpn.devel/9237> This topic could not be covered in depth as d12fk was not present. It was decided to revisit this topic later when d12fk is present and when the changes have been reviewed in more depth (in two weeks or so). Mattock will provide experimental Windows installers with this patchset after the code has passed initial review. - --- Discussed the "Openvpn with cryptodev on FreeBSD does not work" patch: <https://community.openvpn.net/openvpn/ticket/480> The patch can't be included as-is, because it will break existing OpenVPN configurations. Syzzer will try to find a cleaner solution to the problem. - --- Full chatlog is attached. - -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlShvjQACgkQwp2X7RmNIqOpNACfR70gFBY3FkZbB2Lp9RVj6ZFi CDYAnj/sgP09PvoUJdf8GIO7bS4YiIQa =NJ7D -----END PGP SIGNATURE-----
(20.50.39) segoon: hi, I'm Vasily Kulikov, the author of OS X keychain patch (20.51.30) syzzer: segoon: hi! (20.53.14) mattock: hi segoon! (20.53.51) mattock: is d12fk here today? (20.54.24) mattock: I don't know if James will be present, but he has not responded to my emails (20.54.29) mattock: he might be on vacation (21.00.58) mattock: ok, meeting time (21.01.01) mattock: who is here? (21.01.13) ***syzzer reporting in (21.02.04) syzzer: haven't seen dazo for a while, he's not even in the channel? (21.02.05) cron2: yo (21.02.08) mattock: hi cron2! (21.02.17) mattock: d12fk? (21.03.38) cron2: haven't seen him in a while (21.03.53) syzzer: plaisthos: we need you for osx stuff! (21.05.37) mattock: no word from James, so I suppose he's not coming (21.05.43) mattock: I'll shoot him an email just in case (21.08.05) mattock: sent (21.09.28) mattock: I think the current attendees are what we'll get today (21.09.33) mattock: shall we start? (21.09.41) jamesyonan [~jamesy...@c-67-166-32-18.hsd1.co.comcast.net] è entrato nella stanza. (21.09.41) modalità (+o jamesyonan) da ChanServ (21.09.59) cron2: hi james :) (21.10.08) jamesyonan: hi cron2 (21.10.11) syzzer: I'll poke plaisthos on whatsapp, but I think we can start in the mean while (21.10.29) mattock: hi james! (21.10.35) mattock: let's begin (21.10.42) mattock: ok, so today's agenda: https://community.openvpn.net/openvpn/wiki/Topics-2014-12-29 (21.10.43) vpnHelper: Title: Topics-2014-12-29 – OpenVPN Community (at community.openvpn.net) (21.11.12) plaisthos: syzzer: YEAH i HAVE TIME (21.11.18) mattock: first topic is segoon's patch: http://thread.gmane.org/gmane.network.openvpn.devel/9320/focus=9346 ("Add Mac OS X keychain support") (21.11.20) vpnHelper: Title: Gmane Loom (at thread.gmane.org) (21.11.23) mattock: plaisthos: :) (21.11.23) plaisthos: sorry for caps (21.11.41) mattock: plaisthos: I thought you got annoyed about being pulled to the meeting :P (21.11.48) syzzer: oh, nvm :p (21.12.17) mattock: jamesyonan: doesn't OpenVPN Connect have OS X keychain support? (21.12.58) jamesyonan: yes it does, but it's implemented by the Connect management interface client (21.13.12) mattock: any thoughts on segoon's approach in general? (21.13.27) jamesyonan: overall the patch seems okay (21.14.04) plaisthos: I unfortenately had not really time to look into it yet in detail (21.14.25) mattock: the patch is pretty big, but only seems to add stuff, not touch existing things (21.14.31) mattock: mostly (21.14.52) syzzer: in general I'd say this should preferably be implemented outside of the openvpn core, but since we already have windows in there too we might move those out later on if we really want that (21.15.27) segoon: the number of changes to the old code is limited to "if (keychain arg is set) { ... }" (21.15.45) cron2: there are a few bits in there that look unrelated, like the patch to compat.h (21.16.58) jamesyonan: I think the more modern thinking about keychain support is to have the keychain ops be implemented outside the core in the app-level process (like a UI) that is controlling the OpenVPN daemon (21.17.47) jamesyonan: because then the user can use their own user-level keychain, rather than having to use the keychain that is accessible to the OpenVPN daemon which is probably running in root/admin context (21.19.32) segoon: jamesyonan: OpenVPN under Tunnelblick is started under root, but it has an access to the user's keychain (21.20.05) segoon: fwiw, I ported the patch to the current OpenVPN version by the Yandex company request, they use the patched OpenVPN under Tunnelblick (21.21.06) jamesyonan: does Tunnelblick run OpenVPN as root? (21.21.10) plaisthos: yes (21.21.24) syzzer: (I never used tunnelblick, so maybe I'm asking the obvious here) tunnelblick itself has no support for the key chain? (21.21.34) plaisthos: no unfortenately not (21.21.59) jamesyonan: but how does OpenVPN, running as root, know which user's keychain to use? (21.22.00) mattock: I believe tunnelblick is the de facto OpenVPN GUI for OS X... there's the Viscosity thing, but that one is proprietary (21.22.51) plaisthos: yeah. Tunnelblick calls the openvpn binary as root and does the management+other paramter stuff (21.22.51) jamesyonan: or does it require that certs/keys be in the system keychain? (21.23.00) plaisthos: like the windows version (21.23.11) segoon: syzzer: the thing is that private key can be configured non-exportable, so openvpn calls Keychain API each time to decrypt the data, it would be problematic if implemented in Tunnelblick (21.23.33) plaisthos: segoon: not that would worke fine (21.23.35) jamesyonan: no, that's not how it works (21.23.46) syzzer: segoon: I don't think so, the management interface has the 'rsa_sign' command to request a new sigature (21.23.55) jamesyonan: RSA offload only requires one call per TLS negotiation (21.24.34) jamesyonan: so having the RSA sign operation run in a different process has negligible impact on performance (21.24.42) plaisthos: the situation is similar to android where an application also does not get access to the private key (21.24.58) segoon: ok, probably it is not that hard to do, nevermind (21.25.51) syzzer: segoon: did you have contact with the tunnelblick guys? they might be very interested in your code too (21.26.47) cron2: I'm not sure I understand what the patch does - does it offload RSA signing, or does it just request the key+cert from the store, and do everything locally? (21.27.04) segoon: syzzer: I was emailed by "Jonathan K. Bullard" <jkbull...@gmail.com>, he asked what specific code parts are related to TB, I've answered him and that's all, I haven't heard him since that time (21.28.12) segoon: cron2: please look at signData() -- it doesn't request the key, it uses SecKeyRawSign() (21.28.50) mattock: segoon: jkbullard is the correct guy to contact... he's usually pretty responsive (21.28.56) jamesyonan: right, so it's offloading the signing (21.29.40) cron2: well, tls_ctx_load_keychain() claims "/* Load Certificate and Private Key */" (21.30.16) segoon: jamesyonan: as to the keychain selection: on my testing machine the specific cert+key are in login keychain, not in system one (21.30.48) jamesyonan: doesn't the management interface support RSA signing offload so that tunnelblick could do the signing in the context of the end user, so that the user's keychain would be used? (21.31.28) segoon: jamesyonan: I cannot answer this question, I haven't looked at the Tunnelblick code (21.31.48) jamesyonan: segoon: but how does OpenVPN daemon running as root know which user's login keychain to use? (21.32.50) segoon: cron2: the "private key" part is about requesting the identity handle, it doesn't explicitly copies priv_key contents (21.33.00) segoon: probably the comment is misleading (21.33.21) cron2: yep, some more explanatory comments for people unfamiliar with the keychain stuff would be welcome (21.33.28) plaisthos: with the management interface approach you would have to read user certificate+ca certifcate and put that into the config file (21.35.33) segoon: plaisthos: and what about the private key (which might be not extractable)? (21.35.51) plaisthos: segoon: you get the callback via management interface (21.36.55) plaisthos: https://github.com/OpenVPN/openvpn/blob/master/doc/management-notes.txt (21.36.56) vpnHelper: Title: openvpn/management-notes.txt at master · OpenVPN/openvpn · GitHub (at github.com) (21.36.59) plaisthos: under rsa-sig (21.37.17) plaisthos: basically you replace --key with --management-external-key (21.37.37) plaisthos: and get BASE64 data you have to sign (21.40.23) segoon: so that's about moving all keychain stuff out of the main OpenVPN process to a helper process that only signs the data (21.40.31) segoon: this process can be run even under another user (21.40.36) plaisthos: yeah (21.40.55) segoon: and it can be started/stopped via config hooks (21.40.57) plaisthos: the process which opens the management connection (21.42.42) segoon: I'm trying to find cons of this solution compared to the current implementation.. (21.43.25) syzzer: well, the con is that it would mean there's more work to do... (21.43.45) segoon: the code will be a bit bigger due to management send/receive code, but all code is executed outside of the main openvpn process (21.44.32) plaisthos: OpenVPN for Android has this implemented (21.44.39) segoon: is it possible to include such helper into the official openvpn distro, if implemented? (21.45.01) cron2: well, the "helper" would have to go into the Gui that talks to the management interface anyway (single-user API) (21.45.15) cron2: like Tunnelblick (21.45.24) syzzer: segoon: actually, I think it would be very nice to have a simple helper that does just that in contrib/ (21.45.28) plaisthos: if you want to look an existing implementation (21.46.38) segoon: the main goal of Yandex here is to push the keychain stuff to upstream to stop supporting it themselves (IOW, myself) (21.46.46) plaisthos: it is also not unrealistic to have somehting like a plugin or external command that can do the same as the management-key (21.46.49) syzzer: if we have a reference implementation testing becomes easier and it can be used by people who want osx keychain support, but do not need/want a gui (21.46.57) segoon: if it is accepted by Tunnelblick instead of OpenVPN it is OK too, I think (21.48.02) syzzer: and from that perspective, you probably achieve better support if it gets integrated into tunnelblick, since those guys have shorter lines to the osx users (21.48.10) cron2: from my perspective as, well, call it "core maintainer", having all OS specific bits in an OS-specific application makes the bits *I* get to maintain easier to manage (21.48.32) syzzer: segoon: yes, just integrated into tunnelblick would be fine too (21.48.50) cron2: (and what syzzer said - if something in OSX changes, the Tunnelblick guys would be the ones to hear about it first) (21.50.09) segoon: from the technical POV I like the idea of the helper out of the main openvpn process, from the social POV tunnelblick upstream'ing looks good too (21.50.35) cron2: a helper / plugin would also be interesting. No idea if the plugin interface can do it today (21.50.35) segoon: however, I'm not sure whether keychain is supposed to work from the terminal without GUI like Tunnelblick (21.50.50) segoon: *is supposed by Yandex (21.51.45) segoon: cron2: what do you mean by "plugin" interface? Is it a yet another interface? (21.51.51) plaisthos: segoon: yeah :) (21.52.07) plaisthos: plugins can be called at/for certain events (21.52.22) segoon: looking into https://github.com/OpenVPN/openvpn/blob/master/doc/README.plugins... (21.52.24) plaisthos: they are basically library with some functions that are called (21.52.24) cron2: segoon: welcome to the wonderful world of OpenVPN extensibility :-) (21.52.38) segoon: :-) (21.53.19) plaisthos: we would "simply" add a --key-plugin option (21.53.34) cron2: (but as far as I can see in README.plugins, we don't support the RSA stuff) (21.53.45) plaisthos: and add a tls_rsa_sign function in the plugin interface (21.53.55) cron2: that :) (21.54.54) syzzer: *but* plugins run as the same user as the openvpn daemon, which is less favourable in this case I think (21.54.58) segoon: are plugins run in the main openvpn process? (21.55.10) syzzer: segoon: yes (21.55.35) segoon: so it is worse than via management interface (21.55.52) syzzer: yes, I think management interface is better in this case (21.56.23) plaisthos: yeah we don't win much %) (21.56.54) mattock: are slowly moving towards a consensus on what needs to be done? :) (21.57.10) segoon: Qs about management interface: (21.57.42) segoon: 1) the only secure local communication channel among the supported is unix socket, isn't it? (21.58.30) syzzer: plaisthos might know better, but I think so yes (21.58.55) plaisthos: well yes (21.59.11) plaisthos: you can also bind to 127.0.0.1 and do tcp (21.59.28) plaisthos: and can do user+pass authentication to the mgm interface (21.59.41) plaisthos: which is cleartext but that does not matter on localhost (22.00.06) segoon: re: user+pass -- understood (22.00.41) segoon: 2) the client connects to openvpn's server socket, registers on rsa-sign event and then should wait for the server's rsa-sign request, right? (22.00.53) plaisthos: I don't know if tunnelblick uses the management interface at the moment (22.00.56) plaisthos: segoon: yes (22.01.19) plaisthos: you can have only one client connected the interface at the time iirc (22.01.38) segoon: i think it can be implemented with config file changes like 'management', 'management-external-key', 'pre-up', etc. (22.01.58) segoon: AFAICS, no actions from Tunnelblick are needed (22.02.19) plaisthos: segoon: tunnelblick might already use the management interface (22.02.25) mattock: I would guess so (22.02.32) plaisthos: just do a ps aux when openvpn is running (22.02.44) segoon: plaisthos: ah, do you mean that it connects to the management interface and I cannot do it again? (22.02.54) plaisthos: iirc tunnelblick adds a ton of options to openvpn via command line (22.03.00) plaisthos: segoon: yes (22.03.52) plaisthos: pretty sure it does (22.04.10) segoon: no, 'ps aux | grep openvpn | grep mana' shows nothing (22.04.18) plaisthos: Acutally thinking about it, since it displays traffic statistics which you only get via management interface (22.04.26) segoon: oh, wait (22.06.38) segoon: nevermind, have problems with Mac :) rebooting (22.07.08) segoon: is it possible to setup management interface for >1 client? (22.07.10) plaisthos: I am at the moment at my windows pc but I can get my Mac out to check (22.07.37) plaisthos: hm (22.07.47) plaisthos: I don't think so (22.07.49) cron2: segoon: no (22.08.01) plaisthos: but I would have to look at the code again (22.08.56) segoon: plaisthos: can you check it on your Mac, please? (22.09.48) plaisthos: lets see if I have a working Tunnelblick installation (22.11.27) segoon: ok, I checked it -- it does use --management (22.12.05) plaisthos: my tunntelblick crashes with sigsev (22.12.05) segoon: so management is not an option, at least with TunnelBlick (22.12.09) syzzer: so that would mean integrating the keychain code into tunnelblick itself (22.12.36) plaisthos: or do a tunnel to your program porxy (22.12.43) plaisthos: in tunnelblick (22.13.51) syzzer: plaisthos: i guess you could, but that sounds a bit hacky. do you think that would be easier than integrating into tunnelblick itself? (22.14.22) plaisthos: syzzer: if you want to have the functionaitaliy without tunnelblick (22.14.29) segoon: plaisthos: sorry, I don't understand your proxy idea (22.14.43) segoon: proxy/tunnel (22.15.09) plaisthos: segoon: when tunnelblick gets a a rsa_sign it sends it to your program instead of cyring and knowing what to do :) (22.16.02) segoon: as I completely don't know TB's internals I cannot say how extensible it is (22.16.29) segoon: OK, I should look at TB's way of --management handling (22.16.39) segoon: am I right that the patch for openvpn is NACK for now? (22.16.39) plaisthos: be warned (22.16.48) plaisthos: building tunntelblick is hellish (22.17.33) cron2: segoon: yeah, sort of "we like the feature, but it might be better done in Tunnelblick"-NAK (22.17.47) syzzer: segoon: I think, but as far is I'm concerned just "for now", as the a solution outside of the openvpn core looks as a beter option (22.19.54) segoon: OK, I'll look at TB. If I'll need openvpn-devel feedback again, how should I ping you guys? (22.20.03) plaisthos: yes (22.20.09) cron2: here, or on the list (22.20.16) plaisthos: if you have question to all the rsa-sign stuff just ping me (22.20.16) cron2: Jonathan Bullard also reads openvpn-devel list (22.20.33) segoon: oh, mailing list, I forgot about it :-) (22.20.48) mattock: :) (22.20.54) mattock: next topic? (22.21.10) segoon: okay, thanks guys! (22.21.41) syzzer: segoon: thank you too! (22.21.44) mattock: you're welcome! (22.22.12) mattock: next topic would be "Make OpenVPN set routes on Windows Vista and later", i.e. the interactive service from d12fk (22.22.20) syzzer: mattock: no, d12fk, so towards the cryptodev patch than? (22.22.28) syzzer: *then (22.22.34) mattock: has anyone reviewed the d12fk's code? (22.22.50) cron2: not me, sorry (22.23.00) syzzer: I started out a bit, but definitely not done (22.23.16) mattock: once the code has seen some review I can generate special Windows installers based on it (22.23.24) mattock: for testing (22.24.02) syzzer: it's on my list to look into it a bit more (22.24.15) mattock: anyhow, let's talk about this when d12fk is here... and hopefully some of you has had time to review the code by then (22.24.26) mattock: maybe retry two weeks from now? (22.24.40) cron2: mattock: yes. But we can cover cryptodev (BSD) (22.24.46) mattock: definitely (22.24.48) mattock: "Openvpn with cryptodev on FreeBSD does not work" (22.24.53) mattock: https://community.openvpn.net/openvpn/ticket/480 (22.24.55) vpnHelper: Title: #480 ([PATCH] Openvpn with crytpodev on FreeBSD does not work) – OpenVPN Community (at community.openvpn.net) (22.25.09) mattock: so "looks innocent, but could break things" (22.25.12) syzzer: yes, so, I looked into this a bit (22.25.26) plaisthos: yes (22.25.56) plaisthos: like how I broke certain obscure chroot configuration with init reordering (22.26.00) cron2: the patch, simple as it is, doesn't sound good to me if it has side-effects (22.26.08) syzzer: the thing is, because the patch pulls the daemon() call forward, some stuff won't work like it used to (22.26.14) cron2: this, yes (22.26.33) syzzer: for example, if you have relative paths in your config file (22.26.35) cron2: so can we just move the cryptodev init after daemon()? I haven't checked where that is actually initialized (22.27.17) syzzer: if that is possible, that would be the preferred solution (22.27.44) syzzer: I just assumed the cryptodev would be automatically initialized when we init openssl (22.28.01) ***cron2 has no idea (22.28.48) syzzer: I don't know either, I don't use freebsd... (22.29.12) cron2: I do, but "man cryptodev" doesn't particularily help here ("it will provide crypto primitives") (22.29.57) plaisthos: isn't cryptodev for hw crypto acclerators? (22.29.58) syzzer: yeah, sounds like openssl opens /dev/crypto, openvpn forks, pid changes, /dev/crypto refuses to answer to the new pid (22.30.09) cron2: plaisthos: yes (22.30.21) syzzer: plaisthos: yes, including stuff like aes-ni iirc (22.30.29) cron2: The crypto driver provides a device-independent framework to support (22.30.29) cron2: cryptographic operations in the kernel. The cryptodev driver provides (22.30.32) cron2: userland applications access to this support through the /dev/crypto (22.30.34) cron2: device. This node primarily operates in an ioctl(2) based model, permit- (22.30.37) cron2: ting a variety of applications to query device capabilities, submit (22.30.39) plaisthos: (which is stupid for aes-ni) (22.30.40) cron2: transactions, and get results. (22.31.17) segoon ha abbandonato la stanza (quit: Quit: WeeChat 0.3.7). (22.31.21) cron2: so - can we easily move just openssl init to "after daemon()"? (22.32.16) plaisthos: yeah (22.32.16) syzzer: cron2: don't think so, we currently load certs etc there (22.32.27) plaisthos: see syzzer (22.32.38) syzzer: and the problem is those paths no longer work after daemon() (22.32.39) cron2: oh (22.33.32) syzzer: but I have to dig a bit deeper, I just wanted to hear your thought on whether it's bad if relative patch no longer work when using --daemon without --cd (22.33.32) jamesyonan ha abbandonato la stanza (quit: Ping timeout: 244 seconds). (22.33.50) cron2: this will break user configs, so "yes" (22.34.52) cron2: I see inside possibly_become_daemon() a pkcs11_forkFixup (); (22.34.59) syzzer: ok, in that case it's a NAK for now, I'll look into it a bit more (22.35.10) cron2: maybe there is an openssl_forkFixup()? (22.35.19) syzzer: yeah, some magic inside pkcs11-helper (I didn't really look into it more) (22.38.53) cron2: mmh, googling suggests that there is cryptodev for linux, and openssl can talk to it (22.41.18) syzzer: I doing multiple things at the same time now, will look into it later (22.41.41) mattock: ok, meeting concluded? (22.42.16) cron2: plaisthos: when you have time, could you look at my bikesheds? (22.43.04) mattock: meeting concluded, sending out the summary (22.43.07) mattock: :) (22.43.12) cron2: g'night (22.43.20) syzzer: ok, good :)
openvpn_irc_meeting_chatlog_2014-12-29.txt.sig
Description: PGP signature
