From: Samuli S. <sa...@op...> - 2012-02-28 14:30:35
Attachments:
changelog-2.3-alpha1.txt
|
The OpenVPN community project team is proud to release OpenVPN 2.3-alpha1. It can be downloaded from here: <http://openvpn.net/index.php/open-source/downloads.html> This release includes a few new major features: * Complete IPv6 support, both transport and payload * Optional PolarSSL support (build time configuration) * Improved plug-in API (v3) which can more easily be expanded in the future: includes support for direct access to X.509 certificate data in plug-ins * Several improvements to the management interface * One-to-one NAT to circumvent IP address conflicts between local and remote networks * New OpenVPN-GUI Note that a few changes have been made which may affect existing installations. A list of new features and the changelog are available here: <https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23> The changelog is also attached to this email. For generic help use these support channels: - Official documentation: <http://openvpn.net/index.php/open-source/documentation/howto.html> - Wiki: <https://community.openvpn.net> - Forums: <https://forums.openvpn.net> - User mailing list: <http://sourceforge.net/mail/?group_id=48978> - User IRC channel: #openvpn at irc.freenode.net Please report bugs and ask development questions here: - Bug tracker and Wiki: <https://community.openvpn.net> - Developer mailing list: <http://sourceforge.net/mail/?group_id=48978> - Developer IRC channel: #openvpn-devel at irc.freenode.net (requires Freenode registration) -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock |
From: Mr D. F. <mr....@go...> - 2012-02-28 16:32:41
|
> * Improved plug-in API (v3) which can more easily be expanded in the > future: includes support for direct access to X.509 certificate data in > plug-ins > [...] > * One-to-one NAT to circumvent IP address conflicts between local and > remote networks > Is there any help/doc/wiki where I could get more information/learn more about these new features? |
From: David S. <ope...@to...> - 2012-02-28 17:04:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/12 17:32, Mr Dash Four wrote: > >> * Improved plug-in API (v3) which can more easily be expanded in >> the future: includes support for direct access to X.509 certificate >> data in plug-ins [...] * One-to-one NAT to circumvent IP address >> conflicts between local and remote networks >> > Is there any help/doc/wiki where I could get more information/learn > more about these new features? For the plug-in API ... look at openvpn-plugin.h ... look for openvpn_plugin_*_v3. Especially openvpn_plugin_open_v3() and openvpn_plugin_func_v3(). If fact, most of the openvpn-plugin.h is a pretty comprehensive reference for the plugin API. For a working example, look at plugin/examples/log_v3.c. For the --client-nat ... look at the man new page. <http://openvpn.net/index.php/manuals/523-openvpn-23.html> kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9NCO0ACgkQDC186MBRfrpXDQCghQoK0eW927kHqHtzri5KOdme p2IAn0WIwLjrv5rTwWtA7FcFzo5IKLbU =zu4J -----END PGP SIGNATURE----- |
From: Samuli S. <sa...@op...> - 2012-02-29 08:59:29
|
>> * Improved plug-in API (v3) which can more easily be expanded in the >> future: includes support for direct access to X.509 certificate data in >> plug-ins >> [...] >> * One-to-one NAT to circumvent IP address conflicts between local and >> remote networks >> > Is there any help/doc/wiki where I could get more information/learn more > about these new features? > The one-to-one NAT feature seems to be described on the man-page in the "--client-nat" section. The new management features are James' handywork, so they're probably described here: <http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html> If not, then maybe on the man-page, or not at all. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock |
From: Mr D. F. <mr....@go...> - 2012-02-29 15:00:09
|
> The one-to-one NAT feature seems to be described on the man-page in the > "--client-nat" section. The new management features are James' > handywork, so they're probably described here: > > <http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html> > > If not, then maybe on the man-page, or not at all. > Thanks, that's good, I'll have a detailed look later on today. |
From: Mr D. F. <mr....@go...> - 2012-02-29 15:01:57
|
> For the plug-in API ... look at openvpn-plugin.h ... look for > openvpn_plugin_*_v3. Especially openvpn_plugin_open_v3() and > openvpn_plugin_func_v3(). If fact, most of the openvpn-plugin.h is a > pretty comprehensive reference for the plugin API. For a working > example, look at plugin/examples/log_v3.c. > > For the --client-nat ... look at the man new page. > <http://openvpn.net/index.php/manuals/523-openvpn-23.html> > Thanks, I'll have a look later on today. Does this differ from the "old" plugin mechanism in v2.2? |
From: David S. <ope...@to...> - 2012-02-29 15:54:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/02/12 16:01, Mr Dash Four wrote: > >> For the plug-in API ... look at openvpn-plugin.h ... look for >> openvpn_plugin_*_v3. Especially openvpn_plugin_open_v3() and >> openvpn_plugin_func_v3(). If fact, most of the openvpn-plugin.h is >> a pretty comprehensive reference for the plugin API. For a working >> example, look at plugin/examples/log_v3.c. >> >> For the --client-nat ... look at the man new page. >> <http://openvpn.net/index.php/manuals/523-openvpn-23.html> >> > Thanks, I'll have a look later on today. Does this differ from the > "old" plugin mechanism in v2.2? Yes, it differs quite a bit. The v3 API is brand new. It has a very different argument list than the v1 and v2 API. However, with the v3 it is expected that the plug-in API itself (function declarations) will not change again. The v3 passes structs with the information, where the v1 and v2 APIs used separate arguments to the plug-in functions. The advantage here is that the plug-ins don't have to be rebuilt if these structs are extended in the future. It's an "unwritten rule" that we will not reduce or re-order the struct contents, only extend it. And there are some version indicators as well, so that if you have a plug-in depending on a minium struct version; you can check this before continuing to extract data. This way, backward compatibility should be handled pretty nicely. I would recommend all plug-in writers to mainly focus on the v3 API. At some point in the future we might deprecate the old APIs and reduce it to only one single API. But anyhow, this won't happen in the near future. If a plug-in contains both v3, v2 and/or v1 functions, only the newest version will be used. So you can write a plug-in which can make advantage of the new API and features with the latest OpenVPN, while having a fall-back for older OpenVPN versions. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9OSgQACgkQDC186MBRfro/uwCgmpKDIIfbkoa5wSSp74sWPRBQ 2zEAoJgGvHAwlkN8e7g9Do88FT8zddtD =SqQN -----END PGP SIGNATURE----- |
From: Carsten K. <C.K...@gm...> - 2012-02-28 17:57:50
|
Hello Samuli, > The OpenVPN community project team is proud to release OpenVPN > 2.3-alpha1. It can be downloaded from here: > <http://openvpn.net/index.php/open-source/downloads.html> > This release includes a few new major features: > * Complete IPv6 support, both transport and payload > * Optional PolarSSL support (build time configuration) > * Improved plug-in API (v3) which can more easily be expanded in the > future: includes support for direct access to X.509 certificate data in > plug-ins > * Several improvements to the management interface > * One-to-one NAT to circumvent IP address conflicts between local and > remote networks > * New OpenVPN-GUI Are there any chances to get full non-admin support for windows in version 2.3 final? I mean strict seperation between OpenVPN service running with local system privileges (can modify routes, etc.) and usermode part (command line, maybe GUI) that interacts with user (start/stop tunnel, ask for passphrase, pin for smartcard, etc.). In companies that have security in mind it's impossible to allow roadwarriors to connect via openvpn because they would need admin privileges. Give them only the privilege to start/stop the openvpn service didn't help because they can't supply credentials. I'm complaining about this show stoppper for ~4 years :-( I personally like openvpn very much and would like to deploy it for our users but I've to buy Cisco because the windows client is better. greetings Carsten |
From: Gert D. <ge...@gr...> - 2012-02-28 20:02:07
|
Hi, On Tue, Feb 28, 2012 at 06:31:03PM +0100, Carsten Krüger wrote: > Are there any chances to get full non-admin support for windows in version 2.3 final? Work is going on on full privilege separation for windows. It's not done yet, so we'll see whether it will make 2.3 (which was the initial plan) or 2.4. I'll let the author comment on more details if he wants to :-) (thus not naming anyone - it's not me, though). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... |
From: Alon Bar-L. <alo...@gm...> - 2012-02-28 18:07:40
|
2012/2/28 Carsten Krüger <C.K...@gm...>: >> * New OpenVPN-GUI > > Are there any chances to get full non-admin support for windows in version 2.3 final? > > I mean strict seperation between OpenVPN service running with local system > privileges (can modify routes, etc.) and usermode part (command line, maybe GUI) that > interacts with user (start/stop tunnel, ask for passphrase, pin for smartcard, etc.). > > In companies that have security in mind it's impossible to allow > roadwarriors to connect via openvpn because they would need admin > privileges. > Give them only the privilege to start/stop the openvpn service didn't help because they can't supply credentials. > > I'm complaining about this show stoppper for ~4 years :-( > > I personally like openvpn very much and would like to deploy it for > our users but I've to buy Cisco because the windows client is better. This is *THE* missing functionality in Windows environment. It seems that nobody interested in developing proper UI using management interface for Windows. Same goes to proper smartcard support. In Linux I am using OpenVPN using unprivileged user (completely!) the daemon runs under my own user, see[1]. Alon. [1] http://en.gentoo-wiki.com/wiki/OpenVPN_Non_Root |
From: David S. <ope...@to...> - 2012-02-28 18:11:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/12 18:31, Carsten Krüger wrote: > Hello Samuli, > >> The OpenVPN community project team is proud to release OpenVPN >> 2.3-alpha1. It can be downloaded from here: > >> <http://openvpn.net/index.php/open-source/downloads.html> > >> This release includes a few new major features: > >> * Complete IPv6 support, both transport and payload * Optional >> PolarSSL support (build time configuration) * Improved plug-in API >> (v3) which can more easily be expanded in the future: includes >> support for direct access to X.509 certificate data in plug-ins * >> Several improvements to the management interface * One-to-one NAT to >> circumvent IP address conflicts between local and remote networks * >> New OpenVPN-GUI > > Are there any chances to get full non-admin support for windows in > version 2.3 final? > > I mean strict seperation between OpenVPN service running with local > system privileges (can modify routes, etc.) and usermode part (command > line, maybe GUI) that interacts with user (start/stop tunnel, ask for > passphrase, pin for smartcard, etc.). This is definitely in the pipe for v2.3. I don't know how far Heiko have come on that since last time we discussed it on the #openvpn-devel channel, but he is really progressing very well here. The solution we've ended up with is a OpenVPN service helper which runs some code parts with admin rights and the OpenVPN binary itself (openvpn.exe) will run completely unprivileged. Those two instances will communicate via named pipes, to set up the proper routes and other networking parameters. > In companies that have security in mind it's impossible to allow > roadwarriors to connect via openvpn because they would need admin > privileges. Give them only the privilege to start/stop the openvpn > service didn't help because they can't supply credentials. > > I'm complaining about this show stoppper for ~4 years :-( > > I personally like openvpn very much and would like to deploy it for > our users but I've to buy Cisco because the windows client is better. The time of complaining will come to an end with 2.3 :) Heiko demonstrated his prototype at FOSDEM a few weeks ago. And it really looked very impressive. But there are some changes to the openvpn code base which needs to be applied, in addition to be synced with the GUI code base. So we decided to postpone this particular feature to a later alpha release - instead of postponing the first alpha release even more. Just to give Heiko a bit better time to complete his code. But there are so many requesting this feature, we really can't ignore it any more. And Heiko is free to flog me if I've said and/or promised too much :) kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9NGL4ACgkQDC186MBRfrqyBQCePJd6rZ32WeDk09s9xQcNnTTh J6AAn2vDkemZkTZcou3Mctor47hi+y3W =VlJA -----END PGP SIGNATURE----- |
From: Carsten K. <C.K...@gm...> - 2012-02-28 18:17:59
|
Hello Alon, ABL> This is *THE* missing functionality in Windows environment. ABL> It seems that nobody interested in developing proper UI using ABL> management interface for Windows. ABL> Same goes to proper smartcard support. Developing the UI (command line) would be trivial but to my knowledge (I'm reading the mailinglist for last 7 years) there is no management interface in openvpn that would allow this. ABL> In Linux I am using OpenVPN using unprivileged user (completely!) the ABL> daemon runs under my own user, see[1]. With su this is trivial :-) greetings Carsten |
From: David S. <ope...@to...> - 2012-02-28 18:26:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/12 19:07, Alon Bar-Lev wrote: > 2012/2/28 Carsten Krüger <C.K...@gm...>: >>> * New OpenVPN-GUI >> >> Are there any chances to get full non-admin support for windows in >> version 2.3 final? >> >> I mean strict seperation between OpenVPN service running with local >> system privileges (can modify routes, etc.) and usermode part >> (command line, maybe GUI) that interacts with user (start/stop >> tunnel, ask for passphrase, pin for smartcard, etc.). >> >> In companies that have security in mind it's impossible to allow >> roadwarriors to connect via openvpn because they would need admin >> privileges. Give them only the privilege to start/stop the openvpn >> service didn't help because they can't supply credentials. >> >> I'm complaining about this show stoppper for ~4 years :-( >> >> I personally like openvpn very much and would like to deploy it for >> our users but I've to buy Cisco because the windows client is >> better. > > This is *THE* missing functionality in Windows environment. It seems > that nobody interested in developing proper UI using management > interface for Windows. Same goes to proper smartcard support. I believe Jan Just Keijser and Heiko talked about this as well at FOSDEM, how to provide a better integrated PKCS#11 support in the Windows GUI. So I would expect this to progress too. And of course, the new GUI Heiko writes is using the management interface too, anything else would be plain stupid these days. Even though, the new communication pipe between the "helper service" and openvpn.exe might gain more features with time, which might cover much of what the management interface provides today too. But we're _not_ trying to kill the management interface. > In Linux I am using OpenVPN using unprivileged user (completely!) the > daemon runs under my own user, see[1]. This new communication pipe should also become available for the *nix platform too. Which again should make it easier to implement something which does not depend on a safe sudo setup too. Maybe even some integration against NetworkManager via DBus for the Linux platform? I'm at least playing with the idea that OpenVPN itself shouldn't necessarily need to know much about how to configure the TUN/TAP device and routes for all different platforms. Rather write platform specific "service helpers" which does that job via the the communication pipe. This would make the OpenVPN code base simpler and perhaps even easier to support more platforms, like Android - and maybe even iPhone and the new Windows Mobile? kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9NHBQACgkQDC186MBRfrrs8ACfT93nLXZ727QLP24FFs/C5hw0 CSMAn0ECng3+celO1axW27gzyNq6aEJw =tGiN -----END PGP SIGNATURE----- |
From: Alon Bar-L. <alo...@gm...> - 2012-02-28 18:39:04
|
On Tue, Feb 28, 2012 at 8:25 PM, David Sommerseth <ope...@to...> wrote: >> This is *THE* missing functionality in Windows environment. It seems >> that nobody interested in developing proper UI using management >> interface for Windows. Same goes to proper smartcard support. > > I believe Jan Just Keijser and Heiko talked about this as well at FOSDEM, > how to provide a better integrated PKCS#11 support in the Windows GUI. > So I would expect this to progress too. And of course, the new GUI Heiko > writes is using the management interface too, anything else would be > plain stupid these days. Right. I don't know what he is writing. Anyway, the message I sent today regarding the external key is the root. Adding functionality to set the certificate via the management have the potential to resolve the whole issue. > Even though, the new communication pipe between the "helper service" and > openvpn.exe might gain more features with time, which might cover much > of what the management interface provides today too. But we're _not_ > trying to kill the management interface. There is no need for the helper service. Nobody care if the openvpn daemon is running in privilege mode. The problem is the user interaction. So I would have avoided to invest resources at the daemon side and invest resources at proper UI. >> In Linux I am using OpenVPN using unprivileged user (completely!) the >> daemon runs under my own user, see[1]. > > This new communication pipe should also become available for the *nix > platform too. Which again should make it easier to implement something > which does not depend on a safe sudo setup too. Maybe even some > integration against NetworkManager via DBus for the Linux platform? dbus is way too fragile, it is good for desktop... not for core components. And... requiring network manager (large piece of software) only for iproute2 replacement is redundant. The management interface is great. Again, the main problem is not the daemon but the user. I went one step farther and wrapped the iproute2... this is optional. > I'm at least playing with the idea that OpenVPN itself shouldn't > necessarily need to know much about how to configure the TUN/TAP device > and routes for all different platforms. Rather write platform specific > "service helpers" which does that job via the the communication pipe. > > This would make the OpenVPN code base simpler and perhaps even easier to > support more platforms, like Android - and maybe even iPhone and the new > Windows Mobile? Well, this can be done now, just wrap the iproute with suid program to do whatever you like, this is the wrapper. The tap device can be accessed using non-privileged user, so all that is left is the iproute2 delegation. This does not require special code or effort. Bottom line: the management interface is great. One missing functionality is setting certificate. Effort should be invested in proper UI to leverage the management interface. Running openvpn *DAEMON* as completely unprivileged is 2nd priority. On Linux it can be done by simply wrapping the iproute2 executable, using sudo/dbus whatever to achieve same functionality. On Windows a similar solution may be provided. Alon. |
From: Heiko H. <hei...@so...> - 2012-02-29 10:16:42
|
On Tuesday 28 February 2012 18:38:57 Alon Bar-Lev wrote: > > Even though, the new communication pipe between the "helper service" and > > openvpn.exe might gain more features with time, which might cover much > > of what the management interface provides today too. But we're _not_ > > trying to kill the management interface. > > There is no need for the helper service. > Nobody care if the openvpn daemon is running in privilege mode. > The problem is the user interaction. > So I would have avoided to invest resources at the daemon side and invest > resources at proper UI. The idea to have the service do the privileged operations instead of just starting openvpn as "Local System" (or whatever) came from the fear of privilege escalation in the scripts that are run by openvpn. So, at least I care that it's not running in privilege mode. Your point is invalid. =P Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen |
From: Alon Bar-L. <alo...@gm...> - 2012-02-29 10:22:57
|
On Wed, Feb 29, 2012 at 12:16 PM, Heiko Hund <hei...@so...> wrote: > > On Tuesday 28 February 2012 18:38:57 Alon Bar-Lev wrote: > > > Even though, the new communication pipe between the "helper service" > > > and > > > openvpn.exe might gain more features with time, which might cover > > > much > > > of what the management interface provides today too. But we're _not_ > > > trying to kill the management interface. > > > > There is no need for the helper service. > > Nobody care if the openvpn daemon is running in privilege mode. > > The problem is the user interaction. > > So I would have avoided to invest resources at the daemon side and > > invest > > resources at proper UI. > > The idea to have the service do the privileged operations instead of just > starting openvpn as "Local System" (or whatever) came from the fear of > privilege escalation in the scripts that are run by openvpn. So, at least > I > care that it's not running in privilege mode. Your point is invalid. =P > It all a matter of priorities and the ability to execute each. Implementing proper UI is the least effort and greatest benefit. That's said, Nobody claims the fact that openvpn runs the scripts is OK. Proper/simple solution would be to deligate script execution via the management interface, leaving the openvpn to be small and secured. Hence, there are several possible solutions for the same problem, while the monolithic approach suffers from disadvantages. Alon. |
From: Carsten K. <C.K...@gm...> - 2012-02-29 10:50:31
|
Hello Heiko, > The idea to have the service do the privileged operations instead of just > starting openvpn as "Local System" (or whatever) came from the fear of > privilege escalation in the scripts that are run by openvpn. Scripting is a point, but as long as the administrator installs openvpn + config + script to a folder that is non writeable for users there should be no problem. From hackers point of view (send malicious packets to openvpn client to exploit a bug) least privileges is a very good idea. > So, at least I care that it's not running in privilege mode. Your point is invalid. =P I created a new user "openvpn", only group membership "network configuration operator" and add him the right to logon as a service. Now openvpnserver.exe runs as user openvpn and it works. According to MS members of this group can't do to much harmfull: http://support.microsoft.com/kb/297938 greetings Carsten |
From: Carsten K. <C.K...@gm...> - 2012-02-28 18:29:14
|
Hello David, > The solution we've ended up with is a OpenVPN service helper which runs > some code parts with admin rights and the OpenVPN binary itself > (openvpn.exe) will run completely unprivileged. Those two instances will > communicate via named pipes, to set up the proper routes and other > networking parameters. Why named pipes? Why don't extend this http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html that it works without admin privileges? > The time of complaining will come to an end with 2.3 :) Heiko > demonstrated his prototype at FOSDEM a few weeks ago. And it really > looked very impressive. But there are some changes to the openvpn code > base which needs to be applied, in addition to be synced with the GUI > code base. So we decided to postpone this particular feature to a later > alpha release - instead of postponing the first alpha release even more. > Just to give Heiko a bit better time to complete his code. But there > are so many requesting this feature, we really can't ignore it any more. > And Heiko is free to flog me if I've said and/or promised too much :) great !!!! greetings Carsten |
From: David S. <ope...@to...> - 2012-02-28 18:31:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/12 19:17, Carsten Krüger wrote: > Hello Alon, > > ABL> This is *THE* missing functionality in Windows environment. ABL> > It seems that nobody interested in developing proper UI using ABL> > management interface for Windows. ABL> Same goes to proper smartcard > support. > > Developing the UI (command line) would be trivial but to my knowledge > (I'm reading the mailinglist for last 7 years) there is no management > interface in openvpn that would allow this. > Have you seen this document? (management/management-notes.txt) <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob_plain;f=management/management-notes.txt;hb=master> Especially look for all the 'pkcs11' prefixed calls, like pkcs11-id-count, pkcs11-id-get. Further James implemented a new feature for the management interface where you can pass the certificate this way too. Unfortunately, as Alon pointed out, this has not yet been documented well - except in the commit log. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commit;h=cf69617bbea45a15423c4188daa9386debcbe1ec> So things are happening here too. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9NHVwACgkQDC186MBRfrr/qgCdF2BT+TqE+h2x/Aqoin271bc0 wfAAn2va1LDzeRo9Km8eQqmYWlsvFJ4E =dhKu -----END PGP SIGNATURE----- |
From: Carsten K. <C.K...@gm...> - 2012-02-28 19:36:33
|
Hello David, > Have you seen this document? (management/management-notes.txt) > <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob_plain;f=management/management-notes.txt;hb=master> No. I connected to management interface and got this: > Management Interface for OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011 > Commands: > auth-retry t : Auth failure retry mode (none,interact,nointeract). > bytecount n : Show bytes in/out, update every n secs (0=off). > echo [on|off] [N|all] : Like log, but only show messages in echo buffer. > exit|quit : Close management session. > forget-passwords : Forget passwords entered so far. > help : Print this message. > hold [on|off|release] : Set/show hold flag to on/off state, or > release current hold and start tunnel. > kill cn : Kill the client instance(s) having common name cn. > kill IP:port : Kill the client instance connecting from IP:port. > load-stats : Show global server load stats. > log [on|off] [N|all] : Turn on/off realtime log display > + show last N lines or 'all' for entire history. > mute [n] : Set log mute level to n, or show level if n is absent. > needok type action : Enter confirmation for NEED-OK request of 'type', > where action = 'ok' or 'cancel'. > needstr type action : Enter confirmation for NEED-STR request of 'type', > where action is reply string. > net : (Windows only) Show network info and routing table. > password type p : Enter password p for a queried OpenVPN password. > pid : Show process ID of the current OpenVPN process. > pkcs11-id-count : Get number of available PKCS#11 identities. > pkcs11-id-get index : Get PKCS#11 identity at index. > signal s : Send signal s to daemon, > s = SIGHUP|SIGTERM|SIGUSR1|SIGUSR2. > state [on|off] [N|all] : Like log, but show state history. > status [n] : Show current daemon status info using format #n. > test n : Produce n lines of output for testing/debugging. > username type u : Enter username u for a queried OpenVPN username. > verb [n] : Set log verbosity level to n, or show if n is absent. > version : Show current version number. > http-proxy-fallback <server> <port> [flags] : Enter dynamic HTTP proxy fallback info. > http-proxy-fallback-disable : Disable HTTP proxy fallback. > END I don't see a command to connect openvpn to a host. I'd like to install openvpn on windows, install it as a service -----------mini_client.ovpn---------------- management localhost 7505 remote myremote.mydomain dev tun ifconfig 10.8.0.2 10.8.0.1 secret static.key -----------mini_client.ovpn---------------- and than telnet to localhost 7505 and send something like "connect mini_client" or if it's more complex -----------complex_client.ovpn---------------- management localhost 7505 remote myremote.mydomain dev tun client auth-user-pass ca ca.pem -----------complex_client.ovpn---------------- telnet localhost 7505 connect complex_client u carsten p test greetings Carsten |
From: Alon Bar-L. <alo...@gm...> - 2012-02-28 18:43:03
|
2012/2/28 David Sommerseth <ope...@to...>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28/02/12 19:17, Carsten Krüger wrote: >> Hello Alon, >> >> ABL> This is *THE* missing functionality in Windows environment. ABL> >> It seems that nobody interested in developing proper UI using ABL> >> management interface for Windows. ABL> Same goes to proper smartcard >> support. >> >> Developing the UI (command line) would be trivial but to my knowledge >> (I'm reading the mailinglist for last 7 years) there is no management >> interface in openvpn that would allow this. >> > > Have you seen this document? (management/management-notes.txt) > <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob_plain;f=management/management-notes.txt;hb=master> > > Especially look for all the 'pkcs11' prefixed calls, like > pkcs11-id-count, pkcs11-id-get. Further James implemented a new feature > for the management interface where you can pass the certificate this way > too. Unfortunately, as Alon pointed out, this has not yet been > documented well - except in the commit log. These features are mine. I wrote these.... and the whole PKCS#11 layer, and many other... like the ability to wrap the iproute2. They are good, but not great. Why? Because the openvpn daemon it-self loads the PKCS#11 provider. This is a security violation. The PKCS#11 provider should be loaded by the UI, so the daemon cannot interact with it at will. It also makes the security openvpn weaker, as foreign library is loaded into the openvpn process. And at Windows 7+ there is a problem, a service cannot access the smartcard readers of the users. And... even if it can (XP), you cannot use smartcard in remote desktop session. Alon. |
From: David S. <ope...@to...> - 2012-02-28 18:55:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/12 19:42, Alon Bar-Lev wrote: > 2012/2/28 David Sommerseth <ope...@to...>: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 28/02/12 19:17, Carsten Krüger wrote: >>> Hello Alon, >>> >>> ABL> This is *THE* missing functionality in Windows environment. >>> ABL> It seems that nobody interested in developing proper UI using >>> ABL> management interface for Windows. ABL> Same goes to proper >>> smartcard support. >>> >>> Developing the UI (command line) would be trivial but to my >>> knowledge (I'm reading the mailinglist for last 7 years) there is >>> no management interface in openvpn that would allow this. >>> >> >> Have you seen this document? (management/management-notes.txt) >> <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob_plain;f=management/management-notes.txt;hb=master> >> >> >> Especially look for all the 'pkcs11' prefixed calls, like >> pkcs11-id-count, pkcs11-id-get. Further James implemented a new >> feature for the management interface where you can pass the >> certificate this way too. Unfortunately, as Alon pointed out, this >> has not yet been documented well - except in the commit log. > > These features are mine. I wrote these.... and the whole PKCS#11 > layer, and many other... like the ability to wrap the iproute2. They > are good, but not great. Why? Because the openvpn daemon it-self loads > the PKCS#11 provider. This is a security violation. The PKCS#11 > provider should be loaded by the UI, so the daemon cannot interact > with it at will. Agreed! And I remember this was part of the discussions at FOSDEM. How should the GUI communicate in regards to the PKCS#11 layer, and how to provide the proper information towards the core OpenVPN process. We were not aware of the --management-external-key at that point, but I think this is the natural way to look now. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9NIykACgkQDC186MBRfrqdvQCgpOTCxegtLzCPaQ6eOnxfuCOA v58AnA2d/xD1/zhXZRj/SWqplv/t//mV =cDMr -----END PGP SIGNATURE----- |
From: David S. <ope...@to...> - 2012-02-28 18:51:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/12 19:29, Carsten Krüger wrote: > Hello David, > >> The solution we've ended up with is a OpenVPN service helper which >> runs some code parts with admin rights and the OpenVPN binary >> itself (openvpn.exe) will run completely unprivileged. Those two >> instances will communicate via named pipes, to set up the proper >> routes and other networking parameters. > > Why named pipes? > > Why don't extend this > http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html > > that it works without admin privileges? Heiko can probably give a much better answer, but if I remember right, the argument was this: Think of a multi-user setup (like a Terminal Server), the management interface will be accessible for all users on that server. Named pipes will be available only for that single user, so the attack vector in an abuse scenario, compared to the management interface, is more limited. And considering this pipe will do privileged network setup, it should be restricted as much as possible. I don't recall now if there was even more restrictions you could apply to these pipes as well. And how this is implemented, the OpenVPN Service will be started automatically. The GUI contacts the Service and the service starts the OpenVPN process with the privileges of the GUI user (IIRC, it was some neat Windows functions which allows to create processes with privileges based upon the user credentials of the other side of the named pipe). And again, the only code pieces in the Service are those related to network configuration. The rest of the Service code runs unprivileged. This service should be able to (for now only in theory; it has not been tested yet) handle more users simultaneously. However, the management interface will be used in addition too, at least in the very beginning, where the logging is transferred back to the GUI and so on. I don't recall now all the GUI would do via this interface. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9NIhAACgkQDC186MBRfrpPJwCfYlbHHIGZtb8TQj2v7ZJKCcxw NFEAmQGuOczRPZzMswO5lDxJEdgtEDs+ =L5DL -----END PGP SIGNATURE----- |
From: Carsten K. <C.K...@gm...> - 2012-02-28 22:09:20
|
Hello David, DS> Heiko can probably give a much better answer, but if I remember right, DS> the argument was this: Think of a multi-user setup (like a Terminal DS> Server), the management interface will be accessible for all users on DS> that server. a) Who an earth allows users on a terminal server to create VPN-sessions? What happens if one of the sessions use redirect gateway? All users are redirected? b) you can set a password for management interface I don't think that this is a valid point. Privilege seperation in openvnp deamon is nice, but is a complete different thing than management interface access. I try to compare it with apache. Apache on linux need root rights to bind to port below 1024 but it didn't need to have root privilege to serve a page. So it's a good idea to use root rights to bind to port 80 and than serve all pages without root rights. OpenVPN need root rights on linux/administrator rights on windows (to be more precise network operator rights) to modify routing tables. In openvpn case it should be something like this: openvpnserv.exe running as a service, has no privileges and opens management interface openvpnhelpserv.exe running as a service has network operator rights (no need for local system ...) openvpnserv and openvpnhelpserv could communicate via pipe. openvpn-management client (could be a perl script) connects to management interface of openvpnserv.exe to start/stop a tunnel and supply secrets. DS> And how this is implemented, the OpenVPN Service will be started DS> automatically. The GUI contacts the Service and the service starts the DS> OpenVPN process with the privileges of the GUI user (IIRC, it was some DS> neat Windows functions which allows to create processes with privileges DS> based upon the user credentials of the other side of the named pipe). The sounds very bad. The service shouldn't create processes in the name of the user. DS> This service should be able to (for now only in theory; it has not been DS> tested yet) handle more users simultaneously. Pretty useless, see above DS> However, the management interface will be used in addition too, at least DS> in the very beginning, where the logging is transferred back to the GUI DS> and so on. I don't recall now all the GUI would do via this interface. Sounds very weird. greetings Carsten |
From: Carsten K. <C.K...@gm...> - 2012-02-28 20:34:28
|
Hello Alon, > This is *THE* missing functionality in Windows environment. > It seems that nobody interested in developing proper UI using > management interface for Windows. > Same goes to proper smartcard support. I found that openvpn management interface works as I'd like it. Add the following lines to client.ovpn -------------------------------- management localhost 1000 management-query-passwords auth-retry interact management-hold -------------------------------- and start the service. Use putty to connect to localhost port 1000, format RAW |>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info |>HOLD:Waiting for hold release |hold release |SUCCESS: hold release succeeded |>PASSWORD:Need 'Auth' username/password |username Auth here_comes_my_username |SUCCESS: 'Auth' username entered, but not yet verified |password Auth here_comes_my_mypassword |SUCCESS: 'Auth' password entered, but not yet verified et voila openvpn connects. I'd like to cry, how long did this works? I found this in changelog: 2004.11.28 -- Version 2.0-beta18 * Added management interface. See new --management-* options or the full management interface documentation in management/management-notes.txt in the tarball. greetings Carsten |