openvpn-devel Mailing List for OpenVPN

Hi David, I am sorry for the delay but I was very busy :( I hope that I resolved all issues. I made several tests with my aaa plugin prototype based on following crypto backends: openssl-1.0.0m (no EKM support) openssl-1.0.1 (with EKM support) openssl-1.1.0-dev (with EKM support) PolarSSL 1.3.8 (no EKM support) a) tls_binding_key is available in OPENVPN_PLUGIN_TLS_FINAL only. b) It depends (if someone request such feature I am open for extending) c) Hex format is without spaces d) It is working with PolarSSL f) Man pages were updated to: Save Exported Keying Material [RFC5705] of len bytes using label in environment (tls_binding_key) for use by plugins in OPENVPN_PLUGIN_TLS_FINAL callback. Note that exporter labels have the potential to collide with existing PRF labels. In order to prevent this, labels MUST begin with "EXPORTER". This option requires OpenSSL 1.0.1 or newer. Regards Daniel On Thu, Jun 05, 2014 at 11:28:16PM +0200, David Sommerseth wrote: > On 26/05/14 15:25, Daniel Kubec wrote: > > Add support for TLS Keying Material Exporters [RFC 5705]. > > > > Keying Material Exporter allow additional keying material to be derived from existing TLS channel. > > This exported keying material can then be used for a variety of purposes. > > > > I've finally had some time to compile and test this patch, as well as > done code review of it. First of all, this is a good piece of work! So > I'm looking forward to see this arrive in OpenVPN. It will surely help > develop more advanced authentication methods. > > The patch does indeed work quite well. It provides a tls_binding_key > environment variable to plugins which supports OPENVPN_PLUGIN_TLS_FINAL. > > Here's my comments, thoughts and questions ... > > a) Is the intention that this tls_binding_key variable should only be > available when the OPENVPN_PLUGIN_TLS_FINAL plugin call happens? > > Currently tls_binding_key is available to all plugin *and* script > calls happening after OPENVPN_PLUGIN_TLS_FINAL has been called. But > *only* after a plugin which supports this hook has run. This smells > like a bug. > > I think I would recommend this variable only to available for the > OPENVPN_PLUGIN_TLS_FINAL call. Which means you would need to add a > setenv_del() in ssl.c:key_method_2_read() after plugin_call(). > > I spotted tls_binding_key in the following hooks (using a slightly > modified sample-plugin/log/log.c) > > Client side: PLUGIN_IPCHANGE, PLUGIN_UP, PLUGIN_ROUTE_UP > and PLUGIN_ROUTE_DOWN > > Server side: PLUGIN_IPCHANGE, PLUGIN_CLIENT_CONNECT_V2*, > PLUGIN_LEARN_ADDRESS and PLUGIN_CLIENT_DISCONNECT > > * Most likely PLUGIN_CLIENT_CONNECT too > > I also tried to use a --client-connect script which dumps 'printenv' > to a file. When this log.so plug-in was used, I saw tls_binding_key > in the printenv dump. It was not present when log.so was not loaded. > > > b) Should there be a script-hook available for this as well? > > This could make it possible to make authentication methods using > scripts as an addition to plug-ins written in C. Just thinking > aloud, not saying it's a requirement. > > > c) The format is currently like this: > 0f3d5a7a 8b78fe1a 8a7fce61 58b89142 > Is this format the preferred formatting? > > Other formats are available through format_hex_ex(). I would > probably recommend another separator than space, if a separator is > needed at all. > > > d) This patch breaks building with PolarSSL. > > ssl.o: In function `key_method_2_read': > ~/openvpn.git/src/openvpn/ssl.c:2129: undefined reference to > `key_state_export_keying_material' > collect2: error: ld returned 1 exit status > > I would recommend to add a kind of wrapper function in > ssl_polarssl.c which adds this function. Not sure if it would > be appropriate to do an ASSERT(0) or do something else. Maybe it > should not set anything, just return without adding the > tls_binding_key. When plug-ins expecting to see this fails to find > this variable, it will the plug-in's responsibility to not explode. > > > e) Has this patch been tested with OpenSSL < 1.0.1? > > Is it really needed with the #else ASSERT(0); ? > > > f) It should be stated better in the man page that this feature depends > on a plug-in supporting OPENVPN_PLUGIN_TLS_FINAL. > > > -- > kind regards, > > David Sommerseth > 

As requested on the mailing list and in trac ticket #410, add an option to disable 'traditional' Diffie Hellman key exchange. People want to be able to create ecdh-only configurations. Also update the manpage to reflect the new behaviour, and while touching it change the text to motivate users towards a more secure configuration. Signed-off-by: Steffan Karger <st...@ka...> --- doc/openvpn.8 | 15 ++++++++++----- src/openvpn/options.c | 14 ++++++++++---- src/openvpn/ssl.c | 5 ++++- 3 files changed, 24 insertions(+), 10 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index f2911c0..0448d29 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -4238,13 +4238,18 @@ Not available with PolarSSL. File containing Diffie Hellman parameters in .pem format (required for .B \-\-tls-server -only). Use +only). -.B openssl dhparam -out dh1024.pem 1024 +Set +.B file=none +to disable Diffie Hellman key exchange (and use ECDH only). Note that this +requires peers to be using an SSL library that supports ECDH TLS cipher suites +(e.g. OpenSSL 1.0.1+, or PolarSSL 1.3+). -to generate your own, or use the existing dh1024.pem file -included with the OpenVPN distribution. Diffie Hellman parameters -may be considered public. +Use +.B openssl dhparam -out dh2048.pem 2048 +to generate 2048-bit DH parameters. Diffie Hellman parameters may be considered +public. .\"********************************************************* .TP .B \-\-ecdh-curve name diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 84eb6ed..92189a5 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -2149,10 +2149,6 @@ options_postprocess_verify_ce (const struct options *options, const struct conne (options->shared_secret_file != NULL) > 1) msg (M_USAGE, "specify only one of --tls-server, --tls-client, or --secret"); - if (options->tls_server) - { - notnull (options->dh_file, "DH file (--dh)"); - } if (options->tls_server || options->tls_client) { #ifdef ENABLE_PKCS11 @@ -2504,6 +2500,16 @@ options_postprocess_mutate (struct options *o) for (i = 0; i < o->connection_list->len; ++i)	options_postprocess_mutate_ce (o, o->connection_list->array[i]); +#ifdef ENABLE_SSL + if (o->tls_server) + { + /* Check that DH file is specified, or explicitly disabled */ + notnull (o->dh_file, "DH file (--dh)"); + if (streq (o->dh_file, "none")) +	o->dh_file = NULL; + } +#endif + #if ENABLE_MANAGEMENT if (o->http_proxy_override)	options_postprocess_http_proxy_override(o); diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c index 3ce1f60..34f02a7 100644 --- a/src/openvpn/ssl.c +++ b/src/openvpn/ssl.c @@ -483,7 +483,10 @@ init_ssl (const struct options *options, struct tls_root_ctx *new_ctx) if (options->tls_server) { tls_ctx_server_new(new_ctx); - tls_ctx_load_dh_params(new_ctx, options->dh_file, options->dh_file_inline); + + if (options->dh_file) +	tls_ctx_load_dh_params(new_ctx, options->dh_file, + options->dh_file_inline); } else	/* if client */ { -- 1.9.1 

On 20/08/14 23:00, Steffan Karger wrote: > Does not actually change behaviour, but fixes compiler warnings > and properly initializing is good habit anyway. > > Signed-off-by: Steffan Karger <st...@ka...> > --- > src/openvpn/plugin.c | 2 +- > src/openvpn/sig.c | 2 +- > src/openvpn/socket.c | 4 ++-- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/openvpn/plugin.c b/src/openvpn/plugin.c > index 0948f23..54c5b52 100644 > --- a/src/openvpn/plugin.c > +++ b/src/openvpn/plugin.c > @@ -291,7 +291,7 @@ plugin_init_item (struct plugin *p, const struct plugin_option *o) > static void > plugin_vlog (openvpn_plugin_log_flags_t flags, const char *name, const char *format, va_list arglist) > { > - unsigned int msg_flags; > + unsigned int msg_flags = 0; > > if (!format) > return; > diff --git a/src/openvpn/sig.c b/src/openvpn/sig.c > index 90e39a4..a3d29de 100644 > --- a/src/openvpn/sig.c > +++ b/src/openvpn/sig.c > @@ -126,7 +126,7 @@ print_signal (const struct signal_info *si, const char *title, int msglevel) > { > const char *type = (si->signal_text ? si->signal_text : ""); > const char *t = (title ? title : "process"); > - const char *hs; > + const char *hs = NULL; > switch (si->source) > { > case SIG_SOURCE_SOFT: > diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c > index 9e6bd10..c649d62 100644 > --- a/src/openvpn/socket.c > +++ b/src/openvpn/socket.c > @@ -2354,12 +2354,12 @@ print_sockaddr_ex (const struct sockaddr *sa, > struct gc_arena *gc) > { > struct buffer out = alloc_buf_gc (128, gc); > - bool addr_is_defined; > + bool addr_is_defined = false; > char hostaddr[NI_MAXHOST] = ""; > char servname[NI_MAXSERV] = ""; > int status; > > - socklen_t salen; > + socklen_t salen = 0; > switch(sa->sa_family) > { > case AF_INET: > ACK. Safe and sane changes. -- kind regards, David Sommerseth 

On 20/08/14 23:00, Steffan Karger wrote: > fixed warning: expression which evaluates to zero treated as a > null pointer constant of type 'struct addrinfo *' > > Seems to be innocent, but clang is correct that this is strange. > init_tun() expects two pointers, but options_string() tried to > feed it two uint32_t values. > > Signed-off-by: Steffan Karger <st...@ka...> > --- > src/openvpn/options.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/openvpn/options.c b/src/openvpn/options.c > index f536daa..84eb6ed 100644 > --- a/src/openvpn/options.c > +++ b/src/openvpn/options.c > @@ -2934,8 +2934,8 @@ options_string (const struct options *o, > o->ifconfig_ipv6_local, > o->ifconfig_ipv6_netbits, > o->ifconfig_ipv6_remote, > - (in_addr_t)0, > - (in_addr_t)0, > + NULL, > + NULL, > false, > NULL); > if (tt) ACK. -- kind regards, David Sommerseth 

On Tue, 2014-04-15 at 19:59 +0300, Samuli Seppänen wrote: > The driver has been tested on Windows 7 64-bit and it "seems to work > ok". If you test this driver please let me know if it works - or if it > does not. I've finally got round to testing this with OpenConnect, also under Windows 7 64-bit. It seems to be a little more pedantic about DeviceIoControl() calls, and needs both input and output buffers to be provided to all of them. So I needed to do this to make it work: http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/c499aec29 Other than that, though, it seems to be working for both IPv6 and Legacy IP. With IPv6 I can't ping the other end of the VPN tunnel because I seem to have a direct "on-link" route to that /64 network, rather than via fe80::8. But I suspect that's probably a vpnc-script issue and not your fault. -- dwmw2 

fixed warning: expression which evaluates to zero treated as a null pointer constant of type 'struct addrinfo *' Seems to be innocent, but clang is correct that this is strange. init_tun() expects two pointers, but options_string() tried to feed it two uint32_t values. Signed-off-by: Steffan Karger <st...@ka...> --- src/openvpn/options.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/openvpn/options.c b/src/openvpn/options.c index f536daa..84eb6ed 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -2934,8 +2934,8 @@ options_string (const struct options *o, o->ifconfig_ipv6_local, o->ifconfig_ipv6_netbits, o->ifconfig_ipv6_remote, - (in_addr_t)0, - (in_addr_t)0, + NULL, + NULL, false, NULL); if (tt) -- 1.9.1 

Does not actually change behaviour, but fixes compiler warnings and properly initializing is good habit anyway. Signed-off-by: Steffan Karger <st...@ka...> --- src/openvpn/plugin.c | 2 +- src/openvpn/sig.c | 2 +- src/openvpn/socket.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/openvpn/plugin.c b/src/openvpn/plugin.c index 0948f23..54c5b52 100644 --- a/src/openvpn/plugin.c +++ b/src/openvpn/plugin.c @@ -291,7 +291,7 @@ plugin_init_item (struct plugin *p, const struct plugin_option *o) static void plugin_vlog (openvpn_plugin_log_flags_t flags, const char *name, const char *format, va_list arglist) { - unsigned int msg_flags; + unsigned int msg_flags = 0; if (!format) return; diff --git a/src/openvpn/sig.c b/src/openvpn/sig.c index 90e39a4..a3d29de 100644 --- a/src/openvpn/sig.c +++ b/src/openvpn/sig.c @@ -126,7 +126,7 @@ print_signal (const struct signal_info *si, const char *title, int msglevel) { const char *type = (si->signal_text ? si->signal_text : ""); const char *t = (title ? title : "process"); - const char *hs; + const char *hs = NULL; switch (si->source) { case SIG_SOURCE_SOFT: diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c index 9e6bd10..c649d62 100644 --- a/src/openvpn/socket.c +++ b/src/openvpn/socket.c @@ -2354,12 +2354,12 @@ print_sockaddr_ex (const struct sockaddr *sa, struct gc_arena *gc) { struct buffer out = alloc_buf_gc (128, gc); - bool addr_is_defined; + bool addr_is_defined = false; char hostaddr[NI_MAXHOST] = ""; char servname[NI_MAXSERV] = ""; int status; - socklen_t salen; + socklen_t salen = 0; switch(sa->sa_family) { case AF_INET: -- 1.9.1 

when "some hacks work, some not" , it looks like assumtion that variables should be initialized with zero. have a look around, maybe youl'll find another uninitialized variable :-) 2014-08-20 13:32 GMT+06:00 Richard Weinberger <ric...@gm...>: > Hi! > > This bug exists for almost 14 months (!!) without a solution. > Some hacks work some not. > https://community.openvpn.net/openvpn/ticket/316 > > I really wonder why this issue is ignored by the OpenVPN developers. > > -- > Thanks, > //richard > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

we have a lot of users on Windows 8, no issue at all. well, I recall some issue (it was different than https://community.openvpn.net/openvpn/ticket/316) couple of early adopters installed Windows 8 preview, openvpn doesn't work on that windows edition (due to improper variable initialization within openvpn), I reported that bug (and even a patch applied), however, nobody agreed to include that patch. http://comments.gmane.org/gmane.network.openvpn.devel/8091 I couldn't find win 8.1 preview since than, it was removed from everywhere, but I confirm my patch helped our early adopters. the date of https://community.openvpn.net/openvpn/ticket/316 is somewhat like "win 8.1 preview", if you want to be really helpful, you can find which edition of windows was described there (or try 8.1 preview, for example). 2014-08-20 13:32 GMT+06:00 Richard Weinberger <ric...@gm...>: > Hi! > > This bug exists for almost 14 months (!!) without a solution. > Some hacks work some not. > https://community.openvpn.net/openvpn/ticket/316 > > I really wonder why this issue is ignored by the OpenVPN developers. > > -- > Thanks, > //richard > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Hi, On Wed, Aug 20, 2014 at 01:06:00PM +0200, David Sommerseth wrote: > What I'm trying to say is that we need more people who understands > coding to submit good patches with fixes, so that others can help review > or test them easily. Then you'll get a quicker turn-around on these > reports. Yes, please :-) Though I have to admit that our turn-around even for reviewing and commiting alone is not as good as it should be. Meh :-( 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... 

Hi, On Wed, Aug 20, 2014 at 11:49:18AM +0200, Richard Weinberger wrote: > Okay, let's come down a bit and have a cup of coffee first. Good plan :-) > I did not know about the new NDIS6 drivers. Now there is a comment mentioning it. Thanks for > that. This is all I wanted. So, yes, "we are working on it" (it was decided last year in Munich that this was needed, and OpenVPN Tech actually found someone who understands windows programming well enough to tackle this and paid him to do it). It seems to have some bugs left, though, so carefully test this before rolling out. 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... 

On 20/08/14 11:51, Richard Weinberger wrote: > > But if there is an issue with almost no reaction from developers > within 14 months > I begin to wonder WTF is going on. > A simple "We're working on it..." would not harm. Fair enough, and I can fully grasp this. But I'll give you a glimpse of the bigger perspective. There are now 3-5 active _community_ developers, and only one of them really plays with Windows. And almost none of them are paid to do OpenVPN. Then you have the users, and there are insanely many of them, Many of those finds bugs or issues and some of them actually do report them. Unfortunately the list of bugs just seems to increase, some with really important issues to fix. So what really happens is that when some of the community developers have some time to hack on OpenVPN, the attention is mostly given to the areas where they have issues too, or have promised to fix things. And if all that is done (which is quite seldom), we tend to look at the areas of the code base which we know best. However, if patches which fixes things arrives on the ML, then they do get reviewed at some point, especially if there are good descriptions of the patches and good test descriptions. When this happens, patches are accepted much quicker. If there's just a patch without much additional comments, the patch might linger for a long time unless some of the developers knows the code paths quite well. What I'm trying to say is that we need more people who understands coding to submit good patches with fixes, so that others can help review or test them easily. Then you'll get a quicker turn-around on these reports. And that is why we tend to be touchy when people complain too loud. But if you want to gain respect and get gratitude from the developers, sending patches is the very best cure. -- kind regards, David Sommerseth 

On Wed, Aug 20, 2014 at 11:29 AM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Wed, Aug 20, 2014 at 10:17:01AM +0200, Richard Weinberger wrote: >> On Wed, Aug 20, 2014 at 10:15 AM, Gert Doering <ge...@gr...> wrote: >> > On Wed, Aug 20, 2014 at 09:32:46AM +0200, Richard Weinberger wrote: >> >> This bug exists for almost 14 months (!!) without a solution. >> >> Some hacks work some not. >> >> https://community.openvpn.net/openvpn/ticket/316 >> >> >> >> I really wonder why this issue is ignored by the OpenVPN developers. >> > >> > We'll send you a refund for the money you've paid. >> >> Nice attempt to be funny. > > I wasn't trying to be funny. Complaining about "it's not happening fast > enough" with lots of expclamation marks about something you didn't pay > anything for isn't really motivating volunteers to spend their free time > on your issues. Okay, let's come down a bit and have a cup of coffee first. Sorry for being rude, this was not my intention. I don't expect people to solve problems for free and I'm well aware how free software development works. There is a good chance that you currently use free software where I did some work. But if there is an issue with almost no reaction from developers within 14 months I begin to wonder WTF is going on. A simple "We're working on it..." would not harm. >> > Seriously: because the amount of free time people can invest is limited, >> > and Windows RT isn't high on the personal pain list for one of the Community >> > developers. If it bothers you so much, take the source and fix the issue, >> > we're happy to review and merge the fixes. >> >> Windows RT != Windows 8. > > Last thing I saw in the ticket was about Windows RT on a tablet. > > OTOH, for regular Win 8, this has been fairly tricky to reproduce - I use > OpenVPN in a commercial environment with users on Win 8 and 8.1 (64bit), > and have received no single complaint from any of them. So it's not like > "it does not work on Win 8, period" but "something is different here". The original bug report came from we. I'm facing the issue on many Windows 8.x clients. > Plus, you nicely overlooked this bit here: > >> > OTOH, OpenVPN Tech *has* started tackling the issue and funded work for a >> > NDIS6 tap driver (which is more than "just recompile") - which nobody >> > tested for about half a year, so the remaining bugs have only been >> > uncovered recently when Samuli started to ship all the windows installers >> > "for Vista and up" with the NDIS6 driver by default. > > ... so, you might want to give this a try. I did not know about the new NDIS6 drivers. Now there is a comment mentioning it. Thanks for that. This is all I wanted. -- Thanks, //richard 

On 20/08/14 11:29, Gert Doering wrote: > Hi, > > On Wed, Aug 20, 2014 at 10:17:01AM +0200, Richard Weinberger wrote: >> On Wed, Aug 20, 2014 at 10:15 AM, Gert Doering <ge...@gr...> wrote: >>> On Wed, Aug 20, 2014 at 09:32:46AM +0200, Richard Weinberger wrote: >>>> This bug exists for almost 14 months (!!) without a solution. >>>> Some hacks work some not. >>>> https://community.openvpn.net/openvpn/ticket/316 >>>> >>>> I really wonder why this issue is ignored by the OpenVPN developers. >>> >>> We'll send you a refund for the money you've paid. >> >> Nice attempt to be funny. > > I wasn't trying to be funny. Complaining about "it's not happening fast > enough" with lots of expclamation marks about something you didn't pay > anything for isn't really motivating volunteers to spend their free time > on your issues. +1 ... And if it happens more times from the same e-mail address, I enable a mail filter sending mails from that address directly to /dev/null. If you want commercial quality support and follow-ups, please contact sa...@op... instead. -- kind regards, David Sommerseth 

Hi, On Wed, Aug 20, 2014 at 10:17:01AM +0200, Richard Weinberger wrote: > On Wed, Aug 20, 2014 at 10:15 AM, Gert Doering <ge...@gr...> wrote: > > On Wed, Aug 20, 2014 at 09:32:46AM +0200, Richard Weinberger wrote: > >> This bug exists for almost 14 months (!!) without a solution. > >> Some hacks work some not. > >> https://community.openvpn.net/openvpn/ticket/316 > >> > >> I really wonder why this issue is ignored by the OpenVPN developers. > > > > We'll send you a refund for the money you've paid. > > Nice attempt to be funny. I wasn't trying to be funny. Complaining about "it's not happening fast enough" with lots of expclamation marks about something you didn't pay anything for isn't really motivating volunteers to spend their free time on your issues. > > Seriously: because the amount of free time people can invest is limited, > > and Windows RT isn't high on the personal pain list for one of the Community > > developers. If it bothers you so much, take the source and fix the issue, > > we're happy to review and merge the fixes. > > Windows RT != Windows 8. Last thing I saw in the ticket was about Windows RT on a tablet. OTOH, for regular Win 8, this has been fairly tricky to reproduce - I use OpenVPN in a commercial environment with users on Win 8 and 8.1 (64bit), and have received no single complaint from any of them. So it's not like "it does not work on Win 8, period" but "something is different here". Plus, you nicely overlooked this bit here: > > OTOH, OpenVPN Tech *has* started tackling the issue and funded work for a > > NDIS6 tap driver (which is more than "just recompile") - which nobody > > tested for about half a year, so the remaining bugs have only been > > uncovered recently when Samuli started to ship all the windows installers > > "for Vista and up" with the NDIS6 driver by default. ... so, you might want to give this a try. 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... 

On Wed, Aug 20, 2014 at 10:15 AM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Wed, Aug 20, 2014 at 09:32:46AM +0200, Richard Weinberger wrote: >> This bug exists for almost 14 months (!!) without a solution. >> Some hacks work some not. >> https://community.openvpn.net/openvpn/ticket/316 >> >> I really wonder why this issue is ignored by the OpenVPN developers. > > We'll send you a refund for the money you've paid. Nice attempt to be funny. > Seriously: because the amount of free time people can invest is limited, > and Windows RT isn't high on the personal pain list for one of the Community > developers. If it bothers you so much, take the source and fix the issue, > we're happy to review and merge the fixes. Windows RT != Windows 8. > OTOH, OpenVPN Tech *has* started tackling the issue and funded work for a > NDIS6 tap driver (which is more than "just recompile") - which nobody > tested for about half a year, so the remaining bugs have only been > uncovered recently when Samuli started to ship all the windows installers > "for Vista and up" with the NDIS6 driver by default. > > 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... -- Thanks, //richard 

Hi, On Wed, Aug 20, 2014 at 09:32:46AM +0200, Richard Weinberger wrote: > This bug exists for almost 14 months (!!) without a solution. > Some hacks work some not. > https://community.openvpn.net/openvpn/ticket/316 > > I really wonder why this issue is ignored by the OpenVPN developers. We'll send you a refund for the money you've paid. Seriously: because the amount of free time people can invest is limited, and Windows RT isn't high on the personal pain list for one of the Community developers. If it bothers you so much, take the source and fix the issue, we're happy to review and merge the fixes. OTOH, OpenVPN Tech *has* started tackling the issue and funded work for a NDIS6 tap driver (which is more than "just recompile") - which nobody tested for about half a year, so the remaining bugs have only been uncovered recently when Samuli started to ship all the windows installers "for Vista and up" with the NDIS6 driver by default. 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... 

Hi! This bug exists for almost 14 months (!!) without a solution. Some hacks work some not. https://community.openvpn.net/openvpn/ticket/316 I really wonder why this issue is ignored by the OpenVPN developers. -- Thanks, //richard 

No functional changes, just add missing includes and make casts explicit. Signed-off-by: Steffan Karger <st...@ka...> --- src/openvpn/ssl_polarssl.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/src/openvpn/ssl_polarssl.c b/src/openvpn/ssl_polarssl.c index ddccf1d..62c110b 100644 --- a/src/openvpn/ssl_polarssl.c +++ b/src/openvpn/ssl_polarssl.c @@ -40,6 +40,7 @@ #include "errlevel.h" #include "ssl_backend.h" +#include "base64.h" #include "buffer.h" #include "misc.h" #include "manage.h" @@ -49,8 +50,10 @@ #include "ssl_verify_polarssl.h" #include <polarssl/error.h> +#include <polarssl/oid.h> #include <polarssl/pem.h> #include <polarssl/sha256.h> +#include <polarssl/version.h> void tls_init_lib() @@ -210,12 +213,13 @@ tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers) void tls_ctx_load_dh_params (struct tls_root_ctx *ctx, const char *dh_file, - const char *dh_file_inline + const char *dh_inline ) { - if (!strcmp (dh_file, INLINE_FILE_TAG) && dh_file_inline) + if (!strcmp (dh_file, INLINE_FILE_TAG) && dh_inline) { - if (0 != dhm_parse_dhm(ctx->dhm_ctx, dh_file_inline, strlen(dh_file_inline))) + if (0 != dhm_parse_dhm(ctx->dhm_ctx, (const unsigned char *) dh_inline, + strlen(dh_inline)))	msg (M_FATAL, "Cannot read inline DH parameters"); } else @@ -257,15 +261,15 @@ tls_ctx_load_cryptoapi(struct tls_root_ctx *ctx, const char *cryptoapi_cert) void tls_ctx_load_cert_file (struct tls_root_ctx *ctx, const char *cert_file, - const char *cert_file_inline + const char *cert_inline ) { ASSERT(NULL != ctx); - if (!strcmp (cert_file, INLINE_FILE_TAG) && cert_file_inline) + if (!strcmp (cert_file, INLINE_FILE_TAG) && cert_inline) { - if (0 != x509_crt_parse(ctx->crt_chain, cert_file_inline, - strlen(cert_file_inline))) + if (0 != x509_crt_parse(ctx->crt_chain, + (const unsigned char *) cert_inline, strlen(cert_inline))) msg (M_FATAL, "Cannot load inline certificate file"); } else @@ -282,16 +286,16 @@ tls_ctx_load_cert_file (struct tls_root_ctx *ctx, const char *cert_file, int tls_ctx_load_priv_file (struct tls_root_ctx *ctx, const char *priv_key_file, - const char *priv_key_file_inline + const char *priv_key_inline ) { int status; ASSERT(NULL != ctx); - if (!strcmp (priv_key_file, INLINE_FILE_TAG) && priv_key_file_inline) + if (!strcmp (priv_key_file, INLINE_FILE_TAG) && priv_key_inline) { status = pk_parse_key(ctx->priv_key, - priv_key_file_inline, strlen(priv_key_file_inline), + (const unsigned char *) priv_key_inline, strlen(priv_key_inline), NULL, 0); if (POLARSSL_ERR_PEM_PASSWORD_REQUIRED == status) @@ -299,7 +303,7 @@ tls_ctx_load_priv_file (struct tls_root_ctx *ctx, const char *priv_key_file, char passbuf[512] = {0}; pem_password_callback(passbuf, 512, 0, NULL); status = pk_parse_key(ctx->priv_key, - priv_key_file_inline, strlen(priv_key_file_inline), + (const unsigned char *) priv_key_inline, strlen(priv_key_inline), (unsigned char *) passbuf, strlen(passbuf));	} } -- 1.9.1 

Correctly handle CIDR masks when pushing clients addressing from an IPv6 pool. This change ignores the incorrectly used `bits` argument to the --ifconfig-ipv6-pool option. The code to save any provided CIDR mask after the pool IP is left in; this may someday become useful when we move to allow IPv6 pools without relying on an IPv4 pool assignment. Signed-off-by: Josh Cepek <jos...@us...> --- doc/openvpn.8 | 5 +---- src/openvpn/multi.c | 2 +- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index f2911c0..e9d8700 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -5533,10 +5533,7 @@ Is only accepted if ``--mode server'' or ``--server'' is set. Specify an IPv6 address pool for dynamic assignment to clients. The pool starts at .B ipv6addr -and increments by +1 for every new client (linear mode). The -.B /bits -setting controls the size of the pool. Due to implementation details, -the pool size must be between /64 and /112. +and matches the offset determined from the start of the IPv4 pool. .TP .B --ifconfig-ipv6-push ipv6addr/bits ipv6remote for ccd/ per-client static IPv6 interface configuration, see diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c index 5910154..b725d1b 100644 --- a/src/openvpn/multi.c +++ b/src/openvpn/multi.c @@ -1361,7 +1361,7 @@ multi_select_virtual_addr (struct multi_context *m, struct multi_instance *mi) mi->context.c2.push_ifconfig_ipv6_remote = mi->context.c1.tuntap->local_ipv6; mi->context.c2.push_ifconfig_ipv6_netbits = - mi->context.options.ifconfig_ipv6_pool_netbits; + mi->context.options.ifconfig_ipv6_netbits; mi->context.c2.push_ifconfig_ipv6_defined = true; }	} -- 1.9.1 

First, an overview of IPv6 pool and CIDR handling. The handling of the --ifconfig-ipv6-pool `bits` CIDR netmask value seems to need adjustment. Today, if this value does not exactly match the same CIDR mask applied to --ifconfig-ipv6, clients connectivity breaks in odd ways. I am proposing that we update the behavior to effectively ignore this value, remove the documentation references to the problematic `bits` setting, and use the server's own CIDR mask to use when pushing to clients. An anti-climatic patch to do this will be sent as a reply, and is backwards-compatible with existing configurations because the CIDR mask will be accepted and ignored. In short, clients should be pushed the CIDR mask of the server, not the mask of the pool size. This is how IPv4 works (a pool using 128 IPs does not mean we push a /25, but we still push the /24 used by the server.) The pool need to be independent of the actual CIDR mask assigned to the VPN network. Until the code can handle IPv6 pools of a smaller size and correctly refuse to use IPs outside the pool range, it is best to not offer v6 pool size selection at all. So what's the problem? The manpage says the `bits` value to the v6 pool controls the size of the pool, which we would get in IPv4 by controlling the start/stop values. However, this value actually has nothing to do with the pool size, and only the initial IP is used meaningfully. When a client connects, the multi_select_virtual_addr() function is responsible for picking IPs for the client, based on either --ifconfig-push values, or the pool (and their v6 equivalents.) This function in turn calls ifconfig_pool_acquire(), which finds the first free IPv4 IP in the pool using ifconfig_pool_find(). However, the IPv6 pool selection happens in add_in6_addr(). This function simply counts forward from the initial IPv6 pool IP to an offset determined by the IPv4 pool IP selected. This has a few ramifications, first of which is that the `bits` value to the --ifconfig-ipv6-pool has no relation to the IPv6 pool size. The IPv6 pool size is dependent on the largest offset from the start of the IPv4 pool. At the very least this makes the manpage description misleading. The situation gets stranger when you have configs that attempt to use a specific "size" IPv6 pool that varies from the server's configured CIDR mask. And now, some examples of problematic configs. In case #1, the server uses a /64 with a v6 pool size of /112. The client can successfully ping the server, but not clients issued an IP (perhaps by --ifconfig-ipv6-push) outside of this /112, even though the entire /64 should be reachable through the server. This is because the client is incorrectly pushed a CIDR mask of /112 when that value should have only defined the size of the v6 pool. Case #2 is nearly the same as #1, except the /112 used for the pool is not in the same /112, but still within the server's /64. This has the effect of preventing the client from pinging even the server itself as the client is told to configure its tun device on a /112 while the server is not in that /112. More ugly side-effects happen in case #3 where the server is configured with ifconfig-ipv6 with a server CIDR mask of /122 (we'll come back to this value in a moment.) However, the smallest allowed v6 pool is /112, causing clients to think the tun link contains many more IPs than it really does, and the client will incorrectly route things not on the VPN network across the VPN. Case #3 gets even worse in net30 mode for IPv4, where the 63rd VPN client to connect (which would normally be given 10.8.0.252/30) will consume the "252nd" IPv6 IP past the start of the pool. However, a /122 only has 64 IPs, which should normally be enough to account for the 63 clients allowed by the v4 pool. Because of how add_in6_addr() works, the 63rd client attempts to consume the 252nd IP past the start of a pool that cannot handle it, and is in fact off the server's IPv6 subnet. This is the case even if the pool is configured to handle CIDR masks as small as a /124 (smallest allowed by --ifconfig-ipv6.) 

Hi, On Fri, Aug 15, 2014 at 02:00:38PM -0500, Micah Robert wrote: > Also, Norton shows 3 of the 4 files to be only 8 days old and 1 to be only > 7 days old. That sounds plausible, as Samuli did a re-spin with a new openssl version some time last week... 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... 

Sorry to have bothered all of you. The problem was in the GnuPG GUI. The signatures checks out fine using command prompt. On Fri, Aug 15, 2014 at 2:00 PM, Micah Robert <mar...@gm...> wrote: > The GnuPG signatures for all 4 of the windows downloads from < > https://openvpn.net/index.php/open-source/downloads.html> show as bad > when verified against the signature downloads from < > https://openvpn.net/index.php/open-source/documentation/sig.html>. > > Also, Norton shows 3 of the 4 files to be only 8 days old and 1 to be only > 7 days old. > > Sincerely, > Micah Robert > 

The GnuPG signatures for all 4 of the windows downloads from < https://openvpn.net/index.php/open-source/downloads.html> show as bad when verified against the signature downloads from < https://openvpn.net/index.php/open-source/documentation/sig.html>. Also, Norton shows 3 of the 4 files to be only 8 days old and 1 to be only 7 days old. Sincerely, Micah Robert 

Hi, On Thu, Aug 14, 2014 at 08:00:38AM +0000, Lev Stipakov wrote: > I have analyzed OpenVPN code with Coverity and I could not explain > some resource leaks Coverity has found. > > 1) https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/options.c#L4378 > > char * ipv6_local; > VERIFY_PERMISSION (OPT_P_UP); > if ( get_ipv6_addr( p[1], NULL, &netbits, &ipv6_local, msglevel ) && > ipv6_addr_safe( p[2] ) ) { > if ( netbits < 64 || netbits > 124 ) { > msg( msglevel, "ifconfig-ipv6: /netbits must be between 64 and > 124, not '/%d'", netbits ); > goto err; > } > > Coverity claims that "err" branch leaks "ipv6_local". I looked into > "get_ipv6_addr" implementation and noticed that it does not pass any > "gc" to subsequent string_alloc call. To my understanding, in this > case caller is responsible for cleaning up, which is not the case for > "err" branch. This might well be true, but since "err" leads to "program ends, resources reclaimed" under most conditions, it's not a fairly serious leak... I'll still put it on my list for fixing. > 2) https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/proxy.c#L863 > > char *pa = NULL; > const int method = get_proxy_authenticate(sd, p->options.timeout, &pa, > NULL, signal_received); > if (method != HTTP_AUTH_NONE) { > if (pa) > msg (D_PROXY, "HTTP proxy authenticate '%s'", pa); > if (p->options.auth_retry == PAR_NCT && method == HTTP_AUTH_BASIC) { > msg (D_PROXY, "HTTP proxy: support for basic auth and other > cleartext proxy auth methods is disabled"); > goto error; > } > > Coverity claims that "error" branch leaks "pa". Same pattern as above, > "get_proxy_authenticate" passes NULL (4th parameter) as "gc" to > "string_alloc". > > Do those issues look like problems? Does it make sense to submit a > patch fixing those? Again, I don't think it's a serious issue - but still, not having leaks is good practice, so a patch adding the appropriate free() calls would be welcome :-) 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...