Re: [Openvpn-devel] [PATCH] Deprecate --no-iv

[Gert Doering]

Hi,

On Wed, Dec 07, 2016 at 09:51:16PM +0100, Arne Schwabe wrote:
> > +- ``--no-iv`` is deprecated in 2.4 and will be remove in 2.5.
> 
> Typo: removed

Since I had not pushed it yet, I've changed Changes.rst to fix that,
and added your Acked-By:

The new commitish is now

commit 4969f0d6bba8a82d411f0700c2e8e4efbeccb6c8
Author: Steffan Karger 
Date:   Wed Dec 7 20:20:47 2016 +0100

Deprecate --no-iv

no other changes to the original patch.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Summary of today's (7th Dec 2016) IRC meeting

[Samuli Seppänen]

Hi,

Here's the summary of today's IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 7th Dec 2016
Time: 20:00 CET (19:00 UTC)

Planned meeting topics for this meeting were here:



The next meeting has been scheduled to a week from now (Wed 14th 
December), at the same time as today.


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



SUMMARY

cron, dazo, janjust, krzee, mattock, selvanair and syzzer participated 
in this meeting.


---

Discussed patchwork briefly:



Noted that patchwork has not yet been installed, and that will not 
change before 2.4.0 is out.


---

Discussed the OpenVPN 2.4_rc2 release:



Two problems have been found that need to be fixed for 2.4_rc2:

- systemd + --chroot is an unhappy combination
- the --mtu-disc option is  broken on server side

The first issue has a pending patch, and work on the second one has started.

---

Discussed the --no-iv option is OpenVPN. It was agreed that the 
performance gains (~1.5% with packet size of 1500 bytes) are not big 
enough to warrant keeping this (insecure) option around.


Syzzer sent a "deprecate --no-iv" patch to the list during the meeting.

---

Discussed OpenVPN 2.4 security audits by OSTIF.org and PIA:




These two organizations have so far been working on roughly the same 
goal without knowledge of each other. It was agreed that we should 
ensure that they remain in sync so that their work does not overlap too 
much.


---

Discussed the "great code reformatting" planned for OpenVPN 2.4_rc2. The 
reformatted code will follow the Allman style:




All tweaks to the coding style were documented on the above page.

Agreed to use the reformatting approach suggested by syzzer:

(1) define the exact tool, version and flags we use for the formatting, 
(2) get an ACK on that on the list

(3) push a commit with just running that on the codebase
(4) get some public ACKs on the commit SHA to confirm this is exactly 
running the tool

(5) send style fixup patches following the default procedure

Also agreed to dazo's suggestion of adding a tools/script directory 
which has a simple script running the indenting properly, and which can 
then be used by patch contributors as well.


Also agreed to create a reformatting branch in Git.

--

Discussed removing user choices from the Windows installer:




It was agreed that refactoring the installer should be taken care of 
after currently open PRs have been merged. The goal is to get a 
refactored installer in OpenVPN 2.4_rc2 (due 15th Dec).


---

Full chatlog has been attached to this email.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


(21:01:09) mattock: meeting time
(21:01:31) ***dazo brb
(21:03:18) cron2: burbs
(21:04:04) krzee: gday
(21:04:08) mattock: let me know when you've burbed enough :P
(21:04:11) mattock: hi krzee!
(21:04:16) ***cron2 wants beer
(21:04:42) ***dazo is here
(21:04:50) syzzer: evening
(21:04:59) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2016-12-07
(21:05:01) vpnHelper: Title: Topics-2016-12-07 – OpenVPN Community (at 
community.openvpn.net)
(21:05:32) mattock: hi all!
(21:05:34) cron2: 2. has been answered on the list already "nothing happened, 
everyone too busy, later!" - check
(21:05:47) krzee: !beer
(21:05:55) mattock: yes, patchwork
(21:06:14) mattock: no progress there
(21:06:18) cron2: (as long as it's not *forgotten*...)
(21:06:20) mattock: 2.4 next?
(21:06:29) dazo: yes
(21:07:12) dazo: we have two issues located  systemd + --chroot is an 
unhappy combination, patch resolving it for 2.4_rc2/0 is on the list ... and 
then --mtu-disc is broken on server side
(21:07:31) dazo: (which we were discussing on #openvpn-devel right before this 
meeting)
(21:07:38) cron2: and AES-OFB ASSERT()s on reneg
(21:07:43) dazo: right!
(21:07:49) cron2: (patch on the list as well)
(21:08:04) syzzer: *-OFB/CFB, actually
(21:08:09) syzzer: but yeah
(21:09:25) dazo: anyone want to review syzzer patch?  Or should I add that to 
my TODO list as well?
(21:10:02) cron2: I have no idea what CO_PACKET_ID_LONG_FORM does or why it 
breaks AES-OFB/CFB, but besides that, it looks logical...
(21:11:11) dazo: I'm planning to work another 3-4 hours today ... and I'd like 
to get all those issues for rc2 closed as soon as possible and I have a chance 
to have a look at it today
(21:11:18) cron2: ah, I should just read the lines above
(21:11:52) cron2: syzzer: so why does it ASSERT?  Or was that "it gets confused 
and that 

Re: [Openvpn-devel] [PATCH] Deprecate --no-iv

[Arne Schwabe]

Am 07.12.16 um 20:20 schrieb Steffan Karger:
> This fixes the bug of supporting --no-iv (since we're only accepting
> bugfixes in the current release phase ;) ).
> 
> The --no-iv function decreases security if used (CBC *requires*
> unpredictable IVs, other modes don't allow --no-iv at all), and even 
> marginally
> decreases other user's security by adding unwanted complexity to our code.
> Let's get rid of this.
> 
> Signed-off-by: Steffan Karger 
> ---
>  Changes.rst   | 2 ++
>  doc/openvpn.8 | 4 
>  src/openvpn/options.c | 4 
>  3 files changed, 10 insertions(+)
> 
> diff --git a/Changes.rst b/Changes.rst
> index 843f2bd..4fb5ab5 100644
> --- a/Changes.rst
> +++ b/Changes.rst
> @@ -171,6 +171,8 @@ Deprecated features
>X.509 subject formatting must be updated to the standardized formatting.  
> See
>the man page for more information.
>  
> +- ``--no-iv`` is deprecated in 2.4 and will be remove in 2.5.

Typo: removed

> +
>  User-visible Changes
>  
>  - For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both 
> fields
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index 290a441..e5619c0 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -4399,6 +4399,10 @@ This option only makes sense when replay protection is 
> enabled
>  .\"*
>  .TP
>  .B \-\-no\-iv
> +
> +.B DEPRECATED
> +This option will be removed in OpenVPN 2.5.
> +
>  (Advanced) Disable OpenVPN's use of IV (cipher initialization vector).
>  Don't use this option unless you are prepared to make

We should use long forms, i.e. do not in this case, in our files I think.


>  a tradeoff of greater efficiency in exchange for less
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 4c4b160..8961eca 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -2238,6 +2238,10 @@ options_postprocess_verify_ce (const struct options 
> *options, const struct conne
>  {
>msg (M_USAGE, "--no-iv not allowed when NCP is enabled.");
>  }
> +  if (!options->use_iv)
> +{
> +  msg (M_WARN, "WARNING: --no-iv is deprecated and will be removed in 
> 2.5");
> +}
>  
>/*
> * Check consistency of replay options

ACK


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Deprecate --no-iv

[Gert Doering]

ACK.  We have too many options :-) - tested.

Your patch has been applied to the master branch.

commit b5bf19b1579343ddccaddf2bb464ef2a5a09664d
Author: Steffan Karger
Date:   Wed Dec 7 20:20:47 2016 +0100

 Deprecate --no-iv

 Signed-off-by: Steffan Karger 
 Acked-by: Gert Doering 
 Message-Id: <1481138447-6292-1-git-send-email-stef...@karger.me>
 URL: 
http://www.mail-archive.com/search?l=mid=1481138447-6292-1-git-send-email-stef...@karger.me
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Fix (and cleanup) crypto flags in combination with NCP

[Gert Doering]

ACK.  Look good, and doesn't break anything in my test scenarios (and we
have confirmation from the reporter in trac #784 that it fixes the OFB
case).

The "we abort if --no-iv is set without explicitly turning off NCP" is a
bit drastic, but acceptable, I think.  Some people will need to change 
their configs, so I've added a Changes.rst entry...

Your patch has been applied to the master branch.

commit 84f88ca4d57cd0dc40fd945e09ab1cea1b2cd0b7
Author: Steffan Karger
Date:   Wed Dec 7 19:01:24 2016 +0100

 Fix (and cleanup) crypto flags in combination with NCP

 Signed-off-by: Steffan Karger 
 Acked-by: Gert Doering 
 Message-Id: <1481133684-5325-1-git-send-email-stef...@karger.me>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13428.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Deprecate --no-iv

[Steffan Karger]

This fixes the bug of supporting --no-iv (since we're only accepting
bugfixes in the current release phase ;) ).

The --no-iv function decreases security if used (CBC *requires*
unpredictable IVs, other modes don't allow --no-iv at all), and even marginally
decreases other user's security by adding unwanted complexity to our code.
Let's get rid of this.

Signed-off-by: Steffan Karger 
---
 Changes.rst   | 2 ++
 doc/openvpn.8 | 4 
 src/openvpn/options.c | 4 
 3 files changed, 10 insertions(+)

diff --git a/Changes.rst b/Changes.rst
index 843f2bd..4fb5ab5 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -171,6 +171,8 @@ Deprecated features
   X.509 subject formatting must be updated to the standardized formatting.  See
   the man page for more information.
 
+- ``--no-iv`` is deprecated in 2.4 and will be remove in 2.5.
+
 User-visible Changes
 
 - For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both fields
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 290a441..e5619c0 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4399,6 +4399,10 @@ This option only makes sense when replay protection is 
enabled
 .\"*
 .TP
 .B \-\-no\-iv
+
+.B DEPRECATED
+This option will be removed in OpenVPN 2.5.
+
 (Advanced) Disable OpenVPN's use of IV (cipher initialization vector).
 Don't use this option unless you are prepared to make
 a tradeoff of greater efficiency in exchange for less
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 4c4b160..8961eca 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -2238,6 +2238,10 @@ options_postprocess_verify_ce (const struct options 
*options, const struct conne
 {
   msg (M_USAGE, "--no-iv not allowed when NCP is enabled.");
 }
+  if (!options->use_iv)
+{
+  msg (M_WARN, "WARNING: --no-iv is deprecated and will be removed in 
2.5");
+}
 
   /*
* Check consistency of replay options
-- 
2.7.4


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Refactor setting close-on-exec for socket FDs

[Gert Doering]

Thanks for the test reports (Agi per Mail, Thermi on IRC) and ACK from
Arne.

Patch has been applied to the master branch ("this is a bugfix").

commit e35a788339497ec5c179a5d0a23f63824989ec3e
Author: Gert Doering
Date:   Tue Dec 6 13:26:02 2016 +0100

 Refactor setting close-on-exec for socket FDs

 URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716
 Signed-off-by: Gert Doering 
 Acked-by: Arne Schwabe 
 Message-Id: <1481027162-12165-1-git-send-email-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13405.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix (and cleanup) crypto flags in combination with NCP

[Steffan Karger]

tls_session_update_crypto_params() did not properly set crypto_flags_or,
but instead set crypto_flags_and twice if a OFB/CFB mode was selected.

Also, the crypto flags in ks->crypto_options.flags were set before
tls_session_update_crypto_params() was called, causing those to not be
adjusted.  To fix this, set the crypto flags in
tls_session_generate_data_channel_keys() instead of key_state_init().

While touching that code, remove the to _or and _and variables, which are
not needed at all.

Finally, refuse to accept --no-iv is NCP is enabled.  (we might otherwise
negotiate invalid combinations and ASSERT out later, and using --no-iv is
a bad idea anyway.)

This fixes trac #784.

Signed-off-by: Steffan Karger 
---
 src/openvpn/init.c   | 4 ++--
 src/openvpn/options.c| 4 
 src/openvpn/ssl.c| 8 +++-
 src/openvpn/ssl_common.h | 2 --
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 18a0d70..7e4f40c 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2334,9 +2334,9 @@ do_init_crypto_tls (struct context *c, const unsigned int 
flags)
   if (options->mute_replay_warnings)
 to.crypto_flags |= CO_MUTE_REPLAY_WARNINGS;
 
-  to.crypto_flags_and = ~(CO_PACKET_ID_LONG_FORM);
+  to.crypto_flags &= ~(CO_PACKET_ID_LONG_FORM);
   if (packet_id_long_form)
-to.crypto_flags_or = CO_PACKET_ID_LONG_FORM;
+to.crypto_flags |= CO_PACKET_ID_LONG_FORM;
 
   to.ssl_ctx = c->c1.ks.ssl_ctx;
   to.key_type = c->c1.ks.key_type;
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index b97ac7b..4c4b160 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -2234,6 +2234,10 @@ options_postprocess_verify_ce (const struct options 
*options, const struct conne
 {
   msg (M_USAGE, "NCP cipher list contains unsupported ciphers.");
 }
+  if (options->ncp_enabled && !options->use_iv)
+{
+  msg (M_USAGE, "--no-iv not allowed when NCP is enabled.");
+}
 
   /*
* Check consistency of replay options
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 91c7787..f42c1ed 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -881,9 +881,6 @@ key_state_init (struct tls_session *session, struct 
key_state *ks)
 }
 
   ks->crypto_options.pid_persist = NULL;
-  ks->crypto_options.flags = session->opt->crypto_flags;
-  ks->crypto_options.flags &= session->opt->crypto_flags_and;
-  ks->crypto_options.flags |= session->opt->crypto_flags_or;
 
 #ifdef MANAGEMENT_DEF_AUTH
   ks->mda_key_id = session->opt->mda_context->mda_key_id_counter++;
@@ -1821,6 +1818,7 @@ tls_session_generate_data_channel_keys(struct tls_session 
*session)
 
   ASSERT (ks->authenticated);
 
+  ks->crypto_options.flags = session->opt->crypto_flags;
   if (!generate_key_expansion (>crypto_options.key_ctx_bi,
   >opt->key_type, ks->key_src, client_sid, server_sid,
   session->opt->server))
@@ -1855,9 +1853,9 @@ tls_session_update_crypto_params(struct tls_session 
*session,
   options->authname, options->keysize, true, true);
 
   bool packet_id_long_form = cipher_kt_mode_ofb_cfb 
(session->opt->key_type.cipher);
-  session->opt->crypto_flags_and &= ~(CO_PACKET_ID_LONG_FORM);
+  session->opt->crypto_flags &= ~(CO_PACKET_ID_LONG_FORM);
   if (packet_id_long_form)
-session->opt->crypto_flags_and = CO_PACKET_ID_LONG_FORM;
+session->opt->crypto_flags |= CO_PACKET_ID_LONG_FORM;
 
   /* Update frame parameters: undo worst-case overhead, add actual overhead */
   frame_add_to_extra_frame (frame, -(crypto_max_overhead()));
diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index 7938f41..8164bbc 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -279,8 +279,6 @@ struct tls_options
 
   /* struct crypto_option flags */
   unsigned int crypto_flags;
-  unsigned int crypto_flags_and;
-  unsigned int crypto_flags_or;
 
   int replay_window;   /* --replay-window parm */
   int replay_time; /* --replay-window parm */
-- 
2.7.4


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.3.14 released

[Samuli Seppänen]

The OpenVPN community project team is proud to release OpenVPN 2.3.14. 
It can be downloaded from here:



This release includes many small fixes and improvements. A summary of 
these changes is available here:



A full list of changes is available here.



For generic help use these support channels:

Official documentation: 

Wiki: 
Forums: 
User mailing list: 
User IRC channel: #openvpn at irc.freenode.net

Please report bugs and ask development questions here:

Bug tracker and wiki: 
Developer mailing list: 
Developer IRC channel: #openvpn-devel at irc.freenode.net (requires 
Freenode registration)

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Add "async push" feature to Changes.rst

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Your patch has been applied to the master branch

I did a slight modification to the Changes.rst file,
making it even more clear that --enable-async-push is
an option to ./configure being used at build time.

commit 212ef1a409b375174dd81d52da34678ebab685ae
Author: Lev Stipakov
Date:   Wed Dec 7 11:56:57 2016 +0200

 Add "async push" feature to Changes.rst

 Acked-by: David Sommerseth 
 Message-Id: <1481104617-3675-1-git-send-email-lstipa...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13420.html
 Signed-off-by: David Sommerseth 


- --
kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYSBIVAAoJEIbPlEyWcf3yRWAP/15zvcZZpenjB3iaouWwrQ35
aoXmzxF2DLG2z6DLtw948Y9oDEE6ZMLwCGK+e/GEMqPf6WOW7tM3mUlxKT3tFMG8
tO/agmvWZtNVaZAm09nmZhtf69kOewsUaFYugqxq2WESKWJC/EgoGh52CcBF305I
m02SBnFRmliVzOOGqcDRobNzMMQ3JrgdAvIcgKegMgGiEhv8siJNjBJKaslk+em7
2JuEbtN1OFtR/lgzNisTxLYHmnxLkGdAhD0RiNqFfOfd6aFsP+r2CldxqeP68Ddp
aDHVTo0UIcgYlWhMUPG+ZjYZclwu948QVljFLvll8fejcxFWbTBGZDNjeqGrtttH
QogmhNCnIWL+BRpQ8mMbsHiWZU2P8LqMYq6z2xIYgSxxl44pk7eKZNxO42QWrldt
BLM3VeySWZQsPnP104Qo1chOdPYsoRAxGGKouP2tP4UOEJ8aBAvDo7fpwW78wrRB
ZUZRiti63Sj5Ug+tS5A3w8CbqFVKzJs3ooULkynl5beAxUBRNiIXjAYLJx2tzFeF
6k/yt2j/78GdullTwSa8wLz1ulePJZt11IrOYZ7eMwYG3HpNQhg7flaWrJhsphRt
Bn8MCiqWHoCDCahgNIjV+9dRXWD51d3SgN2nQT6Q5yofiRxtWKiKv+h7xiPYTmK6
V9tkB9DJDHvGWScCY8hw
=gSOB
-END PGP SIGNATURE-

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Arm inotify only in server mode

[David Sommerseth]

On 07/12/16 09:19, Gert Doering wrote:
> Hi,
> 
> On Wed, Dec 07, 2016 at 01:45:51AM +0200, Lev Stipakov wrote:
>>  #ifdef ENABLE_ASYNC_PUSH
>>/* arm inotify watcher */
>> -  event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
>> (void*)_shift);
>> +  if (c->options.mode == MODE_SERVER)
>> +event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
>> (void*)_shift);
>>  #endif
> 
> I find this a non-robust approach to this.
> 
> What is wrong with
> 
>if ( c->c2.inotify_fd > 0 )
>  {
>event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
> (void*)_shift);
>  }
> 
> (as I suggested on IRC yesterday evening)?

That scenario is already tackled in tunnel_server_tcp() [mtcp.c:708] and
tunnel_server_udp_single_threaded() [mudp.c:300], which I would say is
the proper place to catch this error.

The race we saw in trac ticket #786 is related to being in non-server
mode.  So if OpenVPN is not running in server mode, we shouldn't touch
c->c2.inotify_fd at all.

> This will ensure that inotify is armed *if* it got prepped, independent of
> "whatever other flags are active in the system" - next thing, someone adds
> a "--no-inotify" run-time switch, and you'll have to revisit this place
> again - or someone else finds a use for inotify in client mode, and this
> will also need touching.

If such a --no-inotify option is added, it would need to be handled in
the tunnel_server_*() functions anyhow.  And to implement such a feature
without checking all the ENABLE_ASYNC_PUSH #ifdefs would be a poor
implementation.

> Also, braces.  See CodingStyle in the wiki.

Yes, that is right once we've formatted the whole code tree to be
consistent.  Currently this kind of missing braces is just as common.
Which is why I didn't really react to this one in this round.


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc




signature.asc
Description: OpenPGP digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs

[Alberto Gonzalez Iniesta]

On Tue, Dec 06, 2016 at 01:36:04PM +0100, Arne Schwabe wrote:
> Am 06.12.16 um 13:26 schrieb Gert Doering:
> > The existing code can leak socket FDs to the "--up" script, which is
> > not desired.  Brought up by Alberto Gonzalez Iniesta, based on debian
> > bug 367716.
> > 
> > Since different sockets get create at different times, just moving the
> > set_cloexec() to link_socket_init_phase1() is not good enough - so move
> > the call into create_socket_(), so we will catch ALL socket
> > creations, no matter when or under which conditions they will be
> > created (SOCKS proxy socket, listening socket, ...).
> 
> Patch looks good. ACK from me. I also looked at the port-share code path
> but that part isn't touched by this commit.
> 

Works for me (tm)

I'm just waiting for the pkcs11-helper maintainer [1] to upload 2.4~rc1
to Debian. If he decides to build against OpenSSL 1.1 I'd have to remove
PKCS #11 support from Debian's package in Stretch.



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828506

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] fuzz testing by google ?

[Gert Doering]

Hi,

On Wed, Dec 07, 2016 at 04:51:36PM +0500,  ?? wrote:
> at least, I recall this commit
> https://github.com/OpenVPN/openvpn/commit/0d8da22ae36d5efd03fba36c1d783b907589e321

*That* commit is "the 2.3.6 release", but I see what you mean.

> it used to crash on simple tcp connect (after immediate disconnect), it was
> reproducible to running login/password authentication mode
> 
> it might have been caught by fuzz testing.

I should point out that this was not a "crash" but an "openvpn detects
invalid input and ASSERT()s out -> well-defined program exit".

Not exactly *friendly* behaviour (and stupid, in this case), but not 
a *crash*.

But that's exactly why fuzzing openvpn is hard: we detect bad stuff, and
in doubt, we ASSERT() - which is well-defined behaviour, not "crashing
randomly, possibly in a way that can be exploited to get access to
security critical bits"

> > Anyway - so what's necessary to make this google fuzz testing work?  Do
> > we instrument our code, or just tell them "hey, here's a useful piece
> > of software, go figure it out yourself"?
> 
> we can start with PR to
> https://github.com/google/oss-fuzz/tree/master/projects
> it must been done by someone from "OpenVPN" github organization.

OK, that would then be Samuli, David or me, I think.  We'll investigate...

> if google machinery will not figure out anything, it might be long way with
> libfuzz-helpers (if we implement such helpers, we can add them to cmoka and
> travis-ci)

Indeed, but that would be "we have to do it", which nobody seems to have
time right now.

gert


-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] fuzz testing by google ?

[Илья Шипицин]

2016-12-07 2:18 GMT+05:00 Gert Doering :

> Hi,
>
> On Fri, Dec 02, 2016 at 08:48:29AM +0500,  ?? wrote:
> > https://opensource.googleblog.com/2016/12/announcing-oss-
> fuzz-continuous-fuzzing.html
>
> This is generally interesting, of course.
>
> Fuzzing openvpn "as a whole" is quite complicated, though - we do check
> our input very well, so the last time someone tried to fuzz TLS packets
> to make openvpn "do bad things", all he got was "go away, you stink,
> session destroyed" :-)
>

at least, I recall this commit
https://github.com/OpenVPN/openvpn/commit/0d8da22ae36d5efd03fba36c1d783b907589e321
it used to crash on simple tcp connect (after immediate disconnect), it was
reproducible to running login/password authentication mode

it might have been caught by fuzz testing.



>
> Anyway - so what's necessary to make this google fuzz testing work?  Do
> we instrument our code, or just tell them "hey, here's a useful piece
> of software, go figure it out yourself"?
>

we can start with PR to
https://github.com/google/oss-fuzz/tree/master/projects
it must been done by someone from "OpenVPN" github organization.

if google machinery will not figure out anything, it might be long way with
libfuzz-helpers (if we implement such helpers, we can add them to cmoka and
travis-ci)


>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/ 
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-
> muenchen.de
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Correctly state the default dhcp server address in man page

[Samuli Seppänen]

Il 07/12/2016 10:29, Gert Doering ha scritto:
> Hi,
>
> On Tue, Dec 06, 2016 at 05:37:15PM -0500, Selva Nair wrote:
>> Yes, it does work in tun mode (easy to test just use offset 0 on command
>> line)
>
> Good :-)
>
>> I had posted a patch ( a year ago?) which sets the offset to 0. I did not
>> remove the offset variable though it makes sense to get rid of it... Anyway
>> the patch never got any attention :)
>
> Apologies.  I've seen the patch but got distracted.
>
> We should get this fixed after 2.4 release in master (along with lots of
> other "now we go clean this up and refactor everything" :-) ).
>
> For "fixing strange parts of openvpn" patches, please feel free to remind
> me every now and then that feedback is missing.  I'm not extending this to
> "all sorts of patches" right now, though, as I can't make promises for the
> "big change patch series"...
>
> Anyway: Samuli, how's patchwork proceeding?  Speaking of "tracking patches".

Patchwork has not progressed one bit. I've been busy pushing out OpenVPN 
releases on weekly basis, plus reviewing and testing Selva's and Ilya's 
commits to openvpn-build and openvpn-gui which those releases need :).

I will get back to patchwork once things calm down on the OpenVPN 
release front.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Add "async push" feature to Changes.rst

[Lev Stipakov]

From: Lev Stipakov 

---
 Changes.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Changes.rst b/Changes.rst
index 843f2bd..44fe346 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -147,6 +147,11 @@ Control channel encryption (``--tls-crypt``)
 channel packets.  Provides more privacy, some obfuscation and poor-man's
 post-quantum security.
 
+Asynchronous push reply
+If asynchronous authentication is enabled and completed after server 
received 
+PUSH_REQUEST message, server sends PUSH_REPLY immediately without waiting 
for next
+PUSH_REQUEST. Requires use of ``--enable-async-push`` as configure 
parameter.
+
 
 Deprecated features
 ---
-- 
1.9.1


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Correctly state the default dhcp server address in man page

[Gert Doering]

Hi,

On Tue, Dec 06, 2016 at 05:37:15PM -0500, Selva Nair wrote:
> Yes, it does work in tun mode (easy to test just use offset 0 on command
> line)

Good :-)

> I had posted a patch ( a year ago?) which sets the offset to 0. I did not
> remove the offset variable though it makes sense to get rid of it... Anyway
> the patch never got any attention :)

Apologies.  I've seen the patch but got distracted.

We should get this fixed after 2.4 release in master (along with lots of
other "now we go clean this up and refactor everything" :-) ).

For "fixing strange parts of openvpn" patches, please feel free to remind
me every now and then that feedback is missing.  I'm not extending this to
"all sorts of patches" right now, though, as I can't make promises for the
"big change patch series"...

Anyway: Samuli, how's patchwork proceeding?  Speaking of "tracking patches".

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Arm inotify only in server mode

[Gert Doering]

Hi,

On Wed, Dec 07, 2016 at 01:45:51AM +0200, Lev Stipakov wrote:
>  #ifdef ENABLE_ASYNC_PUSH
>/* arm inotify watcher */
> -  event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
> (void*)_shift);
> +  if (c->options.mode == MODE_SERVER)
> +event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
> (void*)_shift);
>  #endif

I find this a non-robust approach to this.

What is wrong with

   if ( c->c2.inotify_fd > 0 )
 {
   event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
(void*)_shift);
 }

(as I suggested on IRC yesterday evening)?

This will ensure that inotify is armed *if* it got prepped, independent of
"whatever other flags are active in the system" - next thing, someone adds
a "--no-inotify" run-time switch, and you'll have to revisit this place
again - or someone else finds a use for inotify in client mode, and this
will also need touching.

It will fix the issue at hand, but is not good code.

Also, braces.  See CodingStyle in the wiki.

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel