[Openvpn-devel] Summary of the community meeting (27th Mar 2019)

[Samuli Seppänen]

...resending as I apparently tried to send this from my personal email
account.

---

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 27th March 2019
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:



The next meeting is scheduled to 3rd April 11:30 CEST.

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



SUMMARY

cron2, dazo, mattock, ordex, plaisthos and syzzer participated
in this meeting.

--

Discussed future meeting schedule:

https://doodle.com/poll/qbnsw7d4mvb5iysn#table

It was agreed to have weekly meetings which alternate between

- Wed 11:30 CET/CEST
- Thu 20:00 CET/CEST

This enables most developers, even those in the U.S., to participate in
the meetings every other week.

Next week's meeting will be on Wed at 11:30 CET/CEST. The meeting one
week from that will be on Thu at 20:00 CET/CEST.

--

Talked about OpenVPN's INSTALL file. Dazo will overhaul it as it
contains quite a bit of obsolete information.

--

Talked about OpenVPN's ChangeLog file in the "master" branch. It
contains essentially the same information as "git shortlog" but has not
been updated in two years and nobody had complained until now. Agreed to
remove that file from Git "master" as useless. It will still be present
in release branches where it is actually recreated at release time.

--

Discussed the OpenVPN T-shirts. Mattock sent T-shirts to most already.
Cron2, janjust and ecrist please (re?)send your postal address to
mattock and you will receive T-shirts as well.

--

Discussed tap-windows6 HLK testing. Fixing the HLK tests should be
"ready" and the work is in here:

https://github.com/sgstair/tap-windows6/tree/hlkwork
https://github.com/sgstair/tapdiag

We also have basic instructions from Stephen on how to run the HLK tests
(the tap-windows6-specific part, plus openvpn configs). So the plan now
is to start merging his work patch by patch and simultaneously start (or
rather, resume) setting up the HLK environment.

Mattock is fighting to get a real, physical Windows Server 2016 box for
running the WHQL compliance HLK tests, as a VM won't cut it for Microsoft.

--

Full chatlog attached.

(12:30:25) mattock2: hi
(12:30:47) dazo: hey!
(12:31:10) syzzer: hi!
(12:31:54) ordex: hi!
(12:31:58) ordex: plaisthos: !!
(12:32:55) cron2_: wooh!
(12:33:51) plaisthos: hey
(12:33:54) dazo: ordex got a strange way to say "hi" :-P
(12:34:30) cron2_: you can never have enough exclamation marks
(12:34:37) ordex: hehe
(12:34:45) dazo: !
(12:34:53) ordex: :D
(12:35:02) ordex: you're good for a couple of weeks now
(12:35:06) dazo: :-D
(12:35:24) cron2_: perfect.  Anything else on the agenda? :)
(12:36:00) dazo: https://www.compart.com/en/unicode/U+037E  this can be fun 
to inject into some code  april 1st coming soon!
(12:36:53) ordex: I don't have anything on my plate worth mentioning (no change 
since last week)
(12:37:40) mattock: so we have plenty of people here
(12:37:46) cron2_: so, meeting schedule... can we agree on biweekly alternating 
wed 11:30 / thu 21:00 ?
(12:38:02) mattock: hmm thu 21 CET/CEST?
(12:38:15) cron2_: ordex: was that 21:00 or 20:00?
(12:38:23) mattock: 21 CEST is too late for me
(12:38:32) mattock: 20:00 is ok-ish
(12:39:02) ordex: 8PM
(12:39:03) ordex: 20:00
(12:39:07) ordex: 8pm-9pm
(12:39:26) cron2_: ah, indeed, that was the problem with tuesday (that I'm just 
not here at tue 8pm) - good, 8pm
(12:39:39) ordex: I am checking
(12:40:06) ordex: yeah Thu 8PM
(12:40:40) syzzer: works for me :)
(12:40:55) cron2_: works for me
(12:41:14) ordex: cool
(12:41:17) mattock: ok good
(12:41:25) ordex: mattock1: was the only red tick, but he said it may be ok-ish
(12:41:28) mattock: that is fairly reasonable
(12:41:54) ordex: oky
(12:41:56) mattock: if we keep the meeting within 1 hour
(12:42:00) mattock: and I think we can
(12:42:04) ordex: I think we should stick to that
(12:42:14) ordex: if we keep this happening every week, 1h should be ok
(12:42:18) mattock: agreed
(12:42:21) ordex: as done so far
(12:42:35) dazo: agreed
(12:43:06) mattock: I'll will retroactively add this as a topic to 
https://community.openvpn.net/openvpn/wiki/Topics-2019-03-27
(12:43:08) vpnHelper: Title: Topics-2019-03-27 – OpenVPN Community (at 
community.openvpn.net)
(12:43:53) mattock: done
(12:44:03) mattock: wed 11:30, thu 20:00 CET/CEST
(12:44:13) syzzer: cool
(12:44:23) cron2_: good.  So, next week, still Wednesday 11:30 (because it was 
already announced) and then April 11 (Thu) 20:00?
(12:44:29) mattock: sounds good
(12:44:39) ordex: yap
(12:44:40) mattock: easy topics next? (4-5 in the updated topic list)
(12:45:00) ordex: next week me, dazo and plaisthos will be in the OpenvPN 
office in Ukraine, so I am not sure we'll have time to join
(12:45:27) ordex: it seems our agend

Re: [Openvpn-devel] [PATCH] Setting adapter mtu on windows systems

[Christopher Schenk]

Hi,

On 28/03/2019 16:00, Selva Nair wrote:

I would go a step further to say we should not add new features that
do not work when started using the interactive service.

Secondly, we should avoid the old style use of netsh and instead use the
iphelper API as far as possible. It should be possible to
set MTU using the SetIfEntry() or SetIpInterfaceEnrty() function -- I 
haven't

checked which one is appropriate here.


I agree on the point that we should add this functionality to the 
interactive service as well. So i modified the patch accordingly.
I also modified my patch so that it uses the SetIpInterfaceEnrty 
function instead of netsh.


---
diff --git a/include/openvpn-msg.h b/include/openvpn-msg.h
index 66177a21..f59c5a21 100644
--- a/include/openvpn-msg.h
+++ b/include/openvpn-msg.h
@@ -39,6 +39,7 @@ typedef enum {
 msg_del_block_dns,
 msg_register_dns,
 msg_enable_dhcp,
+    msg_set_mtu,
 } message_type_t;

 typedef struct {
@@ -117,4 +118,11 @@ typedef struct {
 interface_t iface;
 } enable_dhcp_message_t;

+typedef struct {
+    message_header_t header;
+    interface_t iface;
+    short family;
+    int mtu;
+} set_mtu_message_t;
+
 #endif /* ifndef OPENVPN_MSG_H_ */
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 48a8fdf7..9fe8444f 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -69,6 +69,10 @@ static void netsh_ifconfig(const struct 
tuntap_options *to,

    const in_addr_t netmask,
    const unsigned int flags);

+static void windows_set_mtu(const int iface_indey,
+                                short family,
+   const int mtu);
+
 static void netsh_set_dns6_servers(const struct in6_addr *addr_list,
    const int addr_len,
    const char *flex_name);
@@ -201,6 +205,63 @@ out:
 return ret;
 }

+static bool
+do_set_mtu_service(const struct tuntap *tt, const short family, const 
int mtu)

+{
+    DWORD len;
+    bool ret = false;
+    ack_message_t ack;
+    struct gc_arena gc = gc_new();
+    HANDLE pipe = tt->options.msg_channel;
+
+    set_mtu_message_t mtu_msg = {
+        .header = {
+            msg_set_mtu,
+            sizeof(set_mtu_message_t),
+            0
+        },
+        .iface = {.index = tt->adapter_index,.name = tt->actual_name },
+        .mtu = mtu,
+        .family = family
+    };
+
+    if (!send_msg_iservice(pipe, &mtu_msg, sizeof(mtu_msg), &ack, 
"Set_mtu"))

+    {
+        goto out;
+    }
+
+    if (family == AF_INET)
+    {
+        if (ack.error_number != NO_ERROR)
+        {
+            msg(M_NONFATAL, "TUN: setting IPv4 mtu using service 
failed: %s [status=%u if_index=%d]",
+                strerror_win32(ack.error_number, &gc), 
ack.error_number, mtu_msg.iface.index);

+        }
+        else
+        {
+            msg(M_INFO, "IPv4 MTU set to %d on interface %d using 
service", mtu, mtu_msg.iface.index);

+            ret = true;
+        }
+    }
+    else if (family == AF_INET6)
+    {
+        if (ack.error_number != NO_ERROR)
+        {
+            msg(M_NONFATAL, "TUN: setting IPv6 mtu using service 
failed: %s [status=%u if_index=%d]",
+                strerror_win32(ack.error_number, &gc), 
ack.error_number, mtu_msg.iface.index);

+        }
+        else
+        {
+            msg(M_INFO, "IPv6 MTU set to %d on interface %d using 
service", mtu, mtu_msg.iface.index);

+            ret = true;
+        }
+    }
+
+out:
+    gc_free(&gc);
+    return ret;
+}
+
 #endif /* ifdef _WIN32 */

 #ifdef TARGET_SOLARIS
@@ -984,6 +1045,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char 
*ifname, int tun_mtu,

 {
 do_address_service(true, AF_INET6, tt);
 do_dns6_service(true, tt);
+        do_set_mtu_service(tt, AF_INET6, tun_mtu);
 }
 else
 {
@@ -1000,6 +1062,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char 
*ifname, int tun_mtu,

 netsh_command(&argv, 4, M_FATAL);
 /* set ipv6 dns servers if any are specified */
 netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, 
ifname);

+        windows_set_mtu(tt->adapter_index, AF_INET6, tun_mtu);
 }

 /* explicit route needed */
@@ -1391,9 +1454,16 @@ do_ifconfig_ipv4(struct tuntap *tt, const char 
*ifname, int tun_mtu,

 case IPW32_SET_NETSH:
 netsh_ifconfig(&tt->options, ifname, tt->local,
    tt->adapter_netmask, 
NI_IP_NETMASK|NI_OPTIONS);

-
 break;
 }
+        if (tt->options.msg_channel)
+        {
+            do_set_mtu_service(tt, AF_INET, tun_mtu);
+        }
+        else
+        {
+            windows_set_mtu(tt->adapter_index, AF_INET, tun_mtu);
+        }
 }

 #else  /* if defined(TARGET_LINUX) */
@@ -5236,6 +5306,46 @@ out:
 return ret;
 }

+static void
+windows_set_mtu(const int iface_index, const short family,
+    const int mtu)
+{
+    DWORD err = 0;
+

[Openvpn-devel] [PATCH] Warn about insecure ciphers also in init_key_type

[Arne Schwabe]

With modern Clients and server initialising the crypto cipher later
and not when reading in the config, most users never the warning when
having selected BF-CBC in the configuration.

This patch adds the logic to print out warning to init_key_type.

Main reason for this patch is a personal experience with someone who was
strictly against putting 'cipher' into a config file because he did not
like hardcoding a cipher and "OpenVPN will do AES-GCM anyway" and thinks
that it is better to not have it in configuration even after told by me
that 15 year defaults might not be good anymore.

Signed-off-by: Arne Schwabe 
---
 src/openvpn/crypto.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index ff9dbfdc..8a92a8c1 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -736,6 +736,17 @@ crypto_max_overhead(void)
+max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH);
 }
 
+static void warn_insecure_key_type(const char* ciphername, const cipher_kt_t 
*cipher)
+{
+if (cipher_kt_insecure(cipher))
+{
+msg(M_WARN, "WARNING: INSECURE cipher (%s) with block size less than 
128"
+" bit (%d bit).  This allows attacks like SWEET32.  
Mitigate by "
+"using a --cipher with a larger block size (e.g. 
AES-256-CBC).",
+ciphername, cipher_kt_block_size(cipher)*8);
+}
+}
+
 /*
  * Build a struct key_type.
  */
@@ -763,6 +774,7 @@ init_key_type(struct key_type *kt, const char *ciphername,
 kt->cipher_length = keysize;
 }
 
+
 /* check legal cipher mode */
 aead_cipher = cipher_kt_mode_aead(kt->cipher);
 if (!(cipher_kt_mode_cbc(kt->cipher)
@@ -779,6 +791,10 @@ init_key_type(struct key_type *kt, const char *ciphername,
 {
 msg(M_FATAL, "Cipher '%s' not allowed: block size too big.", 
ciphername);
 }
+if(warn)
+{
+warn_insecure_key_type(ciphername, kt->cipher);
+}
 }
 else
 {
@@ -831,9 +847,10 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key,
 cipher_ctx_init(ctx->cipher, key->cipher, kt->cipher_length,
 kt->cipher, enc);
 
+const char* ciphername = 
translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher));
 msg(D_HANDSHAKE, "%s: Cipher '%s' initialized with %d bit key",
 prefix,
-translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher)),
+ciphername,
 kt->cipher_length *8);
 
 dmsg(D_SHOW_KEYS, "%s: CIPHER KEY: %s", prefix,
@@ -841,13 +858,7 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key,
 dmsg(D_CRYPTO_DEBUG, "%s: CIPHER block_size=%d iv_size=%d",
  prefix, cipher_kt_block_size(kt->cipher),
  cipher_kt_iv_size(kt->cipher));
-if (cipher_kt_insecure(kt->cipher))
-{
-msg(M_WARN, "WARNING: INSECURE cipher with block size less than 
128"
-" bit (%d bit).  This allows attacks like SWEET32.  Mitigate 
by "
-"using a --cipher with a larger block size (e.g. 
AES-256-CBC).",
-cipher_kt_block_size(kt->cipher)*8);
-}
+warn_insecure_key_type(ciphername, kt->cipher);
 }
 if (kt->digest && kt->hmac_length > 0)
 {
-- 
2.21.0



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

[Openvpn-devel] [PATCH applied] Re: docs: Update INSTALL

[Gert Doering]

Acked-by: Gert Doering 

Thanks.  Changes look reasonable.  I have *not* applied this to release/2.4
as I assume that stuff like "openssl version" and "configure output" will
look different, so it would bring in incorrect "improvements".  (Can you
do a 2.4 version as well, please? :) )

Your patch has been applied to the master branch.

commit 6099ab67122429c04d743443a50d258b11ac1f07
Author: David Sommerseth
Date:   Wed Mar 27 13:06:04 2019 +0100

 docs: Update INSTALL

 Signed-off-by: David Sommerseth 
 Acked-by: Gert Doering 
 Message-Id: <20190327120604.21101-1-dav...@openvpn.net>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18307.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] Setting adapter mtu on windows systems

[Selva Nair]

Hi,

On Fri, Mar 29, 2019 at 6:25 AM Christopher Schenk
 wrote:
>
> Hi,
>
> On 28/03/2019 16:00, Selva Nair wrote:
> > I would go a step further to say we should not add new features that
> > do not work when started using the interactive service.
> >
> > Secondly, we should avoid the old style use of netsh and instead use the
> > iphelper API as far as possible. It should be possible to
> > set MTU using the SetIfEntry() or SetIpInterfaceEnrty() function -- I
> > haven't
> > checked which one is appropriate here.
>
> I agree on the point that we should add this functionality to the
> interactive service as well. So i modified the patch accordingly.
> I also modified my patch so that it uses the SetIpInterfaceEnrty
> function instead of netsh.

Thanks for the update. Looks okay, but would prefer a version
sent out by git-send-email so that we can apply and test the patch.

Some minor comments below.

>
> ---
> diff --git a/include/openvpn-msg.h b/include/openvpn-msg.h
> index 66177a21..f59c5a21 100644
> --- a/include/openvpn-msg.h
> +++ b/include/openvpn-msg.h
> @@ -39,6 +39,7 @@ typedef enum {
>   msg_del_block_dns,
>   msg_register_dns,
>   msg_enable_dhcp,
> +msg_set_mtu,
>   } message_type_t;
>
>   typedef struct {
> @@ -117,4 +118,11 @@ typedef struct {
>   interface_t iface;
>   } enable_dhcp_message_t;
>
> +typedef struct {
> +message_header_t header;
> +interface_t iface;
> +short family;
> +int mtu;
> +} set_mtu_message_t;
> +
>   #endif /* ifndef OPENVPN_MSG_H_ */
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 48a8fdf7..9fe8444f 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -69,6 +69,10 @@ static void netsh_ifconfig(const struct
> tuntap_options *to,
>  const in_addr_t netmask,
>  const unsigned int flags);
>
> +static void windows_set_mtu(const int iface_indey,

iface_indey -> iface_index ?

> +short family,
> +   const int mtu);
> +
>   static void netsh_set_dns6_servers(const struct in6_addr *addr_list,
>  const int addr_len,
>  const char *flex_name);
> @@ -201,6 +205,63 @@ out:
>   return ret;
>   }
>
> +static bool
> +do_set_mtu_service(const struct tuntap *tt, const short family, const
> int mtu)
> +{
> +DWORD len;
> +bool ret = false;
> +ack_message_t ack;
> +struct gc_arena gc = gc_new();
> +HANDLE pipe = tt->options.msg_channel;
> +
> +set_mtu_message_t mtu_msg = {
> +.header = {
> +msg_set_mtu,
> +sizeof(set_mtu_message_t),
> +0
> +},
> +.iface = {.index = tt->adapter_index,.name = tt->actual_name },
> +.mtu = mtu,
> +.family = family
> +};
> +
> +if (!send_msg_iservice(pipe, &mtu_msg, sizeof(mtu_msg), &ack,
> "Set_mtu"))
> +{
> +goto out;
> +}
> +
> +if (family == AF_INET)
> +{
> +if (ack.error_number != NO_ERROR)
> +{
> +msg(M_NONFATAL, "TUN: setting IPv4 mtu using service
> failed: %s [status=%u if_index=%d]",
> +strerror_win32(ack.error_number, &gc),
> ack.error_number, mtu_msg.iface.index);
> +}
> +else
> +{
> +msg(M_INFO, "IPv4 MTU set to %d on interface %d using
> service", mtu, mtu_msg.iface.index);
> +ret = true;
> +}
> +}
> +else if (family == AF_INET6)
> +{
> +if (ack.error_number != NO_ERROR)
> +{
> +msg(M_NONFATAL, "TUN: setting IPv6 mtu using service
> failed: %s [status=%u if_index=%d]",
> +strerror_win32(ack.error_number, &gc),
> ack.error_number, mtu_msg.iface.index);
> +}

Though this repetition is fine with me and may be we do
the same in other similar contexts, cant we combine these
two cases into one by defining a string "IPv4" or "IPv6"
based on the value of family?

The same applies to windows_set_mtu() as well.

> +else
> +{
> +msg(M_INFO, "IPv6 MTU set to %d on interface %d using
> service", mtu, mtu_msg.iface.index);
> +ret = true;
> +}
> +}
> +
> +out:
> +gc_free(&gc);
> +return ret;
> +}
> +
>   #endif /* ifdef _WIN32 */
>
>   #ifdef TARGET_SOLARIS
> @@ -984,6 +1045,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char
> *ifname, int tun_mtu,
>   {
>   do_address_service(true, AF_INET6, tt);
>   do_dns6_service(true, tt);
> +do_set_mtu_service(tt, AF_INET6, tun_mtu);
>   }
>   else
>   {
> @@ -1000,6 +1062,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char
> *ifname, int tun_mtu,
>   netsh_command(&argv, 4, M_FATAL);
>   /* set ipv6 dns servers if any are specified */
>   netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len,
> ifname);
> +windows_set_mtu(tt->adapter_index, AF

Re: [Openvpn-devel] [PATCH] Setting adapter mtu on windows systems

[Gert Doering]

Hi,

On Fri, Mar 29, 2019 at 03:33:24PM -0400, Selva Nair wrote:
> > +else if (family == AF_INET6)
> > +{
> > +if (ack.error_number != NO_ERROR)
> > +{
> > +msg(M_NONFATAL, "TUN: setting IPv6 mtu using service
> > failed: %s [status=%u if_index=%d]",
> > +strerror_win32(ack.error_number, &gc),
> > ack.error_number, mtu_msg.iface.index);
> > +}
> 
> Though this repetition is fine with me and may be we do
> the same in other similar contexts, cant we combine these
> two cases into one by defining a string "IPv4" or "IPv6"
> based on the value of family?
> 
> The same applies to windows_set_mtu() as well.

Yes please,  Newer code already tries to do this (like most of the
service-related stuff calling a common function for ipv4-or-ipv6 stuff).

(We don't do this for the existing ifconfig orgy because it would not
really help readibility... but hopefully that one will get cleaned
up more thoroughly eventually)

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