Re: [Openvpn-devel] [PATCH 3/3] Implement tls-groups option to specify eliptic curves/groups

[Antonio Quartulli]

Hi,

this patch looks pretty simple and easy to digest.

However, there are several style things which are odd. See below:

On 01/04/2020 12:21, Arne Schwabe wrote:
> OpenSSL 1.1+ by default only allows signatures and key exchange from the
> default list of X25519:secp256r1:X448:secp521r1:secp384r1. Since in
> TLS1.3 key exchange is independent from the signature/key of the
> certificates, allowing all groups per default is not a sensible choice
> anymore and the shorter lister is reasonable.
> 
> However, when using certificates with exotic curves the signatures of
> this certificates will no longer be accepted. This option allows to
> modify the list for these corner cases.

there are some errors in the commit message, but they can probably be
fixed at merge time.


> 
> Signed-off-by: Arne Schwabe 
> ---
>  README.ec|   7 +--
>  doc/openvpn.8|  37 +++--
>  src/openvpn/openssl_compat.h |   4 ++
>  src/openvpn/options.c|  10 +++-
>  src/openvpn/options.h|   1 +
>  src/openvpn/ssl.c|   6 +++
>  src/openvpn/ssl_backend.h|  10 
>  src/openvpn/ssl_mbedtls.c|  47 
>  src/openvpn/ssl_mbedtls.h|   1 +
>  src/openvpn/ssl_openssl.c| 101 +++
>  10 files changed, 194 insertions(+), 30 deletions(-)
> 
> diff --git a/README.ec b/README.ec
> index 32938017..2f830972 100644
> --- a/README.ec
> +++ b/README.ec
> @@ -12,14 +12,15 @@ OpenVPN 2.4.0 and newer automatically initialize ECDH 
> parameters. When ECDSA is
>  used for authentication, the curve used for the server certificate will be 
> used
>  for ECDH too. When autodetection fails (e.g. when using RSA certificates)
>  OpenVPN lets the crypto library decide if possible, or falls back to the
> -secp384r1 curve.
> +secp384r1 curve. The list of groups/curves that the crypto library will 
> choose
> +from can be set with the --tls-groups  configuration.
>  
>  An administrator can force an OpenVPN/OpenSSL server to use a specific curve
>  using the --ecdh-curve  option with one of the curves listed as
> -available by the --show-curves option. Clients will use the same curve as
> +available by the --show-groups option. Clients will use the same curve as
>  selected by the server.
>  
> -Note that not all curves listed by --show-curves are available for use with 
> TLS;
> +Note that not all curves listed by --show-groups are available for use with 
> TLS;
>  in that case connecting will fail with a 'no shared cipher' TLS error.
>  
>  Authentication (ECDSA)
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index c5b16981..4897fbdb 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -5084,11 +5084,11 @@ simply supplied to the crypto library.  Please see 
> the OpenSSL and/or mbed TLS
>  documentation for details on the cipher list interpretation.
>  
>  For OpenSSL, the
> -.B \-\-tls-cipher
> +.B \-\-tls\-cipher

Why not fixing these issues in a separate patch? (my opinion)

>  is used for TLS 1.2 and below. For TLS 1.3 and up, the
>  .B \-\-tls\-ciphersuites
>  setting is used. mbed TLS has no TLS 1.3 support yet and only the
> -.B \-\-tls-cipher
> +.B \-\-tls\-cipher

same

>  setting is used.
>  
>  Use
> @@ -5096,6 +5096,8 @@ Use
>  to see a list of TLS ciphers supported by your crypto library.
>  
>  Warning!
> +.B \-\-tls\-groups
> +,
>  .B \-\-tls\-cipher
>  and
>  .B \-\-tls\-ciphersuites
> @@ -5111,6 +5113,33 @@ OpenSSL.
>  The default for \-\-tls\-ciphersuites is to use the crypto library's default.
>  .\"*
>  .TP
> +.B \-\-tls\-groups l
> +A list
> +.B l
> +of allowable groups/curves in order of preference.
> +
> +Set the allowed elictipic curves/groups for the TLS session.

   ^^ typ0

> +These groups are  allowed to be used in signatures and key exchange.
> +
> +mbed TLS currently allows all known curves per default.
> +
> +OpenSSL 1.1+ restricts the list per default to
> +"X25519:secp256r1:X448:secp521r1:secp384r1".
> +
> +If you use certificates that use non-standard curves, you
> +might need to add them here. If you do not force the ecdh curve
> +by using
> +.B \-\-ecdh\-curve
> +, the groups for ecdh will also be picked from this list.
> +
> +OpenVPN maps the curve name secp256r1 to prime256v1 to allow
> +specifying the tls-groups option for mbed TLS and OpenSSL.
> +
> +Warning: this option not only affects eliptic curve certificates
> +but also the key exchange in TLS 1.3 and using this option improperly
> +will disable TLS 1.3.
> +.\"*
> +.TP
>  .B \-\-tls\-cert\-profile profile
>  Set the allowed cryptographic algorithms for certificates according to
>  .B profile\fN.
> @@ -5876,8 +5905,10 @@ engines supported by the OpenSSL library.
>  .TP
>  .B \-\-show\-curves
>  (Standalone)
> -Show all available elliptic curves to use with the
> +Show all available elliptic groups/curves to use 

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

[David Sommerseth]

On 14/04/2020 20:52, Juliusz Sosinowicz wrote:
> diff --git a/src/openvpn/cryptoapi.c b/src/openvpn/cryptoapi.c
> index 30eba7b2..a82c52ad 100644
> --- a/src/openvpn/cryptoapi.c
> +++ b/src/openvpn/cryptoapi.c
> @@ -39,6 +39,10 @@
>  
>  #ifdef ENABLE_CRYPTOAPI
>  
> +#ifdef ENABLE_CRYPTO_WOLFSSL
> +#error wolfSSL does not support CryptoAPI
> +#endif
> +

Except of the documentation effect, wouldn't it be better to handle that in
syshead.h instead?

In syshead.h, I see this:
--
#if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL)
#define ENABLE_CRYPTOAPI
#endif
--

This is the only place I could find defining this macro.  So extending it with
&& !defined(ENABLE_CRYPTO_WOLFSSL) would eliminate the need to worry about the
ENABLE_CRYPTOAPI elsewhere.

Has this patch been tested against Windows builds with WolfSSL enabled, like
via mingw?


-- 
kind regards,

David Sommerseth
OpenVPN Inc




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

Re: [Openvpn-devel] [PATCH] Fix broken async push with NCP is used

[Arne Schwabe]

Am 13.03.20 um 17:59 schrieb Lev Stipakov:
> From: Lev Stipakov 
> 
> With NCP and deferred auth, we perform cipher negotiation and
> generate data channel keys on incoming push request, assuming that auth
> succeeded. With async push, when auth succeeds in between push requests,
> we send push reply immediately.
> 
> The code which generates data channel keys is only called on handling incoming
> push requests (incoming_push_message). It might not be called with NCP,
> deferred auth and async push because on incoming push request auth might not
> be complete yet. When auth is complete in between push requests, push reply
> is sent and it is assumed that connection is established. However, since data 
> channel keys
> are not generated on the server side, connection doesn't work.
> 
> Fix by generating data channel keys when async push is triggered.
> 
> Reported-by: smaxfi...@duosecurity.com
> Signed-off-by: Lev Stipakov 
> ---
>  src/openvpn/init.c  |  6 ++
>  src/openvpn/multi.c | 24 +++-
>  src/openvpn/push.c  |  6 ++
>  src/openvpn/ssl.c   |  6 ++
>  src/openvpn/ssl.h   |  5 +++--
>  5 files changed, 36 insertions(+), 11 deletions(-)
> 
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 824b6667..b3096dc8 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -2343,10 +2343,8 @@ do_deferred_options(struct context *c, const unsigned 
> int found)
>  }
>  #endif
>  
> -/* Do not regenerate keys if server sends an extra push reply */
> -if (!session->key[KS_PRIMARY].crypto_options.key_ctx_bi.initialized
> -&& !tls_session_update_crypto_params(session, &c->options, 
> &c->c2.frame,
> - frame_fragment))
> +if (!tls_session_update_crypto_params(session, &c->options, 
> &c->c2.frame,
> +  frame_fragment))
>  {
>  msg(D_TLS_ERRORS, "OPTIONS ERROR: failed to import crypto 
> options");
>  return false;
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index da0aeeba..b42bcec9 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -2137,8 +2137,30 @@ multi_process_file_closed(struct multi_context *m, 
> const unsigned int mpp_flags)
>  {
>  if (mi)
>  {
> -/* continue authentication and send push_reply */
> +/* continue authentication, perform NCP negotiation and send 
> push_reply */
>  multi_process_post(m, mi, mpp_flags);
> +
> +/* With NCP and deferred authentication, we perform cipher 
> negotiation and
> + * data channel keys generation on incoming push request, 
> assuming that auth
> + * succeeded. When auth succeeds in between push requests 
> and async push is used,
> + * we send push reply immediately. Above 
> multi_process_post() call performs
> + * NCP negotiation and here we do keys generation. */
> +
> +struct context *c = &mi->context;
> +struct frame *frame_fragment = NULL;
> +#ifdef ENABLE_FRAGMENT
> +if (c->options.ce.fragment)
> +{
> +frame_fragment = &c->c2.frame_fragment;
> +}
> +#endif
> +struct tls_session *session = 
> &c->c2.tls_multi->session[TM_ACTIVE];
> +if (!tls_session_update_crypto_params(session, &c->options,
> +  &c->c2.frame, 
> frame_fragment))
> +{
> +msg(D_TLS_ERRORS, "TLS Error: initializing data channel 
> failed");
> +register_signal(c, SIGUSR1, "init-data-channel-failed");
> +}

I am not happy to see this code fragment being copied here and having
the same code now three times almost identical.

This is the point where we should put it into its own fuction.



Otherwise the code looks good.
So

Semi-Acked-By: Arne Schwabe 


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

Re: [Openvpn-devel] [PATCH] Document some limitations of --auth-user-pass

[Gert Doering]

Hi,

On Fri, Mar 13, 2020 at 03:01:33PM +0200, sam...@openvpn.net wrote:
> From: Samuli Seppänen 
> 
> URL: https://community.openvpn.net/openvpn/ticket/757
> Signed-off-by: Samuli Seppänen 
> ---

I'm going to mark that patch in patchwork as "changes requested",
given that Selva changed the issue towards "if this happens, 
we'll just ignore the stored username and ask management for both 
user+password".

Not sure if we still need a documentation patch, but if we want one,
it will have to be different text :)

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 applied] Re: Skip expired certificates in Windows certificate store

[Gert Doering]

Hi,

On Wed, Apr 15, 2020 at 02:22:15PM -0400, Selva Nair wrote:
> > is this one and aa6affe6df811db11577847366a569def0a3e314 also material
> > for release/2.4?  So "feature" or "bug" category?
> 
> Yes it would be good to get this one and aa6affe into 2.4. This one
> will cherry-pick with a minor conflict in cryptoapicert.c, easily
> resolved. aa6affe should cherry-pick with no issues.

That conflict was trivial indeed.  I fixed an occurrance of "else {"
while at it (whitespace only).

Test built on Ubuntu/MinGW, not actually tested the resulting binary.

Cursory review of the code also does not reveal anything unexpected.


commit 5f8a9df1eea33c2d6fc267e5e3683449954c986b (HEAD -> release/2.4)
Author: Selva Nair 
Date:   Wed Feb 12 10:06:07 2020 -0500

Allow unicode search string in --cryptoapicert option
(cherry picked from commit aa6affe6df811db11577847366a569def0a3e314)

commit 4658b3b6f6008eea1819ea26a46fd46df87b1030
Author: Selva Nair 
Date:   Wed Feb 12 10:06:06 2020 -0500

Skip expired certificates in Windows certificate store
(cherry picked from commit 7b63984d51a2582ba2d406e46a7debb11df7f478)

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] Set the correct mtu on windows based systems

[Gert Doering]

Hi,

On Thu, Apr 04, 2019 at 01:16:56PM +0200, Christopher Schenk wrote:
> Signed-off-by: Christopher Schenk 
> ---
>  include/openvpn-msg.h |  8 
>  src/openvpn/tun.c | 89 +++
>  src/openvpnserv/interactive.c | 31 
>  3 files changed, 128 insertions(+)

So, we have this nice patch, and I got a very pointed reminder today
that I messed merging it up.

The patch has an ACK, so everything is good, but Lev and Simon whacked
tun.c a lot in between, and someone else added message types, so it does
not apply anymore.

Applying: Set the correct mtu on windows based systems
error: patch failed: include/openvpn-msg.h:39
error: include/openvpn-msg.h: patch does not apply
error: patch failed: src/openvpn/tun.c:984
error: src/openvpn/tun.c: patch does not apply
error: patch failed: src/openvpnserv/interactive.c:1198
error: src/openvpnserv/interactive.c: patch does not apply
Patch failed at 0001 Set the correct mtu on windows based systems


Would you accept an apology for me dragging my feet on this for so long,
and send a rebased v3 to current master?

(And if that does not get traction, feel free to send Max my way on
a weekly basis)

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 applied] Re: Skip expired certificates in Windows certificate store

[Selva Nair]

Hi,

> is this one and aa6affe6df811db11577847366a569def0a3e314 also material
> for release/2.4?  So "feature" or "bug" category?

Yes it would be good to get this one and aa6affe into 2.4. This one
will cherry-pick with a minor conflict in cryptoapicert.c, easily
resolved. aa6affe should cherry-pick with no issues.

Selva


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

Re: [Openvpn-devel] [PATCH applied] Re: Skip expired certificates in Windows certificate store

[Gert Doering]

Hi,

is this one and aa6affe6df811db11577847366a569def0a3e314 also material
for release/2.4?  So "feature" or "bug" category?

(I've left this sit in my inbox and also in patchwork to remind me that
I wanted to clarify this, and then never got around to actually do so)

gert


On Thu, Feb 13, 2020 at 08:54:18PM +0100, Gert Doering wrote:
> Your patch has been applied to the master branch.
> 
> Haven't done any real testing, just test build on MinGW (to have "the
> other build environment").  Passes :-)
> 
> commit 7b63984d51a2582ba2d406e46a7debb11df7f478
> Author: Selva Nair
> Date:   Wed Feb 12 10:06:06 2020 -0500
> 
>  Skip expired certificates in Windows certificate store
> 
>  Signed-off-by: Selva Nair 
>  Acked-by: Lev Stipakov 
>  Message-Id: <1581519967-16950-1-git-send-email-selva.n...@gmail.com>
>  URL: 
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19404.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
> 

-- 
"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 applied] Fix possible access of uninitialized pipe handles

[Gert Doering]

Hi,

On Thu, Feb 20, 2020 at 07:21:24PM -0500, Selva Nair wrote:
> On Thu, Feb 20, 2020 at 1:20 PM David Sommerseth  wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Your patch has been applied to the master branch
> >
> > commit 32723d29b2775d63d3fe329d017e7a08e0cdcb72
> > Author: Selva Nair
> > Date:   Wed Feb 19 20:56:43 2020 -0500
> 
> I think this and next one could also go into 2.4.
> 
> Here are the commits, in case
> .
> 32723d29b2775d63d3fe329d017e7a08e0cdcb72
> e1f7d7885752ac3a0279ecc7e31ccee2af40fbe4

And so it has been done - sorry for the delay (and feel free to remind
me occasionally if things seem to get stuck).

I have test built both on Ubuntu/MinGW, and also done a cursory "does
the commits look reasonable?" check - trivial enough.


commit df5ea7f1b87012414d2625d1562715887ad1686d (HEAD -> release/2.4)
Author: Selva Nair 
Date:   Wed Feb 19 20:56:43 2020 -0500

Fix possible access of uninitialized pipe handles
(cherry picked from commit 32723d29b2775d63d3fe329d017e7a08e0cdcb72)

commit 1d9e0be2a7733b0efb0556d187a36912606a9d97
Author: Selva Nair 
Date:   Wed Feb 19 19:49:37 2020 -0500

Fix possibly uninitialized return value in GetOpenvpnSettings()
(cherry picked from commit e1f7d7885752ac3a0279ecc7e31ccee2af40fbe4)

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] Fix illegal client float

[Antonio Quartulli]

Hi,

On 15/04/2020 11:32, Arne Schwabe wrote:
> Am 15.04.20 um 09:30 schrieb Lev Stipakov:
>> From: Lev Stipakov 
>>
>> There is a time frame between allocating peer-id and initializing data
>> channel key, which is performed on receiving push request.
>>
>> If a "rogue" data channel packet arrives during that time frame from
>> another address and  with same peer-id, this would cause client to float
>> to that new address. This is because:
>>
>>  - tls_pre_decrypt() sets packet length to zero if
>>data channel key has not been initialized, which leads to
>>
>>  - openvpn_decrypt() returns true if packet length is zero,
>> which leads to
>>
>>  - process_incoming_link_part1() returns true, which
>> calls multi_process_float(), which commits float
>>
>> Note that problem doesn't happen when data channel key
>> is initialized, since in this case openvpn_decrypt() returns false.
>>
>> Fix illegal float by adding buffer length check before calling
>> multi_process_float().
>>
>> This should fix Trac #1272.
>>
>> Signed-off-by: Lev Stipakov 
>> ---
>>  v2: add comment explaning why nonzero check needed
>>
>>  src/openvpn/multi.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
>> index da0aeeba..37d2a6f2 100644
>> --- a/src/openvpn/multi.c
>> +++ b/src/openvpn/multi.c
>> @@ -2555,7 +2555,8 @@ multi_process_incoming_link(struct multi_context *m, 
>> struct multi_instance *inst
>>  orig_buf = c->c2.buf.data;
>>  if (process_incoming_link_part1(c, lsi, floated))
>>  {
>> -if (floated)
>> +/* nonzero length means that we have a valid, decrypted 
>> packed */
>> +if (floated && c->c2.buf.len > 0)
>>  {
>>  multi_process_float(m, m->pending);
>>  }
>>
> Thanks!
> 
> Acked-By: Arne Schwabe 

just went through the entire flow with Lev and David and this all makes
a lot of sense now. Couldn't come up with a better fix for this issue.


Acked-by: Antonio Quartulli 



-- 
Antonio Quartulli


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

Re: [Openvpn-devel] Summary of the community meeting (15th April 2020) -- Win installer version checks

[Gert Doering]

Hi,

On Wed, Apr 15, 2020 at 11:52:50AM -0400, Nathan Stratton Treadway wrote:
> (Of course, even better from a user standpoint would be a single unified
> OpenVPN Windows installer which automatically installs the
> correctly-signed drivers for the current system -- but I assume that
> approach has already been investigated/considered earlier in the
> development of the Windows installer)

From my understanding, the upcoming 2.5 MSI installer should do this
(a single .msi which contains all the individual packages needed for
all plattforms and architectures).

For the NSIS installer, this seems to be not so trivial, and since we
wanted to move away from it anyway, nobody volunteered to implement and
test it yet... but indeed, it would be nice to have, so *if* we have
a volunteer, this would be certainly welcome :-)

(*I* have no idea about windows installers, I'm a *BSD person)

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] Summary of the community meeting (15th April 2020) -- Win installer version checks

[Nathan Stratton Treadway]

On Wed, Apr 15, 2020 at 13:38:37 +0300, Samuli Seppänen wrote:
> 
> Here's the summary of the IRC meeting.
> 
> ---
> 
> COMMUNITY MEETING
> 
> Place: #openvpn-meeting on irc.freenode.net
> Date: Wed 15th April 2020
> Time: 11:30 CEST (09:30 UTC)
> 
[...]
> 
> Mattock will check if it would be possible to give unique identifiers to
> Windows 7 and Windows 10 flavors of tap-windows6. This would prevent
> situations where an existing, cached Windows 7 driver is preferred over
> a Windows 10 (attestation signed) version, hence causing driver
> installation failures.
> 
> Mattock will also check if we could, with a reasonable effort, provide
> users with an easy way to clean up old tap-windows6 drivers in the NSIS
> installer. The process is already known and can be done with external
> scripts, but integration / reimplementation in NSIS is missing.

Just wanted to be sure that the separate-but-related step of having the
Windows installer verify the Windows version at install time is also on
the list for investigation.  

In our particular case, at least, if the Win7 installer had refused to
proceed when executed under Win10, the situation with TAP driver
mismatch would have been avoided completely.  If it's possible to do,
that seems a preferable outcome, even if the steps mentioned above also
make it much easier to recover from the mismatch situation after the
fact.

(Of course, even better from a user standpoint would be a single unified
OpenVPN Windows installer which automatically installs the
correctly-signed drivers for the current system -- but I assume that
approach has already been investigated/considered earlier in the
development of the Windows installer)

Thanks.

Nathan




Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


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

Re: [Openvpn-devel] [PATCH 2/3] Refactor counting number of element in a : delimited list into function

[Antonio Quartulli]

Hi,

On 01/04/2020 12:21, Arne Schwabe wrote:
> ---
>  src/openvpn/misc.c| 18 ++
>  src/openvpn/misc.h| 13 +
>  src/openvpn/ssl_mbedtls.c | 15 ++-
>  3 files changed, 33 insertions(+), 13 deletions(-)
> 
> diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
> index 1931149b..b375451f 100644
> --- a/src/openvpn/misc.c
> +++ b/src/openvpn/misc.c
> @@ -735,4 +735,22 @@ output_peer_info_env(struct env_set *es, const char 
> *peer_info)
>  }
>  }
>  
> +int get_num_elements(const char* string, char delimiter)
> +{
> +  int string_len = strlen(string);
> +
> +  ASSERT(0 != string_len);
> +
> +  int element_count = 1;
> +  /* Get number of ciphers */
> +  for (int i = 0; i < string_len; i++)
> +{
> +  if (string[i] == delimiter)
> +{
> +  element_count++;
> +}
> +}

while copying this code you are breaking the indentation. note that 2
blanks before the curly brackets. that's nt supposed to be there.


> +
> +  return element_count;
> +}
>  #endif /* P2MP_SERVER */
> diff --git a/src/openvpn/misc.h b/src/openvpn/misc.h
> index 991b7df2..0655b7fe 100644
> --- a/src/openvpn/misc.h
> +++ b/src/openvpn/misc.h
> @@ -175,4 +175,17 @@ void output_peer_info_env(struct env_set *es, const char 
> *peer_info);
>  
>  #endif /* P2MP_SERVER */
>  
> +/**
> + * Counts the number of delimiter in a string and returns
> + * their number +1. 

I'd rephrase this sentence as:

Returns the occurrences of 'delimiter' in 'string' +1.

> This is typically used to find out the
> + * number elements in a cipher string or similar that is separated by : like
> + *
> + *   X25519:secp256r1:X448:secp512r1:secp384r1:brainpoolP384r1
> + *
> + * @param stringthe string to work on
> + * @param delimiter the delimiter to count, typically ':'
> + * @return  number of delimiter found + 1

  I'd change to "occurrences of 'delimiter' +1"

> + */
> +int
> +get_num_elements(const char* string, char delimiter);
>  #endif /* ifndef MISC_H */
> diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
> index 0f0b035b..0e17e734 100644
> --- a/src/openvpn/ssl_mbedtls.c
> +++ b/src/openvpn/ssl_mbedtls.c
> @@ -289,33 +289,22 @@ void
>  tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers)
>  {
>  char *tmp_ciphers, *tmp_ciphers_orig, *token;
> -int i, cipher_count;
> -int ciphers_len;
>  
>  if (NULL == ciphers)
>  {
>  return; /* Nothing to do */
> -
>  }
> -ciphers_len = strlen(ciphers);
>  
>  ASSERT(NULL != ctx);
> -ASSERT(0 != ciphers_len);
>  
>  /* Get number of ciphers */
> -for (i = 0, cipher_count = 1; i < ciphers_len; i++)
> -{
> -if (ciphers[i] == ':')
> -{
> -cipher_count++;
> -}
> -}
> +int cipher_count = get_num_elements(ciphers, ':');
>  
>  /* Allocate an array for them */
>  ALLOC_ARRAY_CLEAR(ctx->allowed_ciphers, int, cipher_count+1)
>  
>  /* Parse allowed ciphers, getting IDs */
> -i = 0;
> +int i = 0;
>  tmp_ciphers_orig = tmp_ciphers = string_alloc(ciphers, NULL);
>  
>  token = strtok(tmp_ciphers, ":");
> 

Other than my little nitpicks above, the patch looks good.
However, I have a question.

Since you are refactoring this code and this is going to master/2.5, why
not reimplementing the get_num_elements() function using strtok() ?


Regards,

-- 
Antonio Quartulli


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

Re: [Openvpn-devel] [PATCH v2 4/5] Implement sending SSO challenge to clients

[Arne Schwabe]

Am 27.03.20 um 22:09 schrieb David Sommerseth:
> On 09/11/2019 16:13, Arne Schwabe wrote:
>> This implements sending AUTH_PENDING and INFO_PRE messages to clients
>> that indicate that the clients should be continue authentication with
>> a second factor. This can currently be out of band (openurl) or a normal
>> challenge/response 2FA like TOTP (CR_TEXT).
>>
>> Signed-off-by: Arne Schwabe 
>> ---
>>  doc/management-notes.txt | 26 +++
>>  src/openvpn/manage.c | 46 
>>  src/openvpn/manage.h |  3 +++
>>  src/openvpn/multi.c  | 19 +
>>  src/openvpn/push.c   | 24 +
>>  src/openvpn/push.h   |  2 ++
>>  6 files changed, 120 insertions(+)
> 
> Code and management notes looks reasonable.  But again, it would be good to
> have a way to test this properly to avoid regressions later on.  Since this is
> also a more advanced authentication method, having good test methods is even
> more critical.

Writing a complete framework to test management interface on the server
side is something that would a huge undertaking for this simple patch.

I think Access Server is basically the only software that I am aware of
that really uses the server side management interface.

So basically having this requirement right now of writing a testing
suite to get this into OpenVPN will mean that we will effectively fork
OpenVPN for AS.

Arne



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

[Openvpn-devel] Summary of the community meeting (15th April 2020)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 15th April 2020
Time: 11:30 CEST (09:30 UTC)

Planned meeting topics for this meeting were here:



Your local meeting time is easy to check from services such as



SUMMARY

cron2, lev, mattock, ordex and plaisthos participated in this meeting.

---

Talked about the WolfSSL patches. Agreed that they're much less invasive
and hence more acceptable now than previously. Some changes were
requested earlier and we're waiting for WolfSSL's response.

---

Talked about the upcoming OpenVPN 2.4.9 release. It will include an
important security fix and a few other things we wish to get in:

- NCP async fix from lev
- two patches from Selva
- the ecliptic curve patch (1/3)

Agreed that we should have a CVE for the security issue. Dazo had
promised to resurface at 14:00 CEST today, which means he can probably
handle the CVE generation as usual.

Our goal is to release 2.4.9 tomorrow, if possible.

---

Mattock will check if it would be possible to give unique identifiers to
Windows 7 and Windows 10 flavors of tap-windows6. This would prevent
situations where an existing, cached Windows 7 driver is preferred over
a Windows 10 (attestation signed) version, hence causing driver
installation failures.

Mattock will also check if we could, with a reasonable effort, provide
users with an easy way to clean up old tap-windows6 drivers in the NSIS
installer. The process is already known and can be done with external
scripts, but integration / reimplementation in NSIS is missing.

These changes would be nice to have in 2.4.9-I601, but we can postpone
them to another Windows installer release if needed.

--

Full chatlog attached
(12:31:17) mattock: meeting time
(12:31:21) cron2: hooray
(12:31:25) lev__: hello
(12:31:54) mattock: hi guys!
(12:32:27) plaisthos: hey!
(12:34:27) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2020-04-15
(12:34:51) plaisthos: Okay I will just start with one topic, the quality of the 
WolfSSL patch approaches a level that might consider it for inclusion
(12:35:36) plaisthos: but I would put a note there that it is in the not 
actively supported by the community project and bugs/problem with it that 
cannot replicated with OpenSSL need to be reported to WolfSSL
(12:35:40) ordex: hi
(12:35:46) plaisthos: hey ordex 
(12:36:18) ordex: well, issues will be reported to our mailing list in any case
(12:36:33) ordex: we just have to ensure that wolfssl will stick to the list
(12:37:05) cron2: I am fine with merging the patch, as it has nearly no code 
changes anymore, just pushing autoconf towards "yes, this function is there, 
even if it's a macro and you can't see it"
(12:37:32) ordex: yup
(12:37:35) ordex: much better
(12:37:36) cron2: and yes, documentation needs to be clear "this is not 
something we test, so if there are problems, talk to WolfSSL"
(12:38:24) ordex: can't the cryptoapi check be performed at configure time ?
(12:38:29) ordex: why an #error in the code ?
(12:39:38) cron2: ENABLE_CRYPTOAPI is not coming "from configure" but from 
syshead.h
(12:39:44) plaisthos: it basically breaks the build on win32
(12:39:48) cron2: but I think the #error is more an extra saveguard, because
(12:39:53) cron2: #if defined(_WIN32) && defined(ENABLE_CRYPTO) && 
defined(ENABLE_CRYPTO_OPENSSL)
(12:39:56) cron2: #define ENABLE_CRYPTOAPI
(12:39:59) cron2: #endif
(12:39:59) cron2: oh
(12:40:06) ordex: ah, so it's a windows thing only
(12:40:21) plaisthos: yeah cryptoapi is the windows key sotre
(12:40:23) ordex: but it needs ENABLE_CRYPTO_OPENSSL
(12:40:30) ordex: which on't be the case with WOLFSSL, no ?
(12:40:48) cron2: mmmh, now if WolfSSL enables ENABLE_CRYPTO_OPENSSL, which I 
think it needs to do (otherwise, we won't compile the openssl stuff...), it 
will break windows builds
(12:40:51) plaisthos: ah yes
(12:41:12) ordex: ah
(12:41:19) cron2: ssl_openssl.c is guarded by "#if defined(ENABLE_CRYPTO) && 
defined(ENABLE_CRYPTO_OPENSSL)"
(12:41:26) cron2: and WolfSSL provides "openssl compat" headers + API
(12:41:45) plaisthos: yeah basically wolfssl is not working on win32
(12:41:51) ordex: yeah
(12:41:56) plaisthos: something that I can live with
(12:41:58) cron2: I think that #error is not good.  They should adjust 
syshead.h instead, and have an extra WolfSSL check there
(12:42:03) ordex: right
(12:42:15) ordex: like: #if defined(_WIN32) && defined(ENABLE_CRYPTO) && 
defined(ENABLE_CRYPTO_OPENSSL) && !defined(ENABLE_CRYPTO_WOLFSSL)
(12:42:17) ordex: no ?
(12:42:20) plaisthos: cron2: I think the cryptoapi stuff might be called in 
more places
(12:42:37) plaisthos: that might have the wrong ifdef or so
(12:42:38) cron2: plaisthos: it should all be wrapped with ENABLE_CRYPTOAPI
(12:42:51) cron2: so if we just not define it ("like when building with 
mbedtls")...
(12:43:05) plai

[Openvpn-devel] [PATCH applied] Re: Fix OpenSSL 1.1.1 not using auto ecliptic curve selection

[Gert Doering]

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

I've changed the title from "ecliptic" to "elliptic" curves, though :)

Haven't tested, but have stared at the actual change and the surrounding
code a bit, and hope that we can remove 1.0.x support soon... :-)

commit d8ac887c6b1b57a1953ab62058b4aed5d8c11f65 (master)
commit 5ee76a8fab0411c7529c8da9f40ad386433d9a0c (release/2.4)
Author: Arne Schwabe
Date:   Sat Mar 28 05:08:58 2020 +0100

 Fix OpenSSL 1.1.1 not using auto ecliptic curve selection

 Acked-by: Antonio Quartulli 
 Message-Id: <20200328040858.16505-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19630.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] Fix OpenSSL 1.1.1 not using auto ecliptic curve selection

[Antonio Quartulli]

Hi,

On 28/03/2020 05:08, Arne Schwabe wrote:
> Commit 8a01147ff attempted to avoid calling the deprecated/noop
> operation SSL_CTX_set_ecdh_auto by surrounding it with #ifdef.
> Unfortunately, that change also made the return; that would exit
> the function no longer being compiled when using OpenSSL 1.1.0+.
> As consequence OpenVPN with OpenSSL 1.1.0+ would always set
> secp384r1 as ecdh curve unless otherwise specified by ecdh
> 
> This patch restores the correct/previous behaviour.
> ---
>  src/openvpn/ssl_openssl.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 3f0031ff..4b5ca214 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -678,8 +678,11 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, const 
> char *curve_name
>  /* OpenSSL 1.0.2 and newer can automatically handle ECDH parameter
>   * loading */
>  SSL_CTX_set_ecdh_auto(ctx->ctx, 1);
> -return;
> +
> +/* OpenSSL 1.1.0 and newer have always ecdh auto loading enabled,
> + * so do nothing */
>  #endif
> +return;

my eyes want to fall when seeing this ifdef jungle...but that's another
topic.

The change makes sense, because for ossl >= 1.1.0 we only want to omit
the call to SSL_CTX_set_ecdh_auto() [no-op since 1.1.0], but the
codeflow should remain the same.

>  #else
>  /* For older OpenSSL we have to extract the curve from key on our 
> own */
>  EC_KEY *eckey = NULL;
> 


Acked-by: Antonio Quartulli 

-- 
Antonio Quartulli


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

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

[Gert Doering]

Hi,

as Arne said, this is much better.

On Tue, Apr 14, 2020 at 08:52:14PM +0200, Juliusz Sosinowicz wrote:
> This patch adds support for wolfSSL in OpenVPN. Support is added by using 
> wolfSSL's OpenSSL compatibility layer. Function calls are left unchanged and 
> instead the OpenSSL includes point to wolfSSL headers and OpenVPN is linked 
> against the wolfSSL library.
[..]

There is one thing, though:

> index 30eba7b2..a82c52ad 100644
> --- a/src/openvpn/cryptoapi.c
> +++ b/src/openvpn/cryptoapi.c
> @@ -39,6 +39,10 @@
>  
>  #ifdef ENABLE_CRYPTOAPI
>  
> +#ifdef ENABLE_CRYPTO_WOLFSSL
> +#error wolfSSL does not support CryptoAPI
> +#endif
> +

I do not like this very much.  It will, effectively, break win32 builds
with WolfSSL - and add yet another #ifdef to our .c files.

ENABLE_CRYPTOAPI is defined in syshead.h

#if defined(_WIN32) && defined(ENABLE_CRYPTO) && defined(ENABLE_CRYPTO_OPENSSL)
#define ENABLE_CRYPTOAPI
#endif

... could you investigate whether it would be sufficient to just 
conditionalize this on WolfSSL, like this?

#if defined(_WIN32) && defined(ENABLE_CRYPTO) && \
defined(ENABLE_CRYPTO_OPENSSL) && !defined(ENABLE_CRYPTO_WOLFSSL)
#define ENABLE_CRYPTOAPI
#endif

so you can have WolfSSL-linked binaries for Windows, just without
CryptoAPI support (as with mbedtls)...

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] Fix illegal client float

[Arne Schwabe]

Am 15.04.20 um 09:30 schrieb Lev Stipakov:
> From: Lev Stipakov 
> 
> There is a time frame between allocating peer-id and initializing data
> channel key, which is performed on receiving push request.
> 
> If a "rogue" data channel packet arrives during that time frame from
> another address and  with same peer-id, this would cause client to float
> to that new address. This is because:
> 
>  - tls_pre_decrypt() sets packet length to zero if
>data channel key has not been initialized, which leads to
> 
>  - openvpn_decrypt() returns true if packet length is zero,
> which leads to
> 
>  - process_incoming_link_part1() returns true, which
> calls multi_process_float(), which commits float
> 
> Note that problem doesn't happen when data channel key
> is initialized, since in this case openvpn_decrypt() returns false.
> 
> Fix illegal float by adding buffer length check before calling
> multi_process_float().
> 
> This should fix Trac #1272.
> 
> Signed-off-by: Lev Stipakov 
> ---
>  v2: add comment explaning why nonzero check needed
> 
>  src/openvpn/multi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index da0aeeba..37d2a6f2 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -2555,7 +2555,8 @@ multi_process_incoming_link(struct multi_context *m, 
> struct multi_instance *inst
>  orig_buf = c->c2.buf.data;
>  if (process_incoming_link_part1(c, lsi, floated))
>  {
> -if (floated)
> +/* nonzero length means that we have a valid, decrypted 
> packed */
> +if (floated && c->c2.buf.len > 0)
>  {
>  multi_process_float(m, m->pending);
>  }
> 
Thanks!

Acked-By: Arne Schwabe 


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

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

[Arne Schwabe]

Am 14.04.20 um 20:52 schrieb Juliusz Sosinowicz:
> This patch adds support for wolfSSL in OpenVPN. Support is added by using 
> wolfSSL's OpenSSL compatibility layer. Function calls are left unchanged and 
> instead the OpenSSL includes point to wolfSSL headers and OpenVPN is linked 
> against the wolfSSL library.
> 
> As requested by OpenVPN maintainers, this patch does not include 
> wolfssl/options.h on its own. By defining the macro EXTERNAL_OPTS_OPENVPN in 
> the configure script wolfSSL will include wolfssl/options.h on its own 
> (change added in https://github.com/wolfSSL/wolfssl/pull/2825). The patch 
> adds an option '--disable-wolfssl-options-h' in case the user would like to 
> supply their own settings file for wolfSSL.
> 

Thanks the patch is lot less intrusive then the last version. We will
have to discuss in our meeting under what condition we want to include
the patch. We might add a note or statement that the WolfSSL support in
OpenVPN is mainly developed and tested by WolfSSL itself or something
along these lines.

> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 453cb20a..73da5fa7 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -428,7 +428,7 @@ openvpn_decrypt_aead(struct buffer *buf, struct buffer 
> work,
>  tag_ptr = BPTR(buf);
>  ASSERT(buf_advance(buf, tag_size));
>  dmsg(D_PACKET_CONTENT, "DECRYPT MAC: %s", format_hex(tag_ptr, tag_size, 
> 0, &gc));
> -#if defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER < 0x10001040L
> +#if (defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER < 0x10001040L) 
> || defined(ENABLE_CRYPTO_WOLFSSL)
>  /* OpenSSL <= 1.0.1c bug requires set tag before processing ciphertext */
>  if (!EVP_CIPHER_CTX_ctrl(ctx->cipher, EVP_CTRL_GCM_SET_TAG, tag_size, 
> tag_ptr))
>  {

Are you sure that WolfSSL requires a workaround for old OpenSSL version
before 1.0.1d?

Arne



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

[Openvpn-devel] [PATCH v2] Fix illegal client float

[Lev Stipakov]

From: Lev Stipakov 

There is a time frame between allocating peer-id and initializing data
channel key, which is performed on receiving push request.

If a "rogue" data channel packet arrives during that time frame from
another address and  with same peer-id, this would cause client to float
to that new address. This is because:

 - tls_pre_decrypt() sets packet length to zero if
   data channel key has not been initialized, which leads to

 - openvpn_decrypt() returns true if packet length is zero,
which leads to

 - process_incoming_link_part1() returns true, which
calls multi_process_float(), which commits float

Note that problem doesn't happen when data channel key
is initialized, since in this case openvpn_decrypt() returns false.

Fix illegal float by adding buffer length check before calling
multi_process_float().

This should fix Trac #1272.

Signed-off-by: Lev Stipakov 
---
 v2: add comment explaning why nonzero check needed

 src/openvpn/multi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index da0aeeba..37d2a6f2 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2555,7 +2555,8 @@ multi_process_incoming_link(struct multi_context *m, 
struct multi_instance *inst
 orig_buf = c->c2.buf.data;
 if (process_incoming_link_part1(c, lsi, floated))
 {
-if (floated)
+/* nonzero length means that we have a valid, decrypted packed 
*/
+if (floated && c->c2.buf.len > 0)
 {
 multi_process_float(m, m->pending);
 }
-- 
2.24.1 (Apple Git-126)



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