[Openvpn-devel] [PATCH applied] Re: Quote the domain name argument passed to the wmic command

2021-02-23 Thread Gert Doering
Acked-by: Gert Doering 

>From reading the ticket, this seems like a necessary change.  I have not
tested this, just looked at the code change, which is trivial enough.

Your patch has been applied to the master and release/2.5 branch.

commit 3338f2d5a2b7f12f314cc53bf0eaa44ba4f2e58c (master)
commit 2c8ef6fd2abbaef2e8c458690be545c171e11afe (release/2.5)
Author: Selva Nair
Date:   Tue Feb 16 19:04:35 2021 -0500

 Quote the domain name argument passed to the wmic command

 Signed-off-by: Selva Nair 
 Acked-by: Gert Doering 
 Message-Id: <1613520275-28637-1-git-send-email-selva.n...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21570.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v3] Allow running a default configuration with TLS libraries without BF-CBC

2021-02-16 Thread Gert Doering
Hi,

On Mon, Feb 15, 2021 at 03:31:46PM +0100, Arne Schwabe wrote:
> Modern TLS libraries might drop Blowfish by default or distributions
> might disable Blowfish in OpenSSL/mbed TLS. We still signal OCC
> options with BF-CBC compatible strings. To avoid requiring BF-CBC
> for this, special this one usage of BF-CBC enough to avoid a hard
> requirement on Blowfish in the default configuration.
> 
> Signed-off-by: Arne Schwabe 
> 
> Patch v2: add more clarifying comment, do not warn about OCC only insecure
>   ciphers, code improvements
> 
> Patch V3: Put ciphername resolution via ciper_kt_name in the right branch

This still fails one of my test cases - but only one (v2 failed two).

The test case is "udp / p2mp tun, 2.4 server with --ncp-disable" (on
the server).

The client is called as 
   ... --dev tun --proto udp --data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC

(no --cipher setting) and logS

2021-02-16 20:04:51 --cipher is not set. Previous OpenVPN version defaulted to 
BF-CBC as fallback when cipher negotiation failed in this case. If you need 
this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration 
and/or add BF-CBC to --data-ciphers.
...
2021-02-16 20:04:53 PUSH: Received control message: 'PUSH_REPLY,route 
10.194.0.0255.255.0.0,route-ipv6 fd00:abcd:194::/48,tun-ipv6,route 
10.194.103.1,topology net30,ping 10,ping-restart 30,ifconfig-ipv6 
fd00:abcd:194:103::1000/64 fd00:abcd:194:103::1,ifconfig 10.194.103.6 
10.194.103.5,peer-id 0'
2021-02-16 20:04:53 Using peer cipher 'BF-CBC'

but something seems to get confused about things:

2021-02-16 20:04:53 Initialization Sequence Completed
2021-02-16 20:05:03 Bad LZO decompression header byte: 166


The server agrees on BF-CBC (same log, different time zone):

Feb 16 14:04:51 phillip tun-udp-p2mp-2.4-noncp[29923]: 2001:608:0:814::f000:11 
peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:BF-CBC
Feb 16 14:04:51 phillip tun-udp-p2mp-2.4-noncp[29923]: 2001:608:0:814::f000:11 
Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 bit key
Feb 16 14:04:51 phillip tun-udp-p2mp-2.4-noncp[29923]: 2001:608:0:814::f000:11 
Incoming Data Channel: Cipher 'BF-CBC' initialized with 128 bit key

but packets fail decryption:

Feb 16 14:04:53 phillip tun-udp-p2mp-2.4-noncp[29923]: 
cron2-gentoo.ov-amd64/2001:608:0:814::f000:11 Authenticate/Decrypt packet 
error: packet HMAC authentication failed
Feb 16 14:05:06 phillip syslogd: last message repeated 103 times


Noticeable fact in the client log: there is no "Data Channel: Cipher..."
line on the client, so maybe this is triggering a new corner case?


Notice 2: there is a test case talking to a 2.3 server *which succeeds*,
but that one has "--cipher BF-CBC".  So what fails seems to be "cipher
initialization for 'implicit BF-CBC'".

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 07/11] Refactor extract_var_peer_info into standalone function and add ssl_util.c

2021-02-14 Thread Gert Doering
Hi,

On Mon, Jan 25, 2021 at 01:56:24PM +0100, Arne Schwabe wrote:
> Our "natural" place for this function would be ssl.c but ssl.c has a lot of
> dependencies on all kinds of other compilation units so including ssl.c into
> unit tests is near impossible currently. Instead create a new file ssl_util.c
> that holds small utility functions like this one.
> 
> Patch v2: add newline add the end of sll_util.h and ssl_util.c

Even if it already got an ACK, I find the function could benefit from a 
v3... "if we refactor, go all the way"

- change to early-return

  if (!peer_info || ((var_start = strstr(peer_info, var)) == NULL))
  {
  return NULL;
  }

- possibly split the assignment-and-compare if() into easier to read

  const char *var_start = strstr(peer_info, var);
  if (!var_start)
  {
  return NULL;
  }

- half the function has been converted to "var" and "var_start", and
  the rest still talks "char *ncp_ciphers_peer"... wat? - maybe that
  should be "char *value" (and "var" should be "key"?) or something.

- the v2 hunk has a newline-at-end-of-file mishap in ssl.c

> index 14c8116f..f59b409f 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -4201,4 +4201,4 @@ void
>  ssl_clean_user_pass(void)
>  {
>  purge_user_pass(_user_pass, false);
> -}
> +}
> \ No newline at end of file

(this is a new "no newline"), while v2 fixes the other one).


On the plus side, I tested "make distcheck" on linux, and all the Makefile
bits and pieces are proper (we tend to break that for new C files...)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Add S_EXITCODE flag for openvpn_run_script to report exit code

2021-02-14 Thread Gert Doering
Your patch has been applied to the master branch.

Again, out of sequence, as this does not depend on 03/11 or 05/11.

Lightly tested and stared at the code a bit.  Added a line break before
a "{"...

commit 04876274b5059f4c27b1f481fd92ff5e8ab15f1c
Author: Arne Schwabe
Date:   Mon Jan 25 13:56:23 2021 +0100

 Add S_EXITCODE flag for openvpn_run_script to report exit code

 Signed-off-by: Arne Schwabe 
 Acked-by: Lev Stipakov 
 Message-Id: <20210125125628.30364-7-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21487.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Introduce management client state for AUTH_PENDING notifications

2021-02-14 Thread Gert Doering
Your patch has been applied to the master branch.

As this is not depending on 03/11, I've applied it out of sequence.

One typo fixed ("techhnically").  Test run on the client, unsurprisingly
no breakage - I have nothing that excercises the new code yet, but 
it still looks very reasonable :-)

commit b29f7dffc073ebd2a3b04eac5f7aee2edcf5da49
Author: Arne Schwabe
Date:   Mon Jan 25 13:56:21 2021 +0100

 Introduce management client state for AUTH_PENDING notifications

 Signed-off-by: Arne Schwabe 
 Acked-by: Lev Stipakov 
 Message-Id: <20210125125628.30364-5-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21498.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Implement client side handling of AUTH_PENDING message

2021-02-14 Thread Gert Doering
Your patch has been applied to the master branch.

I'm not sure I understand the code, though.  It receives the new timeout
from the server (that is easy), but then caps it by "hand_window", which
is never increased - so the maximum timeout stays at "60", unless increased
manually on the client.  Where am I misreading this?  Or is this a 
prerequisite for this functionality?

c->c2.push_request_timeout = ks->established + min_uint(max_timeout, 
server_timeout);

(or am I totally misunderstanding push_request_timeout, and this has
nothing to do with hand-window, except "it's using this as a default
value", but only for triggering re-sends, not for "final give up"?)

However, for my standard test cases, this does not break anything, and
the code looks reasonable.  So in it goes :)

commit 3f8fb2b2c1d664f421d36181846da89c4330c6cc
Author: Arne Schwabe
Date:   Mon Jan 25 13:56:19 2021 +0100

 Implement client side handling of AUTH_PENDING message

 Signed-off-by: Arne Schwabe 
 Acked-by: Lev Stipakov 
 Message-Id: <20210125125628.30364-3-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21491.html
     Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Allow running a default configuration with TLS libraries without BF-CBC

2021-02-14 Thread Gert Doering
Hi,

On Mon, Jan 25, 2021 at 01:43:30PM +0100, Arne Schwabe wrote:
> Modern TLS libraries might drop Blowfish by default or distributions
> might disable Blowfish in OpenSSL/mbed TLS. We still signal OCC
> options with BF-CBC compatible strings. To avoid requiring BF-CBC
> for this, special this one usage of BF-CBC enough to avoid a hard
> requirement on Blowfish in the default configuration.

I was about to merge this, based on Antonio's ACK, but this part of
the code confuses me:

> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index b81137cf..d52057cc 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -3836,18 +3856,32 @@ options_string(const struct options *o,
> + (TLS_SERVER == true)
> <= 1);
>  
> -init_key_type(, o->ciphername, o->authname, o->keysize, true,
> -  false);
> +/* Skip resolving BF-CBC to allow SSL libraries without BF-CBC
> + * to work here in the default configuration */
> +const char *ciphername = o->ciphername;
> +int keysize;
> +
> +if (strcmp(o->ciphername, "BF-CBC") == 0) {
> +init_key_type(, "none", o->authname, o->keysize, true,
> +  false);
> +ciphername = cipher_kt_name(kt.cipher);
> +keysize = 128;
> +}
> +else
> +{
> +init_key_type(, o->ciphername, o->authname, o->keysize, true,
> +  false);
> +keysize = kt.cipher_length * 8;
> +}
>  /* Only announce the cipher to our peer if we are willing to
>   * support it */
> -const char *ciphername = cipher_kt_name(kt.cipher);

So the old code always sends "cipher_kt_name(kt.cipher)".

The new code adds a special case handling for "BF-CBC", calling
init_key_type(none), but then does the "cipher_kt_name()" only for
the "BF-CBC/none" case, no more for the "all other ciphers".

This looks like the wrong way around - shouldn't it do the

> +ciphername = cipher_kt_name(kt.cipher);

for the "not BF-CBC" case, and "ciphername = o->cipher" for "only BF-CBC"?


Call me confused...

As a side note, it seems to fail two of my t_client test cases, 
namely "talking to a 2.3 server with --cipher BF-CBC" and "talking to 
a 2.4 server with --ncp-disable", so maybe that code needs some more 
discussion.  I have not investigated more into these failures, first 
want to understand what the code tries to do.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Check return values in md_ctx_init and hmac_ctx_init

2021-02-14 Thread Gert Doering
Your patch has been applied to the master branch.

Whitespace has been adjusted in a totally space-neutral way.  As
instructed by the master of whitespace distribution.

(On the patch itself: only compile-tested, but it seems to be "obviously
correct", according to the man pages)

commit 0714ed804e40f80b48a7571193d7e4d81d2bcd4b
Author: Arne Schwabe
Date:   Mon Feb 1 18:43:08 2021 +0100

 Check return values in md_ctx_init and hmac_ctx_init

 Signed-off-by: Arne Schwabe 
 Acked-by: Antonio Quartulli 
 Message-Id: <20210201174310.22153-2-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21546.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Explain structver usage in sample defer plugin.

2021-02-03 Thread Gert Doering
Your patch has been applied to the master, release/2.5 and release/2.4 branch.

I have taken the liberty of changing "structvar" to "structver" in the
Subject:

(As a side note, I do not think the structver check in openvpn_plugin_func_v3()
is really necessary - if "open_v3" succeeds, we already know which struct ver
openvpn uses...)

commit fdfbd4441c2225dc69431c57d18291e103c466cf (master)
commit 1f61f3f755a84ed9765da744c7b61a35f36c4d4b (release/2.5)
commit 5b17607ad593bc081dc35b2ed1d6b852786a0d23 (release/2.4)
Author: Greg Cox
Date:   Mon Feb 1 07:09:49 2021 +

 Explain structver usage in sample defer plugin.

 Acked-by: David Sommerseth 
 Message-Id: <1612163389-16421-1-git-send-email-g...@mozilla.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21540.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Add a warning for disabled DHCP media sense on Window

2021-02-01 Thread Gert Doering
Hi,

On Thu, Feb 13, 2020 at 03:53:04PM +0100, Arne Schwabe wrote:
> This on of the old patches that are still pending. It seems that the
> original submitter never replied. This is still something we want to
> merge or should we just "close" due to timeout? I am not too familiar
> with the DHCP problem to have a good opinion on that.

I am now going to close it.

This seems to be a fairly rare problem, and if "--dhcp-renew" fixes it
without extra code, this sounds like an acceptable solution.

If Jiri wants this to be merged, the process would be "re-send a v2,
rebased on current master, with the changes Selva suggested integrated".

(We do not do pull requests, so I have not looked, and will not look,
whether PR 97 has/had an updated patch already)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
     Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Change pull request timeout use a timeout rather than a number

2021-01-30 Thread Gert Doering
Your patch has been applied to the master branch.

Only very lightly tested.

Observation: it introduces "*session" and "*ks" to send_push_request() 
which might be needed by later patches on, but are not used by code 
in this patch yet.

commit 413580b6a41d7eefb35438701fc79a63e0344ced
Author: Arne Schwabe
Date:   Mon Jan 25 13:56:18 2021 +0100

 Change pull request timeout use a timeout rather than a number

 Signed-off-by: Arne Schwabe 
 Acked-by: Lev Stipakov 
 Message-Id: <20210125125628.30364-2-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21490.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Remove inetd support from OpenVPN

2021-01-30 Thread Gert Doering
Acked-by: Gert Doering 

stared-at-code (which is quite a lot of changes, some of which want "-w"), 
ran on the client and server test rigs (breaks --inetd mode, whoa, but 
everything else works :-) ).  Looks good!

Removal of --inetd has been pending for multiple months now (since before
the release of 2.5.0) and nobody has ever asked for it to stay - so, gone
it is, now.

Your patch has been applied to the master branch.

commit ce652e7d3865dcdebfdc9233d9f46dfbcc2a6e2b
Author: Arne Schwabe
Date:   Mon Dec 14 18:24:07 2020 +0100

 Remove inetd support from OpenVPN

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201214172407.30451-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21360.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: More explicit versioning compatibility in sample-plugins/defer/simple.c

2021-01-30 Thread Gert Doering
Your patch has been applied to the master, release/2.5 and release/2.4 branch.

Again, I have not tested beyond a test compile (but it looks good).

As a side note: my change to change the required v3structver to "5"
was too restrictive - there was a bit of confusion what got added when, and I 
thought this was necessary for logging.  But it isn't, "5" is "with base64", 
and "4" is "with secure_memzero()" - which we wanted for plugin-auth-pam,
and my code was copy-pasted from there...  according to openvpn-plugin.h,
logging has been there from "v3 api structver v1".

I do not think it's needed to fix that as 2.4, 2.5 and master all have "v5" 
and people really should not code new plugins on 2.3 or older openvpn 
deployments...

commit a385a3e8a28f2ce96c7ee0be8940b257765add5a (master)
commit ae5ca3ebf1cccae2f2d11a2ed6219c40be9cc4ea (release/2.5)
commit 86c674230d6334c1aa18f74acc7a9741a6c9683a (release/2.4)
Author: Greg Cox
Date:   Wed Jan 27 20:21:49 2021 +

 More explicit versioning compatibility in sample-plugins/defer/simple.c

 Acked-by: David Sommerseth 
 Message-Id: <1611778909-20630-2-git-send-email-g...@mozilla.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21508.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Update openvpn_plugin_func_v2 to _v3 in sample-plugins/defer/simple.c

2021-01-30 Thread Gert Doering
Your patch has been applied to the master, release/2.5 and release/2.4 branch.

I have not tested anything beyond "it still compiles", but this looks 
reasonable 
and has David's ACK.

commit 7d1361c18f38d6301b4d558578c73e74f6597927 (master)
commit 11aa1288ffc95877cd5686e19137b9abd6c374bb (release/2.5)
commit 5e7e41dc56d71cb7e414d53059149d9490f14a67 (release/2.4)
Author: Greg Cox
Date:   Wed Jan 27 20:21:48 2021 +

 Update openvpn_plugin_func_v2 to _v3 in sample-plugins/defer/simple.c

 Acked-by: David Sommerseth 
 Message-Id: <1611778909-20630-1-git-send-email-g...@mozilla.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21507.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] rfc: mingw and the interactive service code

2021-01-27 Thread Gert Doering
Hi,

On Wed, Jan 27, 2021 at 10:04:49PM -0500, Selva Nair wrote:
> I see two options:
> (i) force __USE_MINGW_ANSI_STDIO = 0 in configure.
> (ii) Change all stdio function calls to be compatible building with and
> without this macro defined. AFICT, the only change required would be to
> replace %s and %S by %ls and %hs in some places -- mostly in interactive
> service, one instance in tun.c
> 
> Any thoughts? I'm leaning towards option (ii).

configure-fiddling-with-#define tends to be a never-ending story, so
I second going for (ii) - if that is compatible with MSVC.  Lev?

And maybe we should write this down somewhere - "which format specifiers
are used, and why?" - style guide page?  or something else?

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Documentation fixes around openvpn_plugin_func_v3 in openvpn-plugin.h.in

2021-01-27 Thread Gert Doering
Your patch has been applied to the master, release/2.5 and release/2.4 branch.

(Thanks, David.  I thought it looked good, but you have worked with the plugin
API for much longer :-) ).

commit 595be121b60f8cee9d4816172a7f9a4987560641 (master)
commit c6013abe860e8c76e132e98458fef7122a1622c0 (release/2.5)
commit 21f60d052e5f841f0689a83122beba40792d71ea (release/2.4)
Author: Greg Cox
Date:   Sun Jan 24 23:46:13 2021 +

 Documentation fixes around openvpn_plugin_func_v3 in openvpn-plugin.h.in

 Acked-by: David Sommerseth 
 Message-Id: <1611531973-443-1-git-send-email-g...@mozilla.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21481.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Fix naming error in sample-plugins/defer/simple.c

2021-01-24 Thread Gert Doering
Acked-by: Gert Doering 

"That's what I get for copy-paste code reuse" :-)

Your patch has been applied to the master, release/2.5 and release/2.4 branch.

commit 2d7e1954cae51ff317de886cc6b6c2daab7b59ea (master)
commit fe8739da3135e3d21b657c23f3bddcb7e5b3f9f3 (release/2.5)
commit 75a7d795acba972cd8b96dc44a5ba1970373226f (release/2.4)
Author: Greg Cox
Date:   Mon Jan 25 07:15:57 2021 +

 Fix naming error in sample-plugins/defer/simple.c

 Acked-by: Gert Doering 
 Message-Id: <1611558957-2958-1-git-send-email-g...@mozilla.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21482.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/1] Exit management interface loop early on receiving 'remote MOD' message.

2021-01-23 Thread Gert Doering
Hi,

On Wed, Jul 03, 2019 at 03:50:41PM +0100, Daniel Kaldor wrote:
> OpenVPN using management interface and running with
> 'management-query-remote' in the config will wait for a 'remote MOD'
> or 'remote ACCEPT' message before continuing with connection.
> 
> Logs indicate that this stage of the connection process currently
> takes ~1s to complete.
> This seems to be because the management interface polling loop is
> being run once unnecessarily after receiving 'remote MOD' message, and
> is only exiting after 1s timeout is reached on final polling loop.
> 
> This change exits the polling loop early, immediately after receiving
> 'remote MOD' message and removes 1s delay in connection.

This might actually have been fixed by 

commit d08b66f39cf80733a51e1607386dc4993faef09f
Author: Vladislav Grishenko 
Date:   Fri Oct 2 03:53:19 2020 +0500

Speedup TCP remote hosts connections

For non-blocking TCP/Unix connection, OpenVPN checks was it established in
loop and if not - sleeps or handles management for next one second. Since
the first check is made right after the connection attempt, it will likely
be always unsuccessful, causing redundant wait for one or more seconds:
...
v3: teach management_sleep() to handle zero timeout and reject negative
use 1s timeout for connection and 0s timeout for management events


could you check if this solves the delays you are experiencing as well?

If not, please re-send, taking Arne's comments into account.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: clean up / rewrite sample-plugins/defer/simple.c

2021-01-23 Thread Gert Doering
Patch has been applied to the master, release/2.5 and release/2.4 branch.

I have fixed the whitespace issue pointed out by Arne, and a few others
that uncrustify wanted fixed (a few TABs have escaped, and one bracked
was misaligned).

commit 452e016cba977cb1c109e74977029b9c0de33de2 (master)
commit 436a4cdd06ecdbab5ef73556431af776a984ad66 (release/2.5)
commit 8007a8a347336fded2f71d84945bbf3e60e58a78 (release/2.4)
Author: Gert Doering
Date:   Thu Jan 21 18:25:36 2021 +0100

 clean up / rewrite sample-plugins/defer/simple.c

 Signed-off-by: Gert Doering 
 Acked-by: Arne Schwabe 
 Message-Id: <20210121172536.32500-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21466.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Make OPENVPN_PLUGIN_ENABLE_PF failures FATAL

2021-01-23 Thread Gert Doering
Hi,

(while technically in the wrong mail thread for the "should PF stay?" 
discussion, this is still interesting)

On Fri, Jan 22, 2021 at 07:39:31AM +, tincanteksup wrote:
> I agree that a VPN should focus on its task and not try to be a firewall.
> 
> I do use the PF plugin but it is of little, if any, actual use, which is 
> not handled better elsewhere.

Which PF plugin do you use?  defer/simple?  Or something else, which is
not a Big Gaping Security Hole?

> I do not pretend to understand the intricacies of the code but if 
> removing the packet filter plugin is relatively simple and clean then, 
> from a user point-of-view, it makes more sense to drop it. Less 
> complication overall.

If you look into the code for places where you find ENABLE_PF or PLUGIN_PF,
you can see that it really touches a LOT of places - and every single line
of code increases the chance that it breaks on future changes, unless
someone invests the time to write test rigs that test all these code
paths (which gets increasingly complex with some features).  

Even testing all the "how is a packet forwarded or not?" paths might not
have caught *this* problem, as it is basically the "I have enabled PF but
the PF initialization failed" corner case which is often overlooked when
building tests for "I have enabled PF and want to make sure PF works!"
case...


So, yes, ripping this out would make the code much simpler in some 
critical paths.  OTOH pf can do nice things you can't easily do with
a linux firewall, like "accept packets from this *other* client only,
identified by common_name" (without having to know the actual IP
address and subnets assigned to it).  This is nice.  But if it is not
used, it's more "theoretically nice" and still can get kicked...

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Make OPENVPN_PLUGIN_ENABLE_PF failures FATAL

2021-01-23 Thread Gert Doering
Patch has been applied to the master and release/2.5 branch.

release/2.4 has different code and does not fail, so does not need
the patch.

commit 6a0c51baaa4d2b329183601ec35d3d16f127519e (master)
commit cbbdcd4f97bb19e5be6c11cf94397b38e869a0ee (release/2.5)
Author: Gert Doering
Date:   Thu Jan 21 14:39:29 2021 +0100

 Make OPENVPN_PLUGIN_ENABLE_PF failures FATAL

 Signed-off-by: Gert Doering 
 Acked-by: Arne Schwabe 
 Message-Id: <20210121133929.20186-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21464.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Make OPENVPN_PLUGIN_ENABLE_PF failures FATAL

2021-01-23 Thread Gert Doering
Hi,

On Fri, Jan 22, 2021 at 08:02:42AM +0100, Arne Schwabe wrote:
> I agree to make this "fixed" in a way that doesn't involve refactoring
> of pf code that is later removed anyway. I don't think the refactoring
> early affects this. It has been probably broken even earlier.

So I got myself nerdsniped into understanding when and how this broke.

Tested v2.4.10, and that works nicely when ENABLE_PF fails - it logs a
warning, and that's it.  No instance restart, no crash.

The instance restart is introduced here:

commit 492e42d35f141346fe21b3e984ed1bd86e5aac40
Author: Steffan Karger 
Date:   Wed Nov 1 23:03:40 2017 +0100

pf: reject client if PF plugin is configured, but init fails

This changes the behavior for pf plugins: instead of just not initializing
the firewall rules and happily continuing, this now rejects the client in
the case of an (unlikely) failure to initialize the pf.

... which, back then, actually worked.  Sort of - it aborts the client
connection, but since it does so very early (before TLS_FINAL), the client
is never told, and times out eventually.

Sat Jan 23 12:45:48 2021 us=726018 2001:608:0:814::f000:21 PLUGIN_CALL: plugin 
function PLUGIN_ENABLE_PF failed with status 1: 
/home/gert/openvpn-pftest.git/sample/sample-plugins/defer/simple.so
Sat Jan 23 12:45:48 2021 us=726033 2001:608:0:814::f000:21 WARNING: failed to 
init PF plugin, rejecting client.


So, git bisect time... and that leads to

$ git bisect good
c252dcc073155567c1982611ec6f065342909287 is the first bad commit
commit c252dcc073155567c1982611ec6f065342909287
Author: Arne Schwabe 
Date:   Fri Jul 3 11:55:06 2020 +0200

Remove did_open_context, defined and connection_established_flag
...

which is somewhat nonobvious to me - but the call chain for the pf*context()
stuff is sufficiently "out of the norm" that it could very well be, changing
assumptions about "how do we know the state of a multi_instance" which 
work well for all well-behaved paths, but not for the pf stuff.


That said, I think a "proper" fix might be to move the pf_init_context()
call to "when the instance is fully initialized and TLS has succeeded"
(so we can proper shut down the instance again).  Somewhere close to the
other plugin calls like "client-connect", and fail "as they do", if
needed.

But I do not intend to do that, just write up thoughts for reference if 
we ever ask ourselves "what was the result of that investigation?" :-)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] clean up / rewrite sample-plugins/defer/simple.c

2021-01-21 Thread Gert Doering
If we ship something that we consider a form of documentation
"this is how to write an OpenVPN plugin" it should meet our standards
for secure and modern code.  This plugin did neither.

  - get rid of system() calls, especially those that enabled a
remote-root exploit if this code was used "as is"

  - change logging from printf() to OpenVPN's plugin_log()

  - this requires changing to openvpn_plugin_open_v3() to get
to the function pointers

  - change wacky "background and sleep in the shell call" to the
double-fork/waitpid model we use in plugins/auth-pam
(copy-paste code reuse)

  - OpenVPN 2.5 and later react badly to OPENVPN_PLUGIN_FUNC_ERROR
returns to OPENVPN_PLUGIN_ENABLE_PF calls (SIGSEGV crash), so
always return SUCCESS.  Only hook ENABLE_PF if that functionality
is actually requested ("setenv test_packet_filter NN").

  - change deeply-nested functions auth_user_pass_verify() and
tls_final() to use early-return style

  - actually make defered PF setup *work* with recent OpenVPNs
(pre-creating temp files broke this, so unlink() the pre-created
file in the ENABLE_PF hook, and re-create asyncronously later)

  - add lots of comments explaining why we do things this way

Security issue reported by "oxr463" on HackerOne.

Signed-off-by: Gert Doering 
---
 sample/sample-plugins/defer/simple.c | 357 ---
 1 file changed, 265 insertions(+), 92 deletions(-)

diff --git a/sample/sample-plugins/defer/simple.c 
b/sample/sample-plugins/defer/simple.c
index 64338b4a..7be1c0a0 100644
--- a/sample/sample-plugins/defer/simple.c
+++ b/sample/sample-plugins/defer/simple.c
@@ -54,13 +54,16 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include "openvpn-plugin.h"
 
-/* bool definitions */
-#define bool int
-#define true 1
-#define false 0
+/* Pointers to functions exported from openvpn */
+static plugin_log_t plugin_log = NULL;
 
 /*
  * Our context, where we keep our state.
@@ -76,6 +79,9 @@ struct plugin_per_client_context {
 bool generated_pf_file;
 };
 
+/* module name for plugin_log() */
+static char *MODULE = "defer/simple";
+
 /*
  * Given an environmental variable name, search
  * the envp array for its value, returning it
@@ -130,33 +136,46 @@ atoi_null0(const char *str)
 }
 }
 
-OPENVPN_EXPORT openvpn_plugin_handle_t
-openvpn_plugin_open_v1(unsigned int *type_mask, const char *argv[], const char 
*envp[])
+/* use v3 functions so we can use openvpn's logging and base64 etc. */
+OPENVPN_EXPORT int
+openvpn_plugin_open_v3(const int v3structver,
+   struct openvpn_plugin_args_open_in const *args,
+   struct openvpn_plugin_args_open_return *ret)
 {
+const char **envp = args->envp;   /* environment variables */
 struct plugin_context *context;
 
-printf("FUNC: openvpn_plugin_open_v1\n");
+/* Check API compatibility -- struct version 5 or higher needed */
+if (v3structver < 5)
+{
+fprintf(stderr, "sample-client-connect: this plugin is incompatible 
with the running version of OpenVPN\n");
+return OPENVPN_PLUGIN_FUNC_ERROR;
+}
+
+/* Save global pointers to functions exported from openvpn */
+plugin_log = args->callbacks->plugin_log;
+
+plugin_log(PLOG_NOTE, MODULE, "FUNC: openvpn_plugin_open_v3");
 
 /*
  * Allocate our context
  */
 context = (struct plugin_context *) calloc(1, sizeof(struct 
plugin_context));
-if (context == NULL)
+if (!context)
 {
-printf("PLUGIN: allocating memory for context failed\n");
-return NULL;
+goto error;
 }
 
 context->test_deferred_auth = atoi_null0(get_env("test_deferred_auth", 
envp));
-printf("TEST_DEFERRED_AUTH %d\n", context->test_deferred_auth);
+plugin_log(PLOG_NOTE, MODULE, "TEST_DEFERRED_AUTH %d", 
context->test_deferred_auth);
 
 context->test_packet_filter = atoi_null0(get_env("test_packet_filter", 
envp));
-printf("TEST_PACKET_FILTER %d\n", context->test_packet_filter);
+plugin_log(PLOG_NOTE, MODULE, "TEST_PACKET_FILTER %d", 
context->test_packet_filter);
 
 /*
  * Which callbacks to intercept.
  */
-*type_mask =
+ret->type_mask =
 OPENVPN_PLUGIN_MASK(OPENVPN_PLUGIN_UP)
 |OPENVPN_PLUGIN_MASK(OPENVPN_PLUGIN_DOWN)
 |OPENVPN_PLUGIN_MASK(OPENVPN_PLUGIN_ROUTE_UP)
@@ -166,90 +185,241 @@ openvpn_plugin_open_v1(unsigned int *type_mask, const 
char *argv[], const char *
 |OPENVPN_PLUGIN_MASK(OPENVPN_PLUGIN_CLIENT_CONNECT_V2)
 |OPENVPN_PLUGIN_MASK(OPENVPN_PLUGIN_CLIENT_DISCONNECT)
 |OPENVPN_PLUGIN_MASK(OPENVPN_PLUGIN_LEARN_ADDRESS)
-|OPENVPN_PLUGIN_MASK(OPENVPN_PLUGIN_TLS_FINAL)
-|OPENVPN_PLUGIN_

[Openvpn-devel] [PATCH] Make OPENVPN_PLUGIN_ENABLE_PF failures FATAL

2021-01-21 Thread Gert Doering
Without this patch, if openpn is using a plugin that provides
OPENVPN_PLUGIN_ENABLE_PF but then fails (returns OPENVPN_PLUGIN_FUNC_ERROR),
OpenVPN will crash on a NULL pointer reference.

The underlying cause is (likely) the refactoring work regarding
CAS_SUCCEEDED etc., and that nobody adjusted the pf.c code accordingly
(it tries to sent itself a SIGUSR1, which tries to tear down the
client MI instance, but since it is not fully set up yet at this
point, things explode).  Full details on the call chain in Trac...

Since we intend to remove pf in 2.6, but we still do not want OpenVPN
to ever SIGSEGV, change the requirements for the plugins to "MUST SUCCEED",
so if the plugin ENABLE_PF call fails, abort openvpn with a M_FATAL
message.

Trac: #1377

Signed-off-by: Gert Doering 
---
 src/openvpn/pf.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/pf.c b/src/openvpn/pf.c
index f9bbfb50..3f472ef4 100644
--- a/src/openvpn/pf.c
+++ b/src/openvpn/pf.c
@@ -639,8 +639,17 @@ pf_init_context(struct context *c)
 }
 if (!c->c2.pf.enabled)
 {
-msg(M_WARN, "WARNING: failed to init PF plugin, rejecting 
client.");
-register_signal(c, SIGUSR1, "plugin-pf-init-failed");
+/* At some point in openvpn history, this code just printed a
+ * warning and signalled itself (SIGUSR1, "plugin-pf-init-failed")
+ * to terminate the client instance.  This got broken at one of
+ * the client auth state refactorings (leading to SIGSEGV crashes)
+ * and due to "pf will be removed anyway" reasons the easiest way
+ * to prevent crashes is to REQUIRE that plugins succeed - so if
+ * the plugin fails, we cleanly abort OpenVPN
+ *
+ * see also: https://community.openvpn.net/openvpn/ticket/1377
+ */
+msg(M_FATAL, "FATAL: failed to init PF plugin, must succeed.");
 return;
 }
 }
-- 
2.26.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] HEADS UP: fate of the built-in packet filter (PF)

2021-01-21 Thread Gert Doering
Hi,

OpenVPN has a built-in packet filter, which has a couple of issues

 - it is IPv4 only (though IPv6 patches existed at some point, but nobody
   reviewed them, so they did not get merged)

 - it can only be configured by a plugin or the management interface
   (so actually *using* it is not very straightforward)

 - it is not tested in any automated way today

 - none of the core developers uses it, or knows any deployment where it
   is used - so if we break it, we might not even notice

   (this was actually what brought up the discussion today - if a plugin 
returns OPENVPN_PLUGIN_FUNC_ERROR on OPENVPN_PLUGIN_ENABLE_PF, openvpn
will crash with a NULL pointer access...)

 - not even OpenVPN AS, which usually uses "those interesting features that
   nobody else knows about" uses PF (compiles with --disable-pf)


Based on this, we consider ripping all the PF stuff *out* of OpenVPN
for the 2.6 release ("hopefully later this year").


This is your chance to speak up and tell us "I use OpenVPN pf for this
totally cool thing, and there is no way to do this with the firewalling
layer the operating system provides, because..." :-)

So - surprise us!

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Document common uses of 'echo' directive, re-enable logging for 'echo'.

2021-01-20 Thread Gert Doering
Patch has been applied to the master and release/2.5 branch.

Whitespace added as requested :-)

commit ef2405a6bf5e8159d2e51e45107bc280fd6d0bd3 (master)
commit 4008ce020526f950cb2055ba7e8f7ceb13e4 (release/2.5)
Author: Gert Doering
Date:   Mon Jan 18 17:28:50 2021 +0100

 Document common uses of 'echo' directive, re-enable logging for 'echo'.

 Signed-off-by: Gert Doering 
 Acked-by: Selva Nair 
 Message-Id: <20210118162850.24214-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21443.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Fix tls-auth mismatch OCC message when tls-cryptv2 is used.

2021-01-20 Thread Gert Doering
Your patch has been applied to the master and release/2.5 branch.

Thanks :-)

commit 15daa9886b64a8378a6c5d68f79076dc44095696 (master)
commit e1bcf8a4bf3986a25f3906abe213fc9cd171ea04 (release/2.5)
Author: Arne Schwabe
Date:   Fri Dec 11 13:59:57 2020 +0100

 Fix tls-auth mismatch OCC message when tls-cryptv2 is used.

 Signed-off-by: Arne Schwabe 
 Acked-by: Steffan Karger 
 Message-Id: <20201211125957.7764-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21358.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] HEADS UP: removing --inetd support in 2.6

2021-01-20 Thread Gert Doering
Hiya,

just so you have heard it: we're going to remove --inetd support from
OpenVPN for OpenVPN 2.6 - since we're assuming that this is hardly
used these days, and it complicates the code base quite a bit.

If you have a good use-case for --inetd that can not be solved otherwise, 

 ** NOW IS THE TIME **

to tell us.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Man page sections corrections

2021-01-19 Thread Gert Doering
Acked-by: Gert Doering 

Thanks.  Well spotted.

Your patch has been applied to the master and release/2.5 branch.

commit 3b1ded3902b051b3c25f6e77da834ecd1b9f7eca (master)
commit 9e2f1bf73aaf48a3a7baf0cda11ef1caf3c69baf (release/2.5)
Author: Richard Bonhomme
Date:   Tue Jan 19 21:56:17 2021 +

 Man page sections corrections

 Signed-off-by: Richard Bonhomme 
 Acked-by: Gert Doering 
 Message-Id: <20210119215617.116886-1-tincantek...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21451.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Man sections: typo (No patch)

2021-01-19 Thread Gert Doering
Hi,

On Tue, Jan 19, 2021 at 09:05:03PM +, tincanteksup wrote:
> Patchworks did not pick this up the way I expected.

"git send-email" adds more headers that helps patchwork differenciate
between "it is a mail that might contain a diff" and "it's a submitted
patch".

The last one looks good (and as #1563 in patchwork).  Will take it from there.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Skip DHCP renew with Wintun adapter

2021-01-18 Thread Gert Doering
Your patch has been applied to the master and release/2.5 branch.

I've not tested it in any way, but looked at "git show -w", and this
this makes it quite clear that the patch does not actually change
as much code as it looks like, just moves the whole "dhcp_masq_post"
code block into the "if (WINDOWS_DRIVER_TAP_WINDOWS6)" block - so,
for TAP6, nothing changes, and for wintun, the code is not reached.

commit e0e7625c6b15f85b81d4f11d02f3daf4f32f1200 (master)
commit b8f4ca323969c13b039f35e5792a35f3e903b28c (release/2.5)
Author: Domagoj Pensa
Date:   Tue Dec 15 18:30:04 2020 +0100

 Skip DHCP renew with Wintun adapter

 Acked-by: Lev Stipakov 
 Message-Id: <20201215173004.26170-1-doma...@pensa.hr>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21364.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Remove 1 second delay before running netsh

2021-01-18 Thread Gert Doering
Your patch has been applied to the master and releae/2.5 branch.

I have not tested it, not even test compiled - but if Lev says
it works, this is all we need :-)

(As a side note: this reduces the *retry* delay on an error from
5 seconds to 4 seconds now - which should not make any interesting
difference)

commit b1a8213ee3fe35a4617608ec7653e4dffea79207 (master)
commit e7641f9b53bb6075fe7be7d5e6d16378eabebabd (release/2.5)
Author: Domagoj Pensa
Date:   Thu Dec 24 12:59:10 2020 +0100

 Remove 1 second delay before running netsh

 Signed-off-by: Domagoj Pensa 
 Acked-by: Lev Stipakov 
 Message-Id: <20201224115910.10129-1-doma...@pensa.hr>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21405.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Clarify --block-ipv6 intent and direction.

2021-01-18 Thread Gert Doering
Patch has been applied to the master and release/2.5 branch.

The commit message has been fixed (option -> direction) as discussed.

commit 8a8ee283aa7a4b409a9dafc082a6c65b5539308b (master)
commit 490203e6a7594ed946fe3158a694f80be2c18c9c (release/2.5)
Author: Gert Doering
Date:   Fri Dec 25 17:42:14 2020 +0100

 Clarify --block-ipv6 intent and direction.

 Signed-off-by: Gert Doering 
 Acked-by: Richard Bonhomme 
 Message-Id: <20201225164214.22771-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21407.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v3] Document common uses of 'echo' directive, re-enable logging for 'echo'.

2021-01-18 Thread Gert Doering
The 'echo' command can be used to signal information to an OpenVPN
GUI driving the openvpn core via management interface.  Which commands
exists and their syntax has so far been mostly undocumented.

Condense the long and good discussion between Selva Nair and
Jonathan K. Bullard into doc/gui-notes.txt (initial draft from
Jonathan, comments from Selva and Arne), with a pointer added
to doc/management-notes.txt.

See:

https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/CAEsd45T%2Bd6FUJ9Po0KHwtHjfuL9Q2D-poG8yFtY45Qyh%2BtHjkg%40mail.gmail.com/#msg36136236

and

https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_jPThhvXTJAtzhqVUVOLPW1VGu6h2jQhVsHicY8P2WRqA%40mail.gmail.com/#msg36141193

for the details.

Re-enable logging of 'echo' statements, but only for the particular
class of messages starting with 'echo msg...'.

v2:
  incorporate feedback from Selva Nair, correct >ECHO examples

v3:
  add "msg*" support status for Windows GUI (11.22.0) and Android (Planned)

Signed-off-by: Gert Doering 
---
 doc/Makefile.am  |   2 +-
 doc/gui-notes.txt| 370 +++
 doc/management-notes.txt |  10 ++
 src/openvpn/options.c|  15 +-
 4 files changed, 389 insertions(+), 8 deletions(-)
 create mode 100644 doc/gui-notes.txt

diff --git a/doc/Makefile.am b/doc/Makefile.am
index df2f54a3..e411f5f9 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -15,7 +15,7 @@ MAINTAINERCLEANFILES = \
 SUBDIRS = doxygen
 
 dist_doc_DATA = \
-   management-notes.txt
+   management-notes.txt gui-notes.txt
 
 dist_noinst_DATA = \
README.plugins interactive-service-notes.rst \
diff --git a/doc/gui-notes.txt b/doc/gui-notes.txt
new file mode 100644
index ..08270f07
--- /dev/null
+++ b/doc/gui-notes.txt
@@ -0,0 +1,370 @@
+Management Interface "echo" protocol
+
+
+THIS IS A PRELIMINARY VERSION OF THIS DOCUMENT. ALL INFORMATION IN IT
+IS SUBJECT TO CHANGE.
+
+
+
+CONTENTS
+THE OPENVPN --ECHO OPTION
+ENVIRONMENT COMMAND
+MESSSAGE COMMANDS
+PASSWORD COMMANDS
+QUOTING
+COMMMAND DETAILS
+
+
+=
+THE OPENVPN --ECHO OPTION
+=
+
+The OpenVPN --echo option causes commands to be sent out through the
+management interface, typically to a Graphic User Interface (GUI) such
+as "OpenVPN for Android", "Tunnelblick" (for macOS), or "Windows
+OpenVPN GUI". It can be included in a configuration file or on a
+command line, or can be pushed from the server.
+
+This document describes the commands that can be sent and how they are
+interpreted by various GUIs.
+
+ * OpenVPN does not process the commands in an --echo option; it only
+sends them out through the management interface.
+
+ * "echo" commands are processed by the GUI if, as, when, and in the
+order they are received. If no GUI is present the processing of
+commands may be delayed, the commands may never be processed, or only
+some commands may be processed. (That can happen if OpenVPN discards
+commands because its buffer for the commands fills up.)
+
+ * There is no mechanism for the GUI to acknowledge the receipt,
+success, or failure of a command.
+
+ * "echo" commands are stored by OpenVPN (within limits, see the next
+point) and sent only when the GUI requests them through the management
+interface. "echo" commands in the configuration file or the command
+line are typically requested and processed at the start of a
+connection attempt. "echo" commands that are pushed by the server are
+also typically asked for at the start of a connection attempt but can
+be sent at any time. They are processed in the middle of a connection
+attempt or after a connection is established, as the "push" options
+are received by the client from the server.
+
+  * OpenVPN's storage for echo commands is limited in size, so a large
+number of commands or commands with long messages may require that
+some commands be removed from the storage. If that happens, some of
+the commands may not be sent through the management interface when a
+GUI does connect to it or asks for the "echo" commands.
+
+ * On SIGUSR1 and SIGHUP connection restarts, "echo" commands that
+were sent through the management interface and have been saved by
+OpenVPN are sent again and will be re-processed by the GUI. (The
+message commands include a mechanism for muting (skipping) duplicate
+messages, see MESSAGE COMMANDS, below.)
+
+ * OpenVPN limits the number of separate arguments in each line of a
+configuration file. Arguments may be quoted to work around this
+limitation, see QUOTING, below.
+
+ * OpenVPN limits the size of each "echo" command sent over the
+m

Re: [Openvpn-devel] [PATCH v2] Document common uses of 'echo' directive, re-enable logging for 'echo'.

2021-01-18 Thread Gert Doering
Hi,

On Mon, Jan 18, 2021 at 01:15:29PM +0100, Gert Doering wrote:
> v2:
>   incorporate feedback from Selva Nair, correct >ECHO examples

There will be a v3, as I just added "Android: Planned" to all the
msg stuff.

Selva, which GUI version will be "the one with msg support"?  So I can
have this fixed as well.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v2] Document common uses of 'echo' directive, re-enable logging for 'echo'.

2021-01-18 Thread Gert Doering
The 'echo' command can be used to signal information to an OpenVPN
GUI driving the openvpn core via management interface.  Which commands
exists and their syntax has so far been mostly undocumented.

Condense the long and good discussion between Selva Nair and
Jonathan K. Bullard into doc/gui-notes.txt (initial draft from
Jonathan, comments from Selva and Arne), with a pointer added
to doc/management-notes.txt.

See:

https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/CAEsd45T%2Bd6FUJ9Po0KHwtHjfuL9Q2D-poG8yFtY45Qyh%2BtHjkg%40mail.gmail.com/#msg36136236

and

https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_jPThhvXTJAtzhqVUVOLPW1VGu6h2jQhVsHicY8P2WRqA%40mail.gmail.com/#msg36141193

for the details.

Re-enable logging of 'echo' statements, but only for the particular
class of messages starting with 'echo msg...'.

v2:
  incorporate feedback from Selva Nair, correct >ECHO examples

Signed-off-by: Gert Doering 
---
 doc/Makefile.am  |   2 +-
 doc/gui-notes.txt| 366 +++
 doc/management-notes.txt |  10 ++
 src/openvpn/options.c|  15 +-
 4 files changed, 385 insertions(+), 8 deletions(-)
 create mode 100644 doc/gui-notes.txt

diff --git a/doc/Makefile.am b/doc/Makefile.am
index df2f54a3..e411f5f9 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -15,7 +15,7 @@ MAINTAINERCLEANFILES = \
 SUBDIRS = doxygen
 
 dist_doc_DATA = \
-   management-notes.txt
+   management-notes.txt gui-notes.txt
 
 dist_noinst_DATA = \
README.plugins interactive-service-notes.rst \
diff --git a/doc/gui-notes.txt b/doc/gui-notes.txt
new file mode 100644
index ..4d993484
--- /dev/null
+++ b/doc/gui-notes.txt
@@ -0,0 +1,366 @@
+Management Interface "echo" protocol
+
+
+THIS IS A PRELIMINARY VERSION OF THIS DOCUMENT. ALL INFORMATION IN IT
+IS SUBJECT TO CHANGE.
+
+
+
+CONTENTS
+THE OPENVPN --ECHO OPTION
+ENVIRONMENT COMMAND
+MESSSAGE COMMANDS
+PASSWORD COMMANDS
+QUOTING
+COMMMAND DETAILS
+
+
+=
+THE OPENVPN --ECHO OPTION
+=
+
+The OpenVPN --echo option causes commands to be sent out through the
+management interface, typically to a Graphic User Interface (GUI) such
+as "OpenVPN for Android", "Tunnelblick" (for macOS), or "Windows
+OpenVPN GUI". It can be included in a configuration file or on a
+command line, or can be pushed from the server.
+
+This document describes the commands that can be sent and how they are
+interpreted by various GUIs.
+
+ * OpenVPN does not process the commands in an --echo option; it only
+sends them out through the management interface.
+
+ * "echo" commands are processed by the GUI if, as, when, and in the
+order they are received. If no GUI is present the processing of
+commands may be delayed, the commands may never be processed, or only
+some commands may be processed. (That can happen if OpenVPN discards
+commands because its buffer for the commands fills up.)
+
+ * There is no mechanism for the GUI to acknowledge the receipt,
+success, or failure of a command.
+
+ * "echo" commands are stored by OpenVPN (within limits, see the next
+point) and sent only when the GUI requests them through the management
+interface. "echo" commands in the configuration file or the command
+line are typically requested and processed at the start of a
+connection attempt. "echo" commands that are pushed by the server are
+also typically asked for at the start of a connection attempt but can
+be sent at any time. They are processed in the middle of a connection
+attempt or after a connection is established, as the "push" options
+are received by the client from the server.
+
+  * OpenVPN's storage for echo commands is limited in size, so a large
+number of commands or commands with long messages may require that
+some commands be removed from the storage. If that happens, some of
+the commands may not be sent through the management interface when a
+GUI does connect to it or asks for the "echo" commands.
+
+ * On SIGUSR1 and SIGHUP connection restarts, "echo" commands that
+were sent through the management interface and have been saved by
+OpenVPN are sent again and will be re-processed by the GUI. (The
+message commands include a mechanism for muting (skipping) duplicate
+messages, see MESSAGE COMMANDS, below.)
+
+ * OpenVPN limits the number of separate arguments in each line of a
+configuration file. Arguments may be quoted to work around this
+limitation, see QUOTING, below.
+
+ * OpenVPN limits the size of each "echo" command sent over the
+management interface to 255 bytes, including overhead characters. To
+allow messages 

[Openvpn-devel] [PATCH applied] Re: Zero initialise msghdr prior to calling sendmesg

2021-01-18 Thread Gert Doering
I have adjusted the whitespace as requested by Antonio, and added your 
SoB-Line (as agreed on IRC).

Your patch has been applied to the master, and release/2.5 branch (bugfix).

I have not merged it to 2.4 - it would nicely fit, but since this is all
TARGET_ANDROID, and nobody builds the Android client with an old tree, this
would just be "repo commit noise".

commit aa58035a955a2ae7ffa2b93ca2c8d2c6e5472695 (master)
commit a65d39bfd27cf5612e55dd536dd189e1a62624c2 (release/2.5)
Author: Arne Schwabe
Date:   Tue Jan 5 14:17:58 2021 +0100

 Zero initialise msghdr prior to calling sendmesg

 Signed-off-by: Arne Schwabe 
 Acked-by: Antonio Quartulli 
 Message-Id: <20210105131758.20311-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21418.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-25 Thread Gert Doering
Hi,

On Sun, Dec 20, 2020 at 07:31:42PM -0500, Selva Nair wrote:
> Here is the link again.
> https://github.com/selvanair/openvpn-gui/releases/tag/v11-echo-msg
> I got no feedback then nor now.

I have stared at the code a bit, and it seems to make sense.  The part
"store a digest + timestamp, and avoid repeating the same message for
 hours" is a good idea.

I can see that "echo_msg_clear()" has a bool parameter to clear the
message history but I can not see a call with "true" - what did you 
have in mind?  A button to clear the messages history?  Or "if changing
to a different profile"?

I have not tested the binary.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-25 Thread Gert Doering
Hi,

On Sun, Dec 20, 2020 at 07:06:57PM +, Greg Cox wrote:
> So IMO, 1-2 are fundamental, 3-5 are
> wishlist/consideration/extensions/ideas, use or ignore as you see fit:
> * Make the ability for receiving messages on a client as described.
> Enabled by default, maybe selectively disable-able because someone will
> think it's spammy, but I'd almost suggest not allowing it.
> * Make the ability to send a user a message via management.  Enabled by
> default, maybe selectively disable-able as a safety mechanism / make
> someone "key the mic to speak."

These two can be done with the proposed "echo msg..." mechanism (and
suppressed with "pull-filter ignore echo" already today, and possibly
with buttons to-be-added in the GUIs).

> * Make the ability to 'wall' a message out to all connected users in one
> command, e.g. 'wall "server going down in 5 mins"' or something like that.

This is an interesting challenge.  Parts of openvpn client might assume 
that a PUSH_REPLY is only seen at initial or renegotion time, so sending
a message with the proposed mechanism ("PUSH_REPLY echo msg server shutdown")
might trigger surprising effects.

It might just work.

But it can not be triggered from the server via client-connect scripts/
files/plugins as those are gone.  Maybe it can be triggered from the
servers-side management interface.  Not sure.


> * Make the ability to 'post' a message for some amount of time, e.g.
> 'wallpost 60m "server going down at 1700"'  Sending a message gets someone
> who is connected now, but misses the user who connects 2m after I go
> through the list of users and I stop looking.  So, this would hang around
> and pop a message to everyone connected now, plus each new connection, for
> the next 60m.

This is something outside "openvpn core", more tied to your client-connect
scripts/plugins on the server.  Put messages with an expire date "somewhere"
(database, filesystem, ...) and on connect, find everything that is still
valid and generate 'push "echo msg..."' messages accordingly.

> * Add an option ala --[no-]use-expired-certs.  When true, proceed like you
> do today; when false, if certs are expired, have the client feed itself a
> message via this mechanism to popup that your certs are expired, so a user
> knows right away what's wrong.  It'd be a spammy option if it tried to tell
> you what to do, so I'm keeping the idea simple and generic.

Interesting idea :-) - not sure what to do about this one.  Since all
"major" GUIs already look at the log file, and present warnings in some
form to the user, maybe this is more a GUI task - if we warn about
"cert might be expired" AND then there is a AUTH_FAILED response, 
change that warning (or even "all warnings logged") into a popup window?

Related but slightly different problem.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-25 Thread Gert Doering
Hi,

On Fri, Dec 25, 2020 at 12:08:16PM -0500, Selva Nair wrote:
> I find it hard to imagine why everyone seems to be avoiding "echo" and
> trying to find alternatives.

Well, in the beginning of this thread, having all forgotten about the
previous thread (still puzzling me) I only had the nagging memory that
"nobody understands 'echo' but it does not do what I want".

Since then I have been converted to the One True Echo and agree with
you that *for this purpose* it's the approach that needs the least
changes to existing infrastructure, and will get the job done.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-25 Thread Gert Doering
Hi,

On Mon, Dec 21, 2020 at 12:22:20PM -0500, Selva Nair wrote:
> > I'm sure the thread is still sitting in my mailbox... will go looking for
> > it today.
> 
> For those who have lost the original threads:
> 
> https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/CAEsd45T%2Bd6FUJ9Po0KHwtHjfuL9Q2D-poG8yFtY45Qyh%2BtHjkg%40mail.gmail.com/#msg36136236
> 
> https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_jPThhvXTJAtzhqVUVOLPW1VGu6h2jQhVsHicY8P2WRqA%40mail.gmail.com/#msg36141193
> 
> That was in Nov-Dec 2017. Actually, I was also thinking of reviving this
> only the other day when intimating users about some updates came up..

Thanks for digging these up for me.  Very interesting read, this :-)

I have tried to shape this into a "v 0.1" patch which should hit the list
"right now", also in reply-to to your e-mail.  Comments and corrections
welcome, I'll whack this as long as needed.  It's in patch form, but 
basically a draft, inviting comments.


> Somehow such itches re-surface at the end of the year :)

Let's see if we can progress this a bit more :-)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
         Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Document common uses of 'echo' directive, re-enable logging for 'echo'.

2020-12-25 Thread Gert Doering
The 'echo' command can be used to signal information to an OpenVPN
GUI driving the openvpn core via management interface.  Which commands
exists and their syntax has so far been mostly undocumented.

Condense the long and good discussion between Selva Nair and
Jonathan K. Bullard into doc/gui-notes.txt (initial draft from
Jonathan, comments from Selva and Arne), with a pointer added
to doc/management-notes.txt.

See:

https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/CAEsd45T%2Bd6FUJ9Po0KHwtHjfuL9Q2D-poG8yFtY45Qyh%2BtHjkg%40mail.gmail.com/#msg36136236

and

https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_jPThhvXTJAtzhqVUVOLPW1VGu6h2jQhVsHicY8P2WRqA%40mail.gmail.com/#msg36141193

for the details.

Re-enable logging of 'echo' statements, but only for the particular
class of messages starting with 'echo msg...'.

Signed-off-by: Gert Doering 
---
 doc/Makefile.am  |   2 +-
 doc/gui-notes.txt| 363 +++
 doc/management-notes.txt |  10 ++
 src/openvpn/options.c|  15 +-
 4 files changed, 382 insertions(+), 8 deletions(-)
 create mode 100644 doc/gui-notes.txt

diff --git a/doc/Makefile.am b/doc/Makefile.am
index df2f54a3..e411f5f9 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -15,7 +15,7 @@ MAINTAINERCLEANFILES = \
 SUBDIRS = doxygen
 
 dist_doc_DATA = \
-   management-notes.txt
+   management-notes.txt gui-notes.txt
 
 dist_noinst_DATA = \
README.plugins interactive-service-notes.rst \
diff --git a/doc/gui-notes.txt b/doc/gui-notes.txt
new file mode 100644
index ..9715e8f6
--- /dev/null
+++ b/doc/gui-notes.txt
@@ -0,0 +1,363 @@
+Management Interface "echo" protocol
+
+
+THIS IS A PRELIMINARY VERSION OF THIS DOCUMENT. ALL INFORMATION IN IT
+IS SUBJECT TO CHANGE.
+
+
+
+CONTENTS
+THE OPENVPN --ECHO OPTION
+ENVIRONMENT COMMAND
+MESSSAGE COMMANDS
+PASSWORD COMMANDS
+QUOTING
+COMMMAND DETAILS
+
+
+=
+THE OPENVPN --ECHO OPTION
+=
+
+The OpenVPN --echo option causes commands to be sent out through the
+management interface, typically to a Graphic User Interface (GUI) such
+as "OpenVPN for Android", "Tunnelblick" (for macOS), or "Windows
+OpenVPN GUI". It can be included in a configuration file or on a
+command line, or can be pushed from the server.
+
+This document describes the commands that can be sent and how they are
+interpreted by various GUIs.
+
+ * OpenVPN does not process the commands in an --echo option; it only
+sends them out through the management interface.
+
+ * "echo" commands are processed by the GUI if, as, when, and in the
+order they are received. If no GUI is present the processing of
+commands may be delayed, the commands may never be processed, or only
+some commands may be processed. (That can happen if OpenVPN discards
+commands because its buffer for the commands fills up.)
+
+ * There is no mechanism for the GUI to acknowledge the receipt,
+success, or failure of a command.
+
+ * "echo" commands are stored by OpenVPN (within limits, see the next
+point) and sent only when the GUI requests them through the management
+interface. "echo" commands in the configuration file or the command
+line are typically requested and processed at the start of a
+connection attempt. "echo" commands that are pushed by the server are
+also typically asked for at the start of a connection attempt but can
+be sent at any time. They are processed in the middle of a connection
+attempt or after a connection is established, as the "push" options
+are received by the client from the server.
+
+  * OpenVPN's storage for echo commands is limited in size, so a large
+number of commands or commands with long messages may require that
+some commands be removed from the storage. If that happens, some of
+the commands may not be sent through the management interface when a
+GUI does connect to it or asks for the "echo" commands.
+
+ * On SIGUSR1 and SIGHUP connection restarts, "echo" commands that
+were sent through the management interface and have been saved by
+OpenVPN are sent again and will be re-processed by the GUI. (The
+message commands include a mechanism for muting (skipping) duplicate
+messages, see MESSAGE COMMANDS, below.)
+
+ * OpenVPN limits the number of separate arguments in each line of a
+configuration file. Arguments may be quoted to work around this
+limitation, see QUOTING, below.
+
+ * OpenVPN limits the size of each "echo" command sent over the
+management interface to 255 bytes, including overhead characters. To
+allow messages of arbitrary length, several message commands can be
+concatenated toget

[Openvpn-devel] [PATCH] Clarify --block-ipv6 intent and direction.

2020-12-25 Thread Gert Doering
--block-ipv6 is a fairly special-purpose option, and only blocks packet
in the client->server option.  This is implied by not ever mentioning
the other direction in the existing documentation, but not written down.

Make this explicit, avoid confusion.

Also, point why this option exist (avoid IPv6 leakage from dual-stacked
clients around IPv4-only VPN offerings).

Trac: #1351

Signed-off-by: Gert Doering 
---
 doc/man-sections/vpn-network-options.rst | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/man-sections/vpn-network-options.rst 
b/doc/man-sections/vpn-network-options.rst
index 26682789..711dfcc8 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -21,7 +21,8 @@ routing.
   For this option to make sense you actually have to route traffic to the
   tun interface. The following example config block would send all IPv6
   traffic to OpenVPN and answer all requests with no route to host,
-  effectively blocking IPv6.
+  effectively blocking IPv6 (to avoid IPv6 connections from dual-stacked
+  clients to leak around IPv4-only VPN services).
 
   **Client config**
 ::
@@ -38,6 +39,12 @@ routing.
--push "redirect-gateway ipv6"
--block-ipv6
 
+  Note: this option does not influence traffic sent from the server 
+  towards the client (neither on the server nor on the client side).
+  This is not seen as necessary, as such traffic can be most easily 
+  avoided by not configuring IPv6 on the server tun, or setting up a
+  server-side firewall rule.
+
 --dev device
   TUN/TAP virtual network device which can be :code:`tunX`, :code:`tapX`,
   :code:`null` or an arbitrary name string (:code:`X` can be omitted for
-- 
2.26.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Travis-ci is changing billing

2020-12-23 Thread Gert Doering
Hi,

On Wed, Dec 23, 2020 at 04:06:26PM +, tincanteksup wrote:
> This may help shed some light:
> 
> https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

I'm more confused than before.  So is what we do still free?  Do we
need to apply somewhere?

Do we do MacOS builds?  If yes, we might consider removing them (we
do have a MacOS buildslave)...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-21 Thread Gert Doering
Hi,

On Mon, Dec 21, 2020 at 06:24:36PM +, Greg Cox wrote:
> My contention is, a VPN client has enough information from its own certs to
> know when its certs are expired and thus not going to work (Yes, there's
> plenty of OTHER reasons a connection can fail, but in a well designed
> setup, the user's certs will go stale long before the server).  It tells
> you this problem in the logs, which folks never read.  

We consciously decided to make this not more prominent (so, warning only,
not error) because the client's machine's time might be wrong - and 
ultimately it's the server's notion of time that decides if the cert
is valid or not.  So this is a hint, but not a "IT WILL NOT WORK!" hard
error.

> If the software were
> to contain a mechanism to make certain failure cases automatically more
> prominent, particularly for 'simple' users who have GUI clients, it'll be a
> big win for supportability on larger installs.

This is indeed getting into philosophy... we do send different types of
AUTH_FAILED today (like, for token expired).  Maybe we could send an
"AUTH_FAILED,cert expired" and have the client display this?

(I admit that I'm neither an expert on AUTH_FAILED message, nor on
"what is the client doing on variations of it", nor on "what *should*
be the expected outcome?".  Selva, Arne will know more).

> And I realize this is getting into advocacy and away from what's right for
> a -devel list, so I'll stop here on this thread.

I find this a very useful exchange, and I would call it "on-topic on
openvpn-devel".  The openvpn-users list is more about "end user issues",
but what you and Max bring forward is "this is where openvpn could be 
more helpful for admins" - and we developers want to listen to that :-)

For me, openvpn usually does what I want (and if not, I start threads
like this one, and try to either code it myself or convince one of the
others that "we!" want to have this and they should code it :-) ) - but
since this is openvpn, there is a myriad other ways to use it which I
might have never thought about...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-20 Thread Gert Doering
Hi,

On Sun, Dec 20, 2020 at 07:31:42PM -0500, Selva Nair wrote:
> I thought we already went through this when we discussed the proposed "echo
> msg" in considerable detail 3 years ago.

Yeah, sorry.  Seems I got distracted and forgot all about the discussed
"solution space", and just remembered the itch.

I'm sure the thread is still sitting in my mailbox... will go looking for
it today.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-20 Thread Gert Doering
Hi,

On Sun, Dec 20, 2020 at 04:00:13PM +0100, Arne Schwabe wrote:
> > ... and the client would then either print this on the console
> > (if !management) or dump it to management, where the GUI/Tunnelblick
> > could pick it up and create a popup window.
> >
> See --echo.  That is basically what you desribe as info-msg in your mail

While echo sounds as if it would do what I want, it doesn't.

Echo is "something magic" - it is never printed by the 2.x client, it
is not even logged.  And it's not displayed by the GUIs either, but
instead it can be used to "do things"...

So less "echo to user" but "send this string to the management interface
and make the mgmt client do something magic"...

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
         Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Remove 1 second delay before running netsh

2020-12-20 Thread Gert Doering
Hi,

On Tue, Dec 15, 2020 at 06:39:50PM +0100, Domagoj Pensa wrote:
> When running various netsh commands before each 1 second sleep is added.
> As more netsh commands are run, especially for Wintun adapters, that can
> add to a noticable delayed connecting time.
> 
> This should be safe. No problems were found in tests and all netsh
> commands executed properly with delay removed. Also, no delays are used
> in a similar code in interactive service and netsh command executions
> are guarded with a semaphore.

This is... interesting.  The offending sleep(1) was added there by
james, 15 years ago, in commit a9c802b2a (imported from SVN)

That commit basically split the "sleep(5) after each try" into
"sleep(1) before and sleep(4) after", so possibly it was needed 
before the very first netsh call...

The change itself is not commented in the commit message, so we 
can only guess

commit a9c802b2a3f77f2b906e22f582681cdec0790c32
Author: James Yonan 
Date:   Thu Dec 22 18:09:40 2005 +

--ip-win32 adaptive is now the default.
--ip-win32 netsh (or --ip-win32 adaptive when in netsh
mode) can now set DNS/WINS addresses on the TAP-Win32
adapter.



Lev: do you have a particular opinion on this change?  You do more
testing with wintun...

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: ssl_common.h: fix 'not all control paths return a value' msvc warning

2020-12-20 Thread Gert Doering
Acked-by: Gert Doering 

Your patch has been applied to the master branch.

commit 86d7e9902db7fcbbbc31aaa5b69bee82375caa21
Author: Lev Stipakov
Date:   Fri Dec 18 00:48:34 2020 +0200

 ssl_common.h: fix 'not all control paths return a value' msvc warning

 Signed-off-by: Lev Stipakov 
 Acked-by: Gert Doering 
 Message-Id: <20201217224834.160-1-lstipa...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21373.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-20 Thread Gert Doering
Hi,

I find myself looking for a mechanism by which I could send informational
messages ("your cert expires in two weeks, go refresh!" - "your openvpn
client needs an upgrade") from the openvpn server to incoming clients.

Of course this should work with all connecting clients, that is, "text
clients", windows GUI, Tunnelblick, iOS Connect, Android.

As far as I am aware, there is no such mechanism today.

Do we want to make one?


From the server / openvpn core side, it could be something totally trivial:

  push "info-msg hey there!"

... and the client would then either print this on the console 
(if !management) or dump it to management, where the GUI/Tunnelblick
could pick it up and create a popup window.

What do you think?

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Fix too early argv freeing when registering DNS

2020-12-15 Thread Gert Doering
Thanks.  As already said, all of a sudden it is very obvious
why it is crashing here... somewhat annoying that this wasn't
noticed before 2.5.0 release, though.

I've stared-at-code, and tested this on Win10 (ubuntu 18 / mingw build)
with a config with --register-dns. Without the patch, crash, with the 
patch, it just works.

Testing is not fully straightforward, as you can not "just run" such 
a config, but you need to either run openvpn-gui as admin, or run 
openvpn from a admin-cmd.exe - and it never OOMs for me, just never
proceeeds after "ipconfig.exe /flushdns".

Thanks :-)

Your patch has been applied to the master and release/2.5 branch.

commit ab4688e3bd78d010ccc96adec66ab552bd009328 (master)
commit 2f2df474158b6c24325a47334fc8b5eb77a69b85 (release/2.5)
Author: Domagoj Pensa
Date:   Tue Dec 15 18:16:00 2020 +0100

 Fix too early argv freeing when registering DNS

 Signed-off-by: Domagoj Pensa 
 Acked-by: Gert Doering 
 Message-Id: <20201215171600.25534-1-doma...@pensa.hr>
 URL: 
https://www.mail-archive.com/search?l=mid=20201215171600.25534-1-doma...@pensa.hr
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix too early argv freeing when registering DNS

2020-12-15 Thread Gert Doering
Hi,

On Tue, Dec 15, 2020 at 06:16:00PM +0100, Domagoj Pensa wrote:
> When registering DNS on Windows, argv is freed after being used in first
> ipconfig command (/flushdns).
> 
> Then same argv is used uninitialized in next ipconfig command (/registerdns)
> causing heap exception and subprocess crash.
> 
> As a consequence second command is never executed and locked netcmd
> semaphore is not cleanly released.
> 
> Removing argv freeing between ipconfig calls solves the problem.

Oh!  Yes, now with your patch, this is very obvious - there is a trac
ticket (so when I merge this, I'll add the trac ticket number to the
commit message) but it sort of puzzled Selva and me, because the
code "looked sane".

Acked-by: g...@greenie.muc.de

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Fix line number reporting on config file errors after segments

2020-12-06 Thread Gert Doering
Patch has been applied to the master, release/2.5 and release/2.4 branch
(bugfix).  

Release/2.4 has the same code, but is missing one recent round of 
uncrustification, many conflicts due to different context and one
due to the new inline-file-handling.

Theoretically it could also be applied to release/2.3, but since it's not 
a really *important* bugfix (= nobody but me noticed in 10+ years), I've 
withstood the temptation.

I have adjusted the line break as instructed (creating two lines with 86 chars).

commit a686f7e29af012783371f401f394ac1e62e5b75f (master)
commit 97af8b3101af6a1f8fef778d2c9e0e5f13d2d440 (release/2.5)
commit 8ce5a319fd7a9b13ed6fee92fbda567c24f832c5 (release/2.4)
Author: Gert Doering
Date:   Sun Dec 6 13:57:11 2020 +0100

 Fix line number reporting on config file errors after  segments

 Acked-by: Antonio Quartulli 
 Message-Id: <20201206125711.12071-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21334.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v2] Fix line number reporting on config file errors after segments

2020-12-06 Thread Gert Doering
 segments neglected to increment the "current line number
in config file" variable (line_num), so after the first ,
errors reported have the wrong line number.

Fix by introducing an extra argument to read_inline_file() function:
"so many lines in the inline block", and changing the return values of
the "check_inline*()" functions to "int", changing this from "false/true"
to "0 = no inline, 1...N = inline with  lines".

On calling add_options() this is implicitly converted back to bool.

v2: use int return value, not extra call-by-reference parameter

Trac: #1325
---
 src/openvpn/options.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 21f8d494..d8a86560 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -4659,7 +4659,8 @@ in_src_get(const struct in_src *is, char *line, const int 
size)
 }
 
 static char *
-read_inline_file(struct in_src *is, const char *close_tag, struct gc_arena *gc)
+read_inline_file(struct in_src *is, const char *close_tag,
+ int *num_lines, struct gc_arena *gc)
 {
 char line[OPTION_LINE_SIZE];
 struct buffer buf = alloc_buf(8*OPTION_LINE_SIZE);
@@ -4668,6 +4669,7 @@ read_inline_file(struct in_src *is, const char 
*close_tag, struct gc_arena *gc)
 
 while (in_src_get(is, line, sizeof(line)))
 {
+(*num_lines)++;
 char *line_ptr = line;
 /* Remove leading spaces */
 while (isspace(*line_ptr))
@@ -4701,10 +4703,10 @@ read_inline_file(struct in_src *is, const char 
*close_tag, struct gc_arena *gc)
 return ret;
 }
 
-static bool
+static int
 check_inline_file(struct in_src *is, char *p[], struct gc_arena *gc)
 {
-bool is_inline = false;
+int num_inline_lines = 0;
 
 if (p[0] && !p[1])
 {
@@ -4717,16 +4719,15 @@ check_inline_file(struct in_src *is, char *p[], struct 
gc_arena *gc)
 p[0] = string_alloc(arg + 1, gc);
 close_tag = alloc_buf(strlen(p[0]) + 4);
 buf_printf(_tag, "", p[0]);
-p[1] = read_inline_file(is, BSTR(_tag), gc);
+p[1] = read_inline_file(is, BSTR(_tag), _inline_lines, 
gc);
 p[2] = NULL;
 free_buf(_tag);
-is_inline = true;
 }
 }
-return is_inline;
+return num_inline_lines;
 }
 
-static bool
+static int
 check_inline_file_via_fp(FILE *fp, char *p[], struct gc_arena *gc)
 {
 struct in_src is;
@@ -4735,7 +4736,7 @@ check_inline_file_via_fp(FILE *fp, char *p[], struct 
gc_arena *gc)
 return check_inline_file(, p, gc);
 }
 
-static bool
+static int
 check_inline_file_via_buf(struct buffer *multiline, char *p[],
   struct gc_arena *gc)
 {
@@ -4806,13 +4807,13 @@ read_config_file(struct options *options,
 }
 if (parse_line(line + offset, p, SIZE(p)-1, file, line_num, 
msglevel, >gc))
 {
-bool is_inline;
-
 bypass_doubledash([0]);
-is_inline = check_inline_file_via_fp(fp, p, >gc);
-add_option(options, p, is_inline, file, line_num, level,
+int lines_inline =
+check_inline_file_via_fp(fp, p, >gc);
+add_option(options, p, lines_inline, file, line_num, level,
msglevel, permission_mask, option_types_found,
es);
+line_num += lines_inline;
 }
 }
 if (fp != stdin)
@@ -4855,12 +4856,12 @@ read_config_string(const char *prefix,
 ++line_num;
 if (parse_line(line, p, SIZE(p)-1, prefix, line_num, msglevel, 
>gc))
 {
-bool is_inline;
-
 bypass_doubledash([0]);
-is_inline = check_inline_file_via_buf(, p, >gc);
-add_option(options, p, is_inline, prefix, line_num, 0, msglevel,
+int lines_inline =
+check_inline_file_via_buf(, p, >gc);
+add_option(options, p, lines_inline, prefix, line_num, 0, msglevel,
permission_mask, option_types_found, es);
+line_num += lines_inline;
 }
 CLEAR(p);
 }
-- 
2.26.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v9] Add DNS SRV remote host discovery support

2020-12-04 Thread Gert Doering
Hi,

On Mon, Nov 16, 2020 at 03:08:57AM +0500, Vladislav Grishenko wrote:
> DNS SRV remote host discovery allows to have multiple OpenVPN servers for
> a single domain w/o explicit profile enumeration, to move services from
> host to host with little fuss, and to designate hosts as primary servers
> for a service and others as backups.
> Feature has been asked several times already, should be useful in case of
> substantial number of clients & servers deployed.

So, Arne has ACKed it, and I went work on it today.  One problem showed
up on FreeBSD - the code uses EAI_NODATA, which is found in 
on FreeBSD, but with this comment:

#if 0
/* obsoleted */
#define EAI_NODATA   7  /* no address associated with hostname */ 
#endif

I'm not sure what to make out of this, but as it stands, the patchset
does not work.

If I just add

  #define EAI_NODATA 7

to socket.c, it compiles and passes my regular client tests (no SRV tests
yet), but I do not think this is the correct solution.

(I have no idea *why* FreeBSD considers this "obsoleted", or what this
define is used for - have not yet investigated in any way)


If you need to test on FreeBSD, openvpn-vagrant has boxes that get
installed with all prerequisites (or I can give you access to one of
my buildslaves).

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Fix port-share option with TLS-Crypt v2

2020-12-04 Thread Gert Doering
Magic heuristics... but if Arne and Steffan agree that this is correct,
who am I to dispute it :-) - it passes client tests and is not
"obviously wrong".

Your patch has been applied to the master and release/2.5 branch.

commit 1387f52682dcd3789c56c9979ccedca281ff88f4 (master)
commit c27f97dc0ac99344659cca57bd048543a9899266 (release/2.5)
Author: Arne Schwabe
Date:   Mon Nov 30 13:38:13 2020 +0100

 Fix port-share option with TLS-Crypt v2

 Signed-off-by: Arne Schwabe 
 Acked-by: Steffan Karger 
 Message-Id: <20201130123813.21388-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21290.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: tls-crypt-v2: also preload tls-crypt-v2 keys (if --persist-key)

2020-12-04 Thread Gert Doering
As for 1/2, I have not really reviewed or tested anything
here.  Trusting you and Arne here.

>From a quick view this looks like a nice "code cleanup en passant",
though :-) (and it does pass the client side tests, of course).

Your patch has been applied to the master and release/2.5 branch.

commit 4d307ed431bf18d554f524ebaf111f5e136147fe (master)
commit bac760f84b39bf8f6b97778a15e5fcf863f6d366 (release/2.5)
Author: Steffan Karger
Date:   Thu Dec 3 16:49:51 2020 +0100

 tls-crypt-v2: also preload tls-crypt-v2 keys (if --persist-key)

 Signed-off-by: Steffan Karger 
 Acked-by: Arne Schwabe 
 Message-Id: <20201203154951.29382-2-stef...@karger.me>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21307.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: tls-crypt-v2: fix server memory leak

2020-12-04 Thread Gert Doering
I have not done much testing, and not even stared much at the
code.  But it's your code and Antonio has a keen eye :-)

Your patch has been applied to the master and release/2.5 branch.

commit fb169c3b8fdfa9792c0eee8441956f062dfd7982 (master)
commit 06e769552481729ddae28ee46b30f2dc8ca77509 (release/2.5)
Author: Steffan Karger
Date:   Thu Dec 3 19:22:30 2020 +0100

 tls-crypt-v2: fix server memory leak

 Signed-off-by: Steffan Karger 
 Acked-by: Antonio Quartulli 
 Message-Id: <20201203182230.33552-1-stef...@karger.me>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21310.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [ovpn-dco] Is cbc-hmac supported?

2020-12-04 Thread Gert Doering
Hi,

On Fri, Dec 04, 2020 at 10:49:04AM +0100, Jan Just Keijser wrote:
> as far as I 
> know no openvpn release supports CCM thus far (which is a shame, really).

I have heard rumors that someone got nerdsniped by this already... :-)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Remove auth_user_pass.wait_for_push variable

2020-12-02 Thread Gert Doering
Acked-by: Gert Doering 

I have pre-tested these changes extensively yesterday, trying 
to find new and exciting ways to break the combination of (async) 
plugin-auth, gen-auth-token, and --auth-nocache on the client - and 
this patchset finally makes this all work correctly :-)   

(my suggestion how to tackle this would have always stored the auth 
username, even if no token auth in use, which seems to violate the 
original principle of --auth-nocache)

Tested again with pristine master sources with only this patch
applied, and it still works.

Your patch has been applied to the master, release/2.5 and
release/2.4 branch (bugfix).

commit dfd624b52bce7ddd0eeaab516df9848e432f3242 (master)
commit 570f0564afb34ede41c99bf66f1f369bcf38b138 (release/2.5)
commit 607dfa9648e9967f89d2ce5bf949e90503011522 (release/2.4)
Author: Arne Schwabe
Date:   Wed Dec 2 12:59:28 2020 +0100

 Remove auth_user_pass.wait_for_push variable

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201202115928.16615-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21297.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Fix auth-token not being updated if auth-nocache is set

2020-11-30 Thread Gert Doering
Acked-by: Gert Doering 

Thanks for digging into this - this was an annoying and hard 
to diagnose "sometimes, TLS reconnects fail for users where 
it *should* succeed due to tokens being used" problem (that
openvpn considers tokens sensitive and never logs them 
didn't help pinpointing the issue :-) ).

I tested this with a client built with lots of extra
debug output, gen-auth-token and frequend tls-renegotiates - 
and indeed, "up->defined" goes to "0" after the first incoming 
token if auth-nocache is active - so, no *further* tokens are 
learned.  With the patch, we also look at "tk->defined", which 
is *then* defined, and tokens work even in that case.

Verified with a 2.4 client against a master server, including
a master restart without having to re-enter credentials on
the client.  Yay :-)

Your patch has been applied to the master, release/2.5 and
release/2.4 branch (bugfix, identical code in all branches).

commit fb789947ab1eba3e68fb8e4b3551d095a53962bd (master)
commit 95e183723fc6571c73ed070b22923df2ce666af2 (release/2.5)
commit f9b73042892c14b906772e72b3116d809457c721 (release/2.4)
Author: Arne Schwabe
Date:   Mon Nov 30 13:39:28 2020 +0100

 Fix auth-token not being updated if auth-nocache is set

     Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201130123928.21837-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21291.html
     Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Make any auth failure tls_authentication_status return auth failed

2020-11-29 Thread Gert Doering
Acked-by: Gert Doering 

Stared at the code for a bit, and it looks simple and straightforward
enough.  With 1/8...7/8 reviewed, I think I even understand what it
does :-)

The bit about "ks->authenticated == KS_AUTH_FALSE" becomes clear when
you look ks_auth_state - FALSE is 0, everything else is > FALSE, so
the "else" is basically the same condition as before.


Testing (only script backend + pam auth + token):

This improves the "token expired on renegotiation" even further,
though it still shows some interesting timing aspects.

Case 1: auth-gen-token 600, sync plugin auth-pam

2020-11-29 10:30:16 us=100840 --auth-token-gen: auth-token from client expired
2020-11-29 10:30:16 us=100868 TLS: Username/auth-token authentication failed 
for username 'fbsd-tc-master'
2020-11-29 10:30:16 us=101534 Control Channel: TLSv1.3, cipher TLSv1.3 
TLS_AES_256_GCM_SHA384, 2048 bit RSA
2020-11-29 10:30:32 us=478267 Delayed exit in 5 seconds
2020-11-29 10:30:32 us=478374 SENT CONTROL [cron2-freebsd-tc-amd64]: 
'AUTH_FAILED,SESSION: token expired' (status=1)

I wonder what it is doing here, between 10:30:16 and 10:30:32?  Expiring
the active key?

On the client side, we see renegotiation, TLS handshake, then a pause
(in which the connection still works fine(!)), then AUTH FAIL, and then
reconnect with user/password credentials:

2020-11-29 10:30:16 TLS: soft reset sec=151/151 bytes=89537/-1 pkts=705/0
2020-11-29 10:30:16 Control Channel: TLSv1.3, cipher TLSv1.3 
TLS_AES_256_GCM_SHA384, 2048 bit RSA
2020-11-29 10:30:32 AUTH: Received control message: AUTH_FAILED,SESSION: token 
expired

2020-11-29 10:30:32 Restart pause, 5 second(s)
..
2020-11-29 10:30:37 TLS: Initial packet from ...
..
2020-11-29 10:30:37 PUSH: Received control message: 
'PUSH_REPLY,...,xauth-tokenSESS_ID,...
..
2020-11-29 10:30:38 Initialization Sequence Completed


The server confirms:

2020-11-29 10:30:37 us=551426 TLS: Username/Password authentication succeeded 
for username 'fbsd-tc-master' 


So - this is definitely very nice.



Test case 2: auth-gen-token 600, deferred plugin auth-pam with 16s delay

- initial connect takes 18s (which is expected)
- initial TLS-reconnect with token takes 0.002s (which is very nice :) )
- TLS reconnect after 10 minute, with expired token...

2020-11-29 10:50:05 us=911127 --auth-token-gen: auth-token from client expired
2020-11-29 10:50:05 us=911147 TLS: Username/auth-token authentication failed 
for username 'fbsd-tc-master'
2020-11-29 10:50:05 us=912088 Control Channel: TLSv1.3, cipher TLSv1.3 
TLS_AES_256_GCM_SHA384, 2048 bit RSA
2020-11-29 10:50:21 us=533468 Delayed exit in 5 seconds
2020-11-29 10:50:21 us=533597 SENT CONTROL [cron2-freebsd-tc-amd64]: 
'AUTH_FAILED,SESSION: token expired' (status=1)

.. does the right thing now!

The client understands, and reconnects with password:

2020-11-29 10:50:26 us=601574 Re-using SSL/TLS context
2020-11-29 10:50:26 us=614341 PLUGIN AUTH-PAM: do deferred auth 
'/tmp/openvpn_acf_3131079bbfa3c5c756b7e374b8328dfc.tmp'
2020-11-29 10:50:26 us=627822 TLS: Username/Password authentication deferred 
for username 'fbsd-tc-master' 
2020-11-29 10:50:41 us=641229 PLUGIN AUTH-PAM: BACKGROUND: fbsd-tc-master: 
deferred auth: PAM succeeded
2020-11-29 10:50:42 us=814877 SENT CONTROL [cron2-freebsd-tc-amd64]: 
'PUSH_REPLY,...,auth-tokenSESS_ID,...,key-derivation tls-ekm' (status=1)


And things are back to "it pings".  Of course the "no-ping" time is longer in 
this case, due to client reconnect (5s) *plus* 16s AUTH-PAM backgrounding, 
but this is exactly what is to be expected.

(This is the case where OpenVPN would previously get totally confused and 
never tell the client "hey, you're dead, reconnect!" - so, bug fixed, great 
stuff)


Your patch has been applied to the master branch (because it needs all
the prerequisite refactoring patches).  Now, how to get the bugfix part
into 2.5.1?

commit 88dc4276485bf2a4cecae3cff55d2e146dcd31ca
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:59 2020 +0200

 Make any auth failure tls_authentication_status return auth failed

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-7-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21223.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Send AUTH_FAILED message to clients on renegotiation failures

2020-11-26 Thread Gert Doering
Acked-by: Gert Doering 

I actually have a test case for this...

 - auth-gen-token 600
 - reneg-sec 30
 - sync plugin-auth-pam

then it will happily renegotiate every 30 seconds, and after 
10 minutes it will "fail without noticing" - the server logs

2020-11-26 15:10:30 us=755319 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
--auth-token-gen: auth-token from client expired
2020-11-26 15:10:30 us=755355 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
TLS: Username/auth-token authentication failed for username 'fbsd-tc-master'

(but never tells the client).

Eventually the keys time out:

2020-11-26 15:10:50 us=604558 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
TLS Error: local/remote TLS keys are out of sync: 
[AF_INET6]2001:608:0:814::f000:21:42838 (received key id: 7, known key ids:  
[key#0 state=S_ACTIVE auth=KS_AUTH_FALSE id=7 sid=4ead8bbc 11847581] [key#1 
state=S_ACTIVE auth=KS_AUTH_TRUE id=6 sid=4ead8bbc 11847581] [key#2 
state=S_UNDEF auth=KS_AUTH_FALSE id=0 sid= ])

.. so pings start failing from here.

2020-11-26 15:11:00 us=968564 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
SIGTERM[soft,auth-control-exit] received, client-instance exiting

.. and on the next reneg-interval, the MI is closed.

The client runs into *ping* timeout eventually...  (but is never told by the 
server 
that the server instance went away):

2020-11-26 15:11:00 TLS: soft reset sec=30/30 bytes=7869/-1 pkts=61/0
2020-11-26 15:11:24 [server] Inactivity timeout (--ping-restart), restarting

retries after 5s:

2020-11-26 15:11:31 us=7470 2001:608:0:814::f000:21 SENT CONTROL 
[cron2-freebsd-tc-amd64]: 'AUTH_FAILED,SESSION: token expired' (status=1)

here the client *is* told, and re-tries 5 seconds later, with the 
"non-token" auth:

2020-11-26 15:11:36 us=98591 2001:608:0:814::f000:21 TLS: Username/Password 
authentication succeeded for username 'fbsd-tc-master' 

(failure of 51 seconds in here)


*With* the patch, there still is silliness involved

2020-11-26 15:42:30 us=587138 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
--auth-token-gen: auth-token from client expired
2020-11-26 15:42:30 us=587168 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
TLS: Username/auth-token authentication failed for username 'fbsd-tc-master'
2020-11-26 15:42:30 us=591020 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2020-11-26 15:42:45 us=175486 cron2-freebsd-tc-amd64/2001:608:0:814::f000:21 
TLS Error: local/remote TLS keys are out of sync: 
[AF_INET6]2001:608:0:814::f000:21:29307 (received key id: 7, known key ids:  
[key#0 state=S_ACTIVE auth=KS_AUTH_FALSE id=7 sid=028b5663 63c9dc4d] [key#1 
state=S_ACTIVE auth=KS_AUTH_TRUE id=6 sid=028b5663 63c9dc4d] [key#2 
state=S_UNDEF auth=KS_AUTH_FALSE id=0 sid= ])

.. and pings fail from 15:42:45 onwards, without telling the client.

The improvement bit happens then:

2020-11-26 15:43:00 TLS: soft reset sec=30/30 bytes=7869/-1 pkts=61/0
2020-11-26 15:43:00 AUTH: Received control message: AUTH_FAILED,SESSION: token 
expired
2020-11-26 15:43:00 Restart pause, 5 second(s)
2020-11-26 15:43:05 [server] Peer Connection Initiated with 
[AF_INET6]2001:608:0:814::f000:11:51199

So on the next renegotiation the client will receive a proper
error, and can reconnect right away.

Ping failure time is down from 51s to 23s, so "improvement" :-)


Your patch has been applied to the master branch.

commit 55d5eaa3e021a21b9537a474c46636d4c2dcdac5
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:58 2020 +0200

 Send AUTH_FAILED message to clients on renegotiation failures

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-6-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21222.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Rename DECRYPT_KEY_ENABLED to TLS_AUTHENTICATED

2020-11-26 Thread Gert Doering
Acked-by: Gert Doering 

code wise, this is just mechanical search-and-replace, so easily
tested :-) - "understanding the code" wise this makes sense,
and even brings in extra documentation!

Your patch has been applied to the master branch.

commit 3ac8e5923a12390f68aa901e04ab3204e326d243
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:57 2020 +0200

 Rename DECRYPT_KEY_ENABLED to TLS_AUTHENTICATED

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-5-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21221.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Clean up tls_authentication_status and document it

2020-11-26 Thread Gert Doering
Acked-by: Gert Doering 

This is not for the faint of heard... so I've excercised this
on the server side test framework (which has various "fail auth"
tests).

The changes in push.c and ssl.c are self-explanatory, though I
wonder why you didn't go for an "early exit if (!multi)" in
tls_authentication_status() to avoid the extra condition.

The change to ssl_verify.c is somewhat harder to grok - but after
staring at the table for a while, the combinations and priority
of evaluation becomes clear ("if either is ACF_FAILED, the result
is ACF_FAILED.  Then, if either is UNDEFINED, ...") - and the new
code reflects that, with WAY less magic, and more comments.  Yay.

Your patch has been applied to the master branch.

commit f9d3fbf9bc87ae6c05fc592712f610491a77d78b
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:56 2020 +0200

 Clean up tls_authentication_status and document it

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-4-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21224.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [ovpn-dco] Is cbc-hmac supported?

2020-11-26 Thread Gert Doering
Hi,

On Thu, Nov 26, 2020 at 05:04:45PM +0800, Tony He wrote:
> Because there is HW crypto engine in some  embedded devices, the crypto
> engine maybe only supports hmac-sha256-cbc-aes.

OK, I was not aware that there is such special-case hardware.  Thanks
for the explanation.

Yes, in that case it might be nice to add support for these crypto 
modes to DCO later, when the initial feature set is done, well tested
and properly shaken down.  

For the initial feature set, DCO needs to focus on a subset of features 
that benefit most users - and that's AES-GCM and CHACHA.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [ovpn-dco] Is cbc-hmac supported?

2020-11-26 Thread Gert Doering
Hi,

On Thu, Nov 26, 2020 at 04:53:14PM +0800, Tony He wrote:
> Understood.  We have dicussed this in the OpenWRT forum. Maybe some kind
> OpenWRT guys will implement  aead hmac-sha256-cbc-aes
> for ovpn-dco module in the future.

Why?  If you do AES in the first place, all numbers I have seen so far
say "AES-GCM modes are faster / use less CPU = battery".  And, less
overhead on the wire.

And on non-intel devices, CHACHA-POLY, because there is ARM acceleration.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Improve keys out of sync message

2020-11-25 Thread Gert Doering
Acked-by: Gert Doering 

I have no test bed that will trigger this, but the change is
not hard to understand (extend print_key_id() with a 
"auth=make_string(ks->authenticated)", append the result to
the "TLS Error:" message.

All other users of print_key_id() are all "just debug output",
so the new format will not confuse anything.

Compile tested on the client.

As with 2/8, uncrustify does not like the indenting of the
new switch/case block.  Adjusted.

Your patch has been applied to the master branch.

commit f1f0f074bf6e7b91673bfa8cb08b3be44ebda76b
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:55 2020 +0200

 Improve keys out of sync message

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-3-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21226.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Add more documentation about our internal TLS functions

2020-11-25 Thread Gert Doering
Acked-by: Gert Doering 

"This was an easy one" - documentation is good.

Your patch has been applied to the master branch.

commit 8292102b102ff62d6b7ed1254076b822cb113162
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:54 2020 +0200

 Add more documentation about our internal TLS functions

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-2-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21220.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Replace key_scan array of static points with inline function

2020-11-25 Thread Gert Doering
Acked-by: Gert Doering 

Not sure if I ever understood these shortcuts (there are 3*2 keys
in session[].keys[], but the shortcuts only reference [0][0],
[0][1] and [2][1]) but from a "mechanically comparing before/after"
point of view, the change looks sane.  

Plus, it passes client side tests, with short reneg timeouts (20s).

This change, of course, makes it more interesting to do backports
of ssl.c-related changes from master/2.6 to 2.5...  so let's get
out 2.6 quickly :-)

Uncrustify complains about indent of the new switch/case block,
and that there is a trailing semicolon.  Fixed.

*Also*, this patch needed to be (manually) rebased due to context 
conflicts after 0d4ca79d4f.  Done.

"points" -> "pointers", as requested.

Your patch has been applied to the master branch.

commit cc5a71637139557a7eaa024251ff75a0acb22bc8
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:53 2020 +0200

 Replace key_scan array of static pointers with inline function

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21225.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Also announce IV_CIPHERS as client in OpenVPN 2.4

2020-11-24 Thread Gert Doering
Acked-by: Gert Doering 

This is useful functionality for better 2.4 client <=> 2.5/master 
server NCP interoperability.  It is only bringing in the client
side, which is fairly nonintrusive.

Tested with my t_client setup (client-side only) and with a few
manual calls to excercise the translation code (works).  What 
does not work is case-insensitive cipher name specifications -
I thought "Bf-cbC" should work, but 2.6 doesn't do this either
(so, no idea where I got that idea from).

Looking at the code, I do wonder why we send IV_NCP=2 and IV_CIPHERS
server to client, when we do not have anything on the client side
that would care about these bits...  but this is nothing this 
patch introduces.

Your patch has been applied to the release/2.4 branch.

commit f8c3e0aef2f6e03a0a5eafd81644c4079796649d
Author: Arne Schwabe
Date:   Sun Aug 30 16:07:36 2020 +0200

 Also announce IV_CIPHERS as client in OpenVPN 2.4

 Signed-off-by: Arne Schwabe 
     Acked-by: Gert Doering 
 Message-Id: <20200830140736.16571-3-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20844.html
     Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Normalise ncp-ciphers option and restrict it to 127 bytes

2020-11-24 Thread Gert Doering
Acked-by: Gert Doering 

It's a prerequisite for the (desirable) IV_CIPHERS patch 
for 2.4.  It passes the client side tests (though the code
is not exercised very strongly).  The code looks different
from the "master" patch due to changes to cipher_kt_get()
and because it's called "--data-ciphers" there - but these
are straightforward.  Besides that, it's exactly the same
code.

NOTE: the patch includes a copy of ssl_ncp.h, which is 
not needed *and* not referenced, so I've dropped that part.

Your patch has been applied to the release/2.4 branch.

commit 7e3cd06d514476658709506c5e8e0703008efc5f
Author: Arne Schwabe
Date:   Sun Aug 30 16:07:35 2020 +0200

 Normalise ncp-ciphers option and restrict it to 127 bytes

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20200830140736.16571-2-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20846.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: build: Fix missing install of man page in certain environments

2020-11-24 Thread Gert Doering
Acked-by: Gert Doering 

I have not tested it further, but the explanation + test report make
this "good enough"

Your patch has been applied to the master and release/2.5 branch.

commit fc25ca3a7cf720fbb53889fdba6ac0154c7c9c1a (master)
commit bbac1542cfb4a9d3033999b26813f0dd0618c3f0 (release/2.5)
Author: David Sommerseth
Date:   Thu Oct 29 22:32:59 2020 +0100

 build: Fix missing install of man page in certain environments

 Signed-off-by: David Sommerseth 
 Acked-by: Gert Doering 
 Message-Id: <20201029213259.1636-1-dav...@openvpn.net>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21236.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Change travis build scripts to use https when fetching prerequisites.

2020-11-24 Thread Gert Doering
Patch has been applied to the master, release/2.5, release/2.4 branch.

commit 0d4069e41d3ba7178be30f78f1174f689dbdfa59 (master)
commit d3dd620b13a21c3ed73fd466390f471915937309 (release/2.5)
commit f16b4edabab1d24adfe3e8824d26f401f6afde6d (release/2.4)
Author: Gert Doering
Date:   Tue Nov 24 17:13:13 2020 +0100

 Change travis build scripts to use https when fetching prerequisites.

 Signed-off-by: Gert Doering 
 Acked-by: Arne Schwabe 
 Message-Id: <20201124161313.18831-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21264.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Change travis build scripts to use https when fetching prerequisites.

2020-11-24 Thread Gert Doering
Reported by "jub0bs" on hackerone.com (#1039504)

Signed-off-by: Gert Doering 
---
 .travis/build-deps.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
index 08b93e7a..61673441 100755
--- a/.travis/build-deps.sh
+++ b/.travis/build-deps.sh
@@ -18,14 +18,14 @@ PREFIX="${PREFIX:-${HOME}/opt}"
 download_tap_windows () {
 if [ ! -f "download-cache/tap-windows-${TAP_WINDOWS_VERSION}.zip" ]; then
wget -P download-cache/ \
-   
"http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip;
+   
"https://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip;
 fi
 }
 
 download_lzo () {
 if [ ! -f "download-cache/lzo-${LZO_VERSION}.tar.gz" ]; then
 wget -P download-cache/ \
-
"http://www.oberhumer.com/opensource/lzo/download/lzo-${LZO_VERSION}.tar.gz;
+
"https://www.oberhumer.com/opensource/lzo/download/lzo-${LZO_VERSION}.tar.gz;
 fi
 }
 
-- 
2.29.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] OpenVPN 3 Linux client - v11 beta released

2020-11-02 Thread Gert Doering
Hi,

On Mon, Nov 02, 2020 at 03:00:58PM +0100, David Sommerseth wrote:
> >   Then the imported configuration profile must get the DCO feature
> >   enabled:
> > 
> >   $ openvpn3 config-manage --show --name CFGNAME --dco true
> 
> So I managed to introduce a typo here, this config-manage operation
> should use --config instead of --name:
> 
> $ openvpn3 config-manage --show --name CFGNAME --dco true

Yeah, right.  The difference is quite obvious :-)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Remove --disable-def-auth configure argument

2020-10-24 Thread Gert Doering
Acked-by: Gert Doering 

Looked at the changes (look good), saw that a few #ifdefs are now
"ENABLE_MANAGEMENT", so compiled with default settings and with
--disable-management.  Both passed compile + t_client tests.

I have not specifically tested management functionality - I do not
have a server testbed for that yet, and I was too lazy to compile
a windows client to test the client side.  I do assume that you
tested that part on the Android client already.

Your patch has been applied to the master branch.

commit 99d217b20064e7fef90dfa49bdcbab23ea7fbcb3
Author: Arne Schwabe
Date:   Fri Oct 23 13:32:44 2020 +0200

 Remove --disable-def-auth configure argument

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023113244.26295-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21214.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Remove explicit setting of peer_id to false

2020-10-24 Thread Gert Doering
Acked-by: Gert Doering 

I can see why this initalization was put there, initially, to 
make clear "P_DATA_V2 is not enabled by default" - but since we do
not do this for all other "do not enable this $bool by default"
initializations either, it is indeed an oddball and confuses more
than it helps.

(If Lev yells at me that he really likes this particular line I
can put it back, though :-) )

Your patch has been applied to the master branch.

commit 0d4ca79d4fc3c42b3970190f96781ed4f2552b32
Author: Arne Schwabe
Date:   Fri Oct 23 13:34:30 2020 +0200

 Remove explicit setting of peer_id to false

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023113431.26691-4-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21218.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Remove NULL checks before calling free

2020-10-24 Thread Gert Doering
Acked-by: Gert Doering 

I have not verified the OpenSSL and pkcs11 free() functions, but the
changes to our source tree (event_free() etc.) are consistent and make
the code easier to read.

Passed a client side test (for good measure).

Your patch has been applied to the master branch.

commit cb70cf51889ee96446ba77a406bb2ac0f01dc174
Author: Arne Schwabe
Date:   Fri Oct 23 13:34:31 2020 +0200

 Remove NULL checks before calling free

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023113431.26691-5-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21216.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Align reliable_free with other free methods to accept NULL

2020-10-24 Thread Gert Doering
Acked-by: Gert Doering 

Change brings this more in line with other code parts, so easier
to understand.

Your patch has been applied to the master branch.

commit 2c8a9877617727438cdd874ecd38c04adebf53ad
Author: Arne Schwabe
Date:   Fri Oct 23 13:34:29 2020 +0200

 Align reliable_free with other free methods to accept NULL

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023113431.26691-3-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21215.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 2/5] xmit_hold is only required for port_share

2020-10-24 Thread Gert Doering
Hi,

On Fri, Oct 23, 2020 at 01:34:28PM +0200, Arne Schwabe wrote:
> Make options.c only set xmit_hold when port_share is active to least
> document this dependency. I have not actually tested if this dependency
> is actually true (or if port_share could work without xmit_hold).

I'm not sure I understand this patch, or the flow.  Before this patch,
xmit_hold is always set to "true" for TCP_SERVER, after this patch,
only for server *and* port_share.

What am I overlooking?

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Inline function tls_get_peer_info

2020-10-24 Thread Gert Doering
Acked-by: Gert Doering 

"obviously correct" and a reasonable change.

Just a quick client side test (passed).

Your patch has been applied to the master branch.

commit 0d5aab889b0209cab9bb65f8bebf2adab5b1ff52
Author: Arne Schwabe
Date:   Fri Oct 23 13:34:27 2020 +0200

 Inline function tls_get_peer_info

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023113431.26691-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21217.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] OpenVPN 2.5-rc1 released unable to redirect IPv4 default gateway under Windows

2020-10-19 Thread Gert Doering
Hi,

On Mon, Oct 19, 2020 at 07:59:06PM +0200, Thomas Schäfer wrote:
> > I expect us to release a RC3 this week, so it can be thoroughly tested.
> 
> I went back to the university tonight just in the moment I saw rc3.
> 
> No wonder: I can confirm it works now as expected.
> 
> Tested with the windows installer package (amd) and with linux source tar 
> ball.

thank you very much! :-)

*happy dance*

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Avoid passing NULL to argv_printf_cat() in temp_file error case.

2020-10-15 Thread Gert Doering
Patch has been applied to the master and release/2.5 branch.

I have beaten this somewhat on the server torture bench, having
a config with plugin-auth-pam (deferred), auth-user-pass-verify *and*
auth-gen-token, testing both "via-env" (script-security 3 needed!)
and "via-file", testing script success and failure.

There might be a race between deferred plugin-auth and a failing
script - I saw something weird, but could not reproduce it (it might
have been "restarted the client too often, so the server log was
unclear on 'which message belongs to what instance'").

commit bbcada8abb410d077f7bc13b8157198b4bf6a3d1 (master)
commit 20965a18e52e60966ed754e6171e08ebe67432d6 (release/2.5)
Author: Gert Doering
Date:   Tue Oct 13 22:47:58 2020 +0200

 Avoid passing NULL to argv_printf_cat() in temp_file error case.

     Signed-off-by: Gert Doering 
 Acked-by: David Sommerseth 
 Message-Id: <20201013204758.2472-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21204.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Avoid passing NULL to argv_printf_cat() in temp_file error case.

2020-10-13 Thread Gert Doering
To pass username + password to verify_user_pass_script(), OpenVPN
can either put both into environment, or create a temp file, and
pass that file name to the "user-pass-verify" script.  The file
name is initialized as "", so if no file is desired, it's well
defined - but if the file can not be created, the pointer is NULL
afterwards.

Change the sequence of events, setting up the argv before the
"if (file)" conditional, and add the file name only inside that
clause, if creating the temp file succeeded.

commit a4eeef17b2 did not create the problem, but modified the
code enough so that the static analyzer in gcc 9.2.0 *now* noticed
and issued a warning.

 ssl_verify.c:1132:5: warning: '%s' directive argument is null
  1132 | argv_printf_cat(, "%s", tmp_file);

Signed-off-by: Gert Doering 
---
 src/openvpn/ssl_verify.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index e19644c8..5c0aa6da 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1098,6 +1098,9 @@ verify_user_pass_script(struct tls_session *session, 
struct tls_multi *multi,
 /* Set environmental variables prior to calling script */
 setenv_str(session->opt->es, "script_type", "user-pass-verify");
 
+/* format command line */
+argv_parse_cmd(, session->opt->auth_user_pass_verify_script);
+
 if (session->opt->auth_user_pass_verify_script_via_file)
 {
 struct status_output *so;
@@ -1115,6 +1118,8 @@ verify_user_pass_script(struct tls_session *session, 
struct tls_multi *multi,
 tmp_file);
 goto done;
 }
+/* pass temp file name to script */
+argv_printf_cat(, "%s", tmp_file);
 }
 else
 {
@@ -1127,10 +1132,6 @@ verify_user_pass_script(struct tls_session *session, 
struct tls_multi *multi,
 setenv_str(session->opt->es, "password", up->password);
 }
 
-/* format command line */
-argv_parse_cmd(, session->opt->auth_user_pass_verify_script);
-argv_printf_cat(, "%s", tmp_file);
-
 /* call command */
 ret = openvpn_run_script(, session->opt->es, 0,
  "--auth-user-pass-verify");
-- 
2.26.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH applied] Re: Fix redirecting of IPv4 default gateway if connecting over IPv6.

2020-10-12 Thread Gert Doering
Hi,

On Sun, Oct 04, 2020 at 06:02:58PM +0200, Gert Doering wrote:
> Patch has been applied to the master and release/2.5 branch.
> 
> commit 23e11e591347080efa3b933beca7f620dd059d5c (master)
> commit 7b4f53095c761bde8c6b39cf645cade4c1c0c5d4 (release/2.5)
> Author: Gert Doering
> Date:   Fri Oct 2 19:57:36 2020 +0200
> 
>  Fix redirecting of IPv4 default gateway if connecting over IPv6.

Turns out that 2.4 is also affected by the problem (because the 
offending commit was applied to 2.4, because "bugfix").

Thus:

commit 4f6461b3dd79a4288580aeea0ba89e94e0251b06 (release/2.4)
Author: Gert Doering 
Date:   Fri Oct 2 19:57:36 2020 +0200

Fix redirecting of IPv4 default gateway if connecting over IPv6.



sorry for not checking this right away.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Add function for common env setting of verify user/pass calls

2020-10-11 Thread Gert Doering
Acked-by: Gert Doering 

I have stared at the code (with and without "-w").  Looks good.

Removal of duplicated code is always good, as well as reduced
indentation levels.  And if it fixes a bug, even better.

As a side note: "retval" in verify_user_pass_management() got
sillified now... only one code path, only one possible exit.

And we need to get rid of a few #ifdefs there...


Code has been tortured a bit on the server testbed - works
as before (using plugin-auth-pam in deferred mode with
must-succeed and must-fail tests).  No auth script and no 
management on the server today.

Client side has been tested for good measure, but is not 
executing these code paths at all.

I have not specifically tested the buggy situation (no testbed
for exactly that combination right now), but I know a production
setup running that combination - they will surely test RC3 with
the fix :-)

The stray half-sentence in the commit message was fed to the
whitespace dragon.

Your patch has been applied to the master and release/2.5 branch.

commit a4eeef17b20541a7afde0f1cbeae4a4e2b0c455a (master)
commit 09aad8b4e1df91b7b6ed5163390eae3730b17d32 (release/2.5)
Author: Arne Schwabe
Date:   Mon Oct 5 13:16:14 2020 +0200

 Add function for common env setting of verify user/pass calls

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201005111614.29325-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21174.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Ignore deprecation warning for daemon on macOS

2020-10-11 Thread Gert Doering
Acked-by: Gert Doering 

"unavoidable warnings are less useful than no warnings at all" -
so as a temporary measure, this makes sense.  Longterm, one could
see whether a "platform_daemon()" call makes sense...  

(From how I read the posix_spawn(3) manpage, it latter is more intended 
to replace fork()/exec() combos... not sure how that would help with
daemonizing [controlling tty and that]... daemon(3) suggests that Apple 
does not want people to start daemons by hand at all, using launchd(8)
instead...  and I agree that *that* would need a totally different
approach to "start openvpn")

Tested on Mojave: fixes the warnings in init.c and down-root.c.

Your patch has been applied to the master branch.

commit a480eaae1d32a6c3970911a561a64c1019944f92
Author: Arne Schwabe
Date:   Mon Oct 5 11:18:05 2020 +0200

 Ignore deprecation warning for daemon on macOS

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201005091805.17260-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21171.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Fix compilation on pre-EKM mbedTLS libraries.

2020-10-10 Thread Gert Doering
Patch has been applied to the master branch.

commit 14bd92b7e4a698678200f439ddda1ee321bb8ee8
Author: Gert Doering
Date:   Sat Oct 10 10:14:35 2020 +0200

 Fix compilation on pre-EKM mbedTLS libraries.

 Signed-off-by: Gert Doering 
 Acked-by: Steffan Karger 
 Message-Id: <20201010081435.2154-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21198.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v2] Fix compilation on pre-EKM mbedTLS libraries.

2020-10-10 Thread Gert Doering
commit f0734e49956217 simplified key_state_export_keying_material(),
changing the function prototype.  For older mbedTLS versions, there
is an "always fail" dummy function which was overlooked in that change.

Fix prototype.

v2: also adjust function return (NULL -> false)

Signed-off-by: Gert Doering 
---
 src/openvpn/ssl_mbedtls.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index bb5633b7..11fbeae4 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -252,14 +252,13 @@ key_state_export_keying_material(struct tls_session 
*session,
 }
 }
 #else
-unsigned char*
+bool
 key_state_export_keying_material(struct tls_session *session,
  const char* label, size_t label_size,
- size_t ekm_size,
- struct gc_arena *gc)
+ void *ekm, size_t ekm_size)
 {
 /* Dummy function to avoid ifdefs in the common code */
-return NULL;
+return false;
 }
 #endif /* HAVE_EXPORT_KEYING_MATERIAL */
 
-- 
2.22.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Fix compilation on pre-EKM mbedTLS libraries.

2020-10-09 Thread Gert Doering
commit f0734e49956217 simplified key_state_export_keying_material(),
changing the function prototype.  For older mbedTLS versions, there
is "always fail" dummy function which was overlooked in that change.

Fix prototype.

Signed-off-by: Gert Doering 
---
 src/openvpn/ssl_mbedtls.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index bb5633b7..b100d03e 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -252,11 +252,10 @@ key_state_export_keying_material(struct tls_session 
*session,
 }
 }
 #else
-unsigned char*
+bool
 key_state_export_keying_material(struct tls_session *session,
  const char* label, size_t label_size,
- size_t ekm_size,
- struct gc_arena *gc)
+ void *ekm, size_t ekm_size)
 {
 /* Dummy function to avoid ifdefs in the common code */
 return NULL;
-- 
2.22.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Simplify key material exporter backend API

2020-10-09 Thread Gert Doering
I have stared at the code a bit ("amazingly straightforward, no crypto
convolutions at all :-)") and tortured the result a bit on the server 
and client test bed.  No complaints.

(I have excercised the "key-derivation tls-ekm" path, but not the 
generic EKM path - no test case for that one yet... need to add one,
it seems)

Your patch has been applied to the master branch.

commit f0734e499562175a6ebbefbfa12b730c976e2507
Author: Steffan Karger
Date:   Fri Oct 9 16:47:55 2020 +0200

 Simplify key material exporter backend API

 Signed-off-by: Steffan Karger 
 Acked-by: Arne Schwabe 
 Message-Id: <20201009144755.39719-1-stef...@karger.me>
 URL: 
https://www.mail-archive.com/search?l=mid=20201009144755.39719-1-stef...@karger.me
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Implement generating data channel keys via EKM/RFC 5705

2020-10-09 Thread Gert Doering
In addition to the thorough review from Steffan, I have tortured
this patch on the client and server side (read: patched client 
talking to an old server, old clients talking to a patched server,
patched client talking to patched server, with/without NCP) and
everything succeeded/failed as expected.

I have actually seen the handshake happen between openssl client
and server, and mbedtls 2.24.0 (gentoo) client / openssl server
(I have not checked if the handshake had any actual *effect*, just
if I could see it in the PUSH_REPLY message, and that ping worked
afterwards).

"PUSH_REPLY ... cipher none,key-derivation tls-ekm" looks weird :-)

Your patch has been applied to the master branch.

commit 6dc09d0d4520483716530e12a444b156720cdfcc
Author: Arne Schwabe
Date:   Fri Oct 9 13:54:53 2020 +0200

 Implement generating data channel keys via EKM/RFC 5705

 Signed-off-by: Arne Schwabe 
 Acked-by: Steffan Karger 
 Message-Id: <20201009115453.4279-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21187.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: networking_iproute2: fix memory leak in net_iface_mtu_set()

2020-10-09 Thread Gert Doering
Yeah, very obvious when you look at it :-)  (wasn't *me* who
ACKed that commit... but I had to check to be sure ;-) )

Your patch has been applied to the master and release/2.5 branch.

commit 1e6e083e042d58f9541bf74d343d52fc5681 (master)
commit a9c8225439f0acaa679ee59244b5b8660b561592 (release/2.5)
Author: Steffan Karger
Date:   Fri Oct 9 15:46:03 2020 +0200

 networking_iproute2: fix memory leak in net_iface_mtu_set()

 Signed-off-by: Steffan Karger 
 Acked-by: Antonio Quartulli 
 Message-Id: <20201009134603.36263-1-stef...@karger.me>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21189.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Allow 'none' cipher being specified in --data-ciphers

2020-10-08 Thread Gert Doering
Acked-by: Gert Doering 

I have added two new cases to my server test suite: client with 
"--data-ciphers none" and "--ncp-disable --cipher none", against 
a server instance that permits "none" as part of its data-ciphers.

The first case failed on the client side ("unrecognized
cipher: none"), the second case was refused by the server side 
("No common cipher... client supports cipher '[null-cipher]').

Of course the server side *also* needs the patch to accept
"none" as part of --data-ciphers :-)

Then, this works:

2020-10-04 15:04:28 us=208824 2001:608:4:0:669a:56c1:4175:2c5b peer info: 
IV_CIPHERS=none
2020-10-04 15:04:28 us=251968 Data Channel: using negotiated cipher 'none'
2020-10-04 15:04:28 us=252006 *** WARNING ***: '--cipher none' was ...

The warning in the logs is very clear and explicit - and I think
this is good.  This is a very special-use setting, and should
only be used with sufficient information and consideration.


Big IPv4 packets (t_client test with 3000 bytes) do not work - something
is wrong in our mtu/overhead calcululation.  But this is not something 
new (as the v3 commit message rightly points out) - if I do "client 
connects with --data-cipher DES-EDE3-CBC" (non AEAD) I get the same 

  TCP/UDP packet too large on write to ... (tried=1544,max=1542)

error as I have with "none" (there, it is tried=1529,max=1526).  Strange 
enough this only happens for IPv4 packets.


Your patch has been applied to the master and release/2.5 branch.

commit c018fc00be25aee5921d234531f87753a3a7aec7 (master)
commit f308251acdc539acb370aeccf46b0ec5587129c1 (release/2.5)
Author: Arne Schwabe
Date:   Thu Oct 8 13:59:59 2020 +0200

 Allow 'none' cipher being specified in --data-ciphers

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201008115959.21151-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21181.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH applied] Re: Speedup TCP remote hosts connections

2020-10-05 Thread Gert Doering
Hi,

On Mon, Oct 05, 2020 at 10:22:43PM +0500, Vladislav Grishenko wrote:
> Perhaps same approach can be applied to server's tcp listening, would
> require testing of more management cases.

There's two code paths here

 --tcp-server

and

 --mode server + --tcp

I think the "mode server" code path is already very quick (= if I test
with your fast TCP client, against a "git master" server, I get 0.16s 
connection setup time).  This is what people use on "more than one
client" servers, so it's already fine.

The "--tcp-server" code path is "point to point".  Not sure we currently
test this at all (I have UDP p2p instance, but no TCP yet... seems I
need to add one).  This might indeed be slow, I had a look at the
accept() path in socket.c recently and was wondering "how can this 
work at all?" - but that's "socket.c" vs. "mtcp.c", I think.


Since this is somewhat of a niche case, I'd put that into the "2.6" bin :-)
- the other one, TCP on the client, is much more heavily used, so 2.5
for that was appropriate.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Support X509 field list to be username

2020-10-05 Thread Gert Doering
Your patch has been applied to the master branch.

Client-side tested, and lightly stared at the code.

The whitespace dragon made me add that blank after comma (but not
the other one in code not already touched by this patch) - IRC
discussion points to "sp_after_comma", which we indeed do not set
today.  We need to discuss this with the dragons :-)

After quite some deliberation I've decided that this is "new feature"
and "too late for 2.5", so not applied to release/2.5 - it was not 
an easy decision, as this could indeed be a very useful feature for
server operators running "distribution provided" binaries, which 
usually is "2.5".  OTOH, at some point we want to get 2.5.0 *out*,
and if we keep adding features, we need more RCs, and then we'll
never get there.  OTOH, again, this is a fairly isolated change - so
if enough users yell at me that THEY MUST HAVE THIS, we could put
it in 2.5.1 or 2.5.2 ("small and isolated new features can be done
in small-numbered subreleases").

Also, we do want 2.6.0 to happen "soonish" this time, like "in one
year, not in four years".  Let's see...

commit 3b04c34de140355b5b1d4ed85f7ccf1db9b0135d
Author: Vladislav Grishenko
Date:   Mon Oct 5 05:51:14 2020 +0500

 Support X509 field list to be username

 Signed-off-by: Vladislav Grishenko 
 Acked-by: Arne Schwabe 
 Message-Id: <20201005005114.13619-1-themi...@yandex-team.ru>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21168.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH applied] Re: Move openvpn specific key expansion into its own function

2020-10-05 Thread Gert Doering
Your patch has been applied to the master branch.

(Since this is only needed for the new PRF functionality and it's
very unlikely that we'll see bugfixes for "master *and* 2.5" for this
code in future, the refactoring is also not needed in 2.5)

Whitespace has been fixed :-) (we really need T-Shirts with
"the whitespace dragon made me do this" on them...)

Tested on the client side against an umodified server, works fine.

commit 15d0524327a10c2999f37375688196f8452f1029
Author: Arne Schwabe
Date:   Tue Aug 25 09:36:42 2020 +0200

 Move openvpn specific key expansion into its own function

 Signed-off-by: Arne Schwabe 
 Acked-by: Steffan Karger 
 Message-Id: <20200825073643.15920-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20815.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] OpenVPN 2.5-rc1 released unable to redirect IPv4 default gateway under Windows

2020-10-04 Thread Gert Doering
Hi Thomas,

On Tue, Sep 22, 2020 at 04:21:49PM +0200, Thomas Schäfer wrote:
> I get 
> Note: unable to redirect IPv4 default gateway -- Cannot read current default 
> gateway from system

I'm fairly sure I found this, and a fix has been merged today.

I expect us to release a RC3 this week, so it can be thoroughly tested.

(You saw the same effect before, but it was a different bug this time...
I've already increased my testing coverage on one of the build machines
now to actually test redirecting v4/v6 gateway, over v4/v6 connections,
and will add one more test machine that has no default route, with the
same test cases - so, hopefully, preventing this from ever happening
again)

thanks for testing & reporting.

gert


-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-04 Thread Gert Doering
Hi again,

On Fri, Oct 02, 2020 at 03:26:29PM +0200, François Kooman wrote:
> After testing connecting over native IPv6 to the VPN server, it turns 
> out the IPv4 traffic is not routed over the VPN. This worked in older 
> versions of OpenVPN (2.4.x) but no longer in OpenVPN 2.5rc2. I am 
> testing with Windows 8.1, but the same was reported on Windows 10.

Antonio has reviewed the fix, and I have just pushed out new master
and release/2.5 trees with this.

If you build your own openvpn, I'd appreciate quick feedback :-) - otherwise,
we'll release a RC3 "this week", so you can test this with pre-built
binaries as well.

Thanks again for the report.

gert


-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


  1   2   3   4   5   6   7   8   9   10   >