[Openvpn-devel] [PATCH 0/2] Fix mistyped option names

2020-08-15 Thread Magnus Kroken
While preparing a 2.5_beta1 package, I had to look
back and forth betwenn various sources to get option
names right. It seems that in some places names are
altered to make grammatical sense, which I find
confusing.

"Data cipher" and "compression" are simply words, and
it makes sense to use the grammatically correct form 
whenever they are used. However I interpret --data-cipher, 
``--data-cipher`` and --compression as literal, as the dashes
and code highlighting hints that this is exactly how these
are used in configuration and commands. There is no option
--data-cipher in OpenVPN, so I would not expect the literal
--data-cipher to appear anywhere, even when a sentence refers
to one singular cipher in the list of --data-ciphers.

Magnus Kroken (2):
  Changes.rst: fix mistyped option names
  doc: fix typos in cipher-negotiation.rst

 Changes.rst | 10 +-
 doc/man-sections/cipher-negotiation.rst |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.20.1



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


[Openvpn-devel] [PATCH 2/2] doc: fix typos in cipher-negotiation.rst

2020-08-15 Thread Magnus Kroken
Signed-off-by: Magnus Kroken 
---
 doc/man-sections/cipher-negotiation.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/man-sections/cipher-negotiation.rst 
b/doc/man-sections/cipher-negotiation.rst
index f1433052..a2feb5f9 100644
--- a/doc/man-sections/cipher-negotiation.rst
+++ b/doc/man-sections/cipher-negotiation.rst
@@ -38,7 +38,7 @@ options to avoid this behaviour.
 OpenVPN 3 clients
 -
 Clients based on the OpenVPN 3.x library (https://github.com/openvpn/openvpn3/)
-do not have a configurable ``--ncp-ciphers`` or ``--data-cipher`` option. 
Instead
+do not have a configurable ``--ncp-ciphers`` or ``--data-ciphers`` option. 
Instead
 these clients will announce support for all their supported AEAD ciphers
 (`AES-256-GCM`, `AES-128-GCM` and in newer versions also `Chacha20-Poly1305`).
 
@@ -90,7 +90,7 @@ version. The default was never changed to ensure backwards 
compatibility.
 In OpenVPN 2.5 this behaviour has now been changed so that if the ``--cipher``
 is not explicitly set it does not allow the weak ``BF-CBC`` cipher any more
 and needs to explicitly added as ``--cipher BFC-CBC`` or added to
-``-data-ciphers``.
+``--data-ciphers``.
 
 We strongly recommend to switching away from BF-CBC to a
 more secure cipher as soon as possible instead.
-- 
2.20.1



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


[Openvpn-devel] [PATCH 1/2] Changes.rst: fix mistyped option names

2020-08-15 Thread Magnus Kroken
Signed-off-by: Magnus Kroken 
---
 Changes.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 0aee3603..f67e1d76 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -34,7 +34,7 @@ Improved Data channel cipher negotiation
 Removal of BF-CBC support in default configuration:
 By default OpenVPN 2.5 will only accept AES-256-GCM and AES-128-GCM as
 data ciphers. OpenVPN 2.4 allows AES-256-GCM,AES-128-GCM and BF-CBC when
-no --cipher and --ncp-cipher options are present. Accepting BF-CBC can be
+no --cipher and --ncp-ciphers options are present. Accepting BF-CBC can be
 enabled by adding
 
 data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC
@@ -101,7 +101,7 @@ Linux VRF support
 TLS 1.3 support
 TLS 1.3 support has been added to OpenVPN.  Currently, this requires
 OpenSSL 1.1.1+.
-The options ``--tls-cipher-suites`` and ``--tls-groups`` have been
+The options ``--tls-ciphersuites`` and ``--tls-groups`` have been
 added to fine tune TLS protocol options.  Most of the improvements
 were also backported to OpenVPN 2.4 as part of the maintainance
 releases.
@@ -112,7 +112,7 @@ Support setting DHCP search domain
 wintun support yet).  Other platforms need to support this via ``--up``
 script (Linux) or GUI (OSX/Tunnelblick).
 
-per-client changing of ``--data-cipher`` or ``data-ciphers-fallback``
+per-client changing of ``--data-ciphers`` or ``data-ciphers-fallback``
 from client-connect script/dir (NOTE: this only changes preference of
 ciphers for NCP, but can not override what the client announces as
 "willing to accept")
@@ -213,9 +213,9 @@ User-visible Changes
   the client configuration almost immediately as result of the
   faster connection setup feature.
 
-- ``--compression`` is nowadays considered risky, because attacks exist
+- ``--compress`` is nowadays considered risky, because attacks exist
   leveraging compression-inside-crypto to reveal plaintext (VORACLE).  So
-  by default, ``--compression xxx`` will now accept incoming compressed
+  by default, ``--compress xxx`` will now accept incoming compressed
   packets (for compatibility with peers that have not been upgraded yet),
   but will not use compression outgoing packets.  This can be controlled with
   the new option ``--allow-compression yes|no|asym``.
-- 
2.20.1



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


Re: [Openvpn-devel] [PATCH] Document tls-crypt security considerations in man page

2017-05-07 Thread Magnus Kroken
Hi Steffan

Non-crypto geek here, comments inline.

On 05.05.2017 22:30, Steffan Karger wrote:
> +control channel messages.  A typical initial negotiation is about 10 packets
> +in each direction.  Assuming both initial negotation and renogatiations are
> +at most 2^16 (65536) packets, and (re)negotiations happen each minute for
> +each user (24/7)

Does 10 and 65536 represent the same actual thing here, where 10 is a 
practical real-world estimate, and 65536 is an extremely conservative 
estimate? Or does it mean that each user will cause a total of 65536 
(re)negotiation packets in his lifetime? I think using a conservative 
estimate is a good idea, but the large difference is somewhat confusing 
(and I'm not entirely sure I get the correct meaning myself).

> this limits the tls\-crypt key lifetime to 8171 year divided

8171 years (just a typo I suppose, but it's significant to the meaning 
of the sentence).

/Magnus

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] OpenVPN Service Flagged as Trojan

2016-12-29 Thread Magnus Kroken
Hi

On 29.12.2016 19.07, Morris, Russell wrote:
> That's good - thanks! Not sure how to fix Windows flagging this though - I'm 
> assuming others will have the same issue.
>
> ... Russell

Most likely a definition update will fix this very soon, or already has. 
I just ran it through Virustotal [1], all scanners report it as 
harmless, including Microsoft with todays definitions. Also, Defender 
reports openvpnserv2 as clean on my computer, with definitions created 
today at 10:44 AM (CET or UTC, I'm not sure which).

[1] 
https://www.virustotal.com/en/file/c3970ec979ccbdb03d38c1df606fc3437a85cea2f3b56a2f03c32fde4dfe9046/analysis/1483035462/

/Magnus

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] mbedtls: include correct net/net_sockets header according to version

2016-12-09 Thread Magnus Kroken
 is deprecated as of mbedTLS 2.4.0, it is renamed
. OpenVPN will fail to build with
mbedTLS 2.4.0 with MBEDTLS_DEPRECATED_REMOVED defined.

Check MBEDTLS_VERSION_NUMBER, and include net.h for < 2.4.0 and
net_sockets.h for >= 2.4.0.

Signed-off-by: Magnus Kroken <mkro...@gmail.com>
---
Tested, builing with both mbedTLS 2.3.0 and 2.4.0 with 
MBEDTLS_DEPRECATED_REMOVED is successful. 

This patch is as much to document the issue as a suggested patch.
I don't know if MBEDTLS_DEPRECATED_REMOVED is considered a
distro/package maintainers problem or something to fix with 
an #if, so I won't be sad if it isn't accepted.

 src/openvpn/ssl_mbedtls.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 11ee65b..985a39f 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -51,11 +51,17 @@
 #include "ssl_verify_mbedtls.h"
 #include 
 #include 
-#include 
+#include 
+
+#if MBEDTLS_VERSION_NUMBER >= 0x0204
+#include 
+#else
+#include 
+#endif
+
 #include 
 #include 
 #include 
-#include 
 
 void
 tls_init_lib()
-- 
2.1.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-mbedTLS depends on mbedTLS debug module - safe to remove?

2016-06-12 Thread Magnus Kroken

Hi

The mbedTLS/PolarSSL build of OpenVPN depends on the debug.c part of 
mbedTLS. Specifically ssl_polarssl.c (ssl_mbedtls.c in master branch), 
key_state_ssl_init() calls debug_set_threshold() [1]. Removing this line 
removes the dependency.


Is it safe to remove the call to debug_set_threshold? Is it only used 
for more verbose logging, or can this cause a TLS error to not be 
noticed (or lead to other security implications)?


Building mbedTLS with the debug module increases its size by about 40k, 
and e.g. OpenWrt builds it without the debug module by default for this 
reason. I'm not asking OpenVPN to remove this, but I would like to know 
the known consequences of such a change.


1: 
https://github.com/OpenVPN/openvpn/commit/a9226fbdd90ac37891937b396c9c3212cd324262#diff-a06a4475e26fd6ec7e0cd3bbdcb30966R745


Regards,
Magnus Kroken