Re: [Openvpn-devel] [ovpn-dco] How to benchmark kernel crypto performance?

[Jan Just Keijser]

Hi Tony,

On 05/04/22 15:04, Tony He wrote:

Hi JJK,

Yeah, I know this way, but there is still context switching in the
kernel space and user space. I have been looking for a way
to benchmark in the kernel space. I expect there is a kernel module like below:

insmod benchmark.ko AES-256-GCM
(After it's done,  this module will exit automatically)


that would be 'tcrypt' then, I guess ; on my Fedora boxen I have
#  modinfo tcrypt
filename: /lib/modules/5.16.18-100.fc34.x86_64/kernel/crypto/tcrypt.ko.xz
author: James Morris 
description:    Quick & dirty crypto testing module
[...]
parm:   alg:charp
parm:   type:uint
parm:   mask:uint
parm:   mode:int
parm:   sec:Length in seconds of speed tests (defaults to zero 
which uses CPU cycles instead) (uint)
parm:   num_mb:Number of concurrent requests to be used in mb 
speed tests (defaults to 8) (uint)

parm:   klen:Key length (defaults to 0) (uint)


cheers,

JJK


Jan Just Keijser  于2022年4月5日周二 19:26写道：

hi Tony,

On 02/04/22 11:40, Tony He wrote:

Hi Antonio,

I am porting ovpn-dco to embedded ARMv8 device with hardware crypto
engine. However the performance is not very good.
It's about 130-140Mbps. I expect more. The SDK already provides kernel
CryptoAPI(CFI) interface  to access the crypto engine.
I want to know if the crypto operation is the bottleneck. Do you know
how to benchmark crypto performance in the kernel space?
Any advice is welcome. Thank you!


a quick & dirty way to test the hardware crypto engine is to use the
Linux cryptodev engine in combination with openssl ; it's a bit tricky
to get it working but it *is* a nice way to test hardware crypto.

* https://github.com/cryptodev-linux/cryptodev-linux.git
* do a custom openssl build with
  ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS enable-engine
enable-dso enable-devcryptoeng 
* run openssl speed using
./openssl speed -elapsed -engine devcrypto -evp aes-128-cbc

and compare the results with "-engine devcrypto" removed.

HTH,

JJK







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

Re: [Openvpn-devel] [ovpn-dco] How to benchmark kernel crypto performance?

[Jan Just Keijser]

hi Tony,

On 02/04/22 11:40, Tony He wrote:

Hi Antonio,

I am porting ovpn-dco to embedded ARMv8 device with hardware crypto
engine. However the performance is not very good.
It's about 130-140Mbps. I expect more. The SDK already provides kernel
CryptoAPI(CFI) interface  to access the crypto engine.
I want to know if the crypto operation is the bottleneck. Do you know
how to benchmark crypto performance in the kernel space?
Any advice is welcome. Thank you!

a quick & dirty way to test the hardware crypto engine is to use the 
Linux cryptodev engine in combination with openssl ; it's a bit tricky 
to get it working but it *is* a nice way to test hardware crypto.


* https://github.com/cryptodev-linux/cryptodev-linux.git
* do a custom openssl build with
    ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS enable-engine 
enable-dso enable-devcryptoeng 

* run openssl speed using
  ./openssl speed -elapsed -engine devcrypto -evp aes-128-cbc

and compare the results with "-engine devcrypto" removed.

HTH,

JJK





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

Re: [Openvpn-devel] [PATCH v2] Retain CAP_NET_ADMIN when dropping privileges

[Jan Just Keijser]

Hi,

On 30/03/22 22:55, Timo Rothenpieler wrote:

---
Using libcap-ng now
sorry to butt in late, but I've got a nasty feeling about this... the 
whole purpose of using

  --user
is, according to the man page
   --user user
  Change the user ID of the OpenVPN process to user after  
initialization,  dropping  privileges  in  the
  process.  This  option is useful to protect the system in 
the event that some hostile party was able to
  gain control of an OpenVPN session. Though OpenVPN's 
security features make this unlikely, it  is  pro‐

  vided as a second line of defense.

  By  setting  user  to  nobody or somebody similarly 
unprivileged, the hostile party would be limited in
  what damage they could cause. Of course once you take 
away privileges, you cannot  return  them  to an
  OpenVPN  session.  This  means, for example, that if you 
want to reset an OpenVPN daemon with a SIGUSR1
  signal (for example in response to a DHCP reset), you 
should make use of one or more of  the  --persist
  options  to  ensure  that OpenVPN doesn't need to execute 
any privileged operations in order to restart
  (such as re-reading key files or running ifconfig on the 
TUN device).


yet with this patch, the openvpn process remains capable of

   CAP_NET_ADMIN
  Perform various network-related operations:
  * interface configuration;
  * administration of IP firewall, masquerading, and
    accounting;
  * modify routing tables;
  * bind to any address for transparent proxying;
  * set type-of-service (TOS);
  * clear driver statistics;
  * set promiscuous mode;
  * enabling multicasting;
  * use setsockopt(2) to set the following socket options:
    SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside
    the range 0 to 6), SO_RCVBUFFORCE, and SO_SNDBUFFORCE.

so this "second line of defense" it getting *VERY* leaky in my opinion 
(and warrants a manpage update, at the very least).


The proper solution would be to have openvpn fork on itself, keep a 
"barebones" process running as root, but with the actual control and 
data channels running in the forked process using truly minimal privileges.


JM2CW,

JJK




  configure.ac  | 19 +
  distro/systemd/openvpn-cli...@.service.in |  2 +-
  distro/systemd/openvpn-ser...@.service.in |  2 +-
  src/openvpn/init.c| 25 ++-
  src/openvpn/platform.c| 91 +++
  src/openvpn/platform.h|  5 ++
  6 files changed, 140 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7199483a..168360d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -794,6 +794,25 @@ dnl
esac
  fi
  
+dnl

+dnl Depend on libcap-ng on Linux
+dnl
+case "$host" in
+   *-*-linux*)
+   PKG_CHECK_MODULES([LIBCAPNG],
+ [libcap-ng],
+ [have_libcapng="yes"],
+ [AC_MSG_ERROR([libcap-ng package not found. 
Is the development package and pkg-config installed?])]
+   )
+   AC_CHECK_HEADER([sys/prctl.h],,[AC_MSG_ERROR([sys/prctl.h not 
found!])])
+
+   CFLAGS="${CFLAGS} ${LIBCAPNG_CFALGS}"
+   LIBS="${LIBS} ${LIBCAPNG_LIBS}"
+   AC_DEFINE(HAVE_LIBCAPNG, 1, [Enable libcap-ng support])
+   ;;
+esac
+
+
  if test "${with_crypto_library}" = "openssl"; then
AC_ARG_VAR([OPENSSL_CFLAGS], [C compiler flags for OpenSSL])
AC_ARG_VAR([OPENSSL_LIBS], [linker flags for OpenSSL])
diff --git a/distro/systemd/openvpn-cli...@.service.in 
b/distro/systemd/openvpn-cli...@.service.in
index cbcef653..159fb4dc 100644
--- a/distro/systemd/openvpn-cli...@.service.in
+++ b/distro/systemd/openvpn-cli...@.service.in
@@ -11,7 +11,7 @@ Type=notify
  PrivateTmp=true
  WorkingDirectory=/etc/openvpn/client
  ExecStart=@sbindir@/openvpn --suppress-timestamps --nobind --config %i.conf
-CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID 
CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
+CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID 
CAP_SETUID CAP_SETPCAP CAP_SYS_CHROOT CAP_DAC_OVERRIDE
  LimitNPROC=10
  DeviceAllow=/dev/null rw
  DeviceAllow=/dev/net/tun rw
diff --git a/distro/systemd/openvpn-ser...@.service.in 
b/distro/systemd/openvpn-ser...@.service.in
index d1cc72cb..6e8e7d94 100644
--- a/distro/systemd/openvpn-ser...@.service.in
+++ b/distro/systemd/openvpn-ser...@.service.in
@@ -11,7 +11,7 @@ Type=notify
  PrivateTmp=true
  WorkingDirectory=/etc/openvpn/server
  ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --suppress-timestamps --config %i.conf
-Capabi

[Openvpn-devel] Switched email addresses

[Jan Just Keijser]

Hi lists,

just so you all know:  I've switched email addresses for my OpenVPN 
mailing list subscriptions, as I am starting a new job as "IT Specialist 
High Performance Computing" at the University of Leiden in May.

I have no idea how long my old Nikhef email address will be forwarded yet.

cheers,

JJK / Jan Just Keijser



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

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.5.5 released

[Jan Just Keijser]

On 15/12/21 18:01, Gert Doering wrote:

Hi,

On Wed, Dec 15, 2021 at 04:30:43PM +, tincantech via Openvpn-users wrote:

-BEGIN PGP SIGNED MESSAGE-
It seems only fair to warn the OpenVPN community that Version 2.5.5 has had 
bugs identified.
A new release v2.5.6 is planned for the coming week, or so..

That was a misunderstanding about a comment I made about the planned
change for the release process for 2.5.6, whenever it happens.

The only bugs we *know* about in 2.5.5 is "Changes.rst was malformatted
and talks about openssl.cfg instead of openssl.cnf" - that does not warrant
a new release yet.

what!  a malformatted Changes.rst file warrants its own CVE code, I 
would say!

Let me report it to mitre ;)

JJK



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

Re: [Openvpn-devel] NTLMv1, NTLMv2 HTTP proxy support?

[Jan Just Keijser]

Hi Gert,

On 07/11/21 14:55, Gert Doering wrote:

Hi Community,

OpenVPN supports HTTP proxies that require NTLM authentication,
supporting NTLMv1 and NTLMv2 protocols.

This is old code, which was written in the dark ages, is not currently
unit/client tested, and uses DES which got deprecated in OpenSSL 3.0.0...

That said, if people still *use* it, we are likely to keep it - otherwise
it might just become lost :-)

So - if you use HTTP proxy in OpenVPN, and that proxy authenticates
against a Windows AD domain, and you use NTLMv1 or NTLMv2 authentication,
please speak up and tell us about your use case!


it took me a while, but I finallly have a working setup with a Samba 
4.15 and a CentOS 7 webserver with mod_auth_ntlm_winbind ; especially 
the latter part is tricky/important, as that code is not supported on 
newer platforms, it seems.


The good news is:   openvpn 2.5.1 still works , both with NTLMv1 and 
NTLMv2; I added two debug statements to ntlm.c and can clearly see:


NTLMv1:
2021-12-15 09:36:16 Info: generate NTLM response
2021-12-15 09:36:16 NTLM response: add security buffer

NTLMv2:
2021-12-15 09:35:44 Info: generate NTLMv2 response
2021-12-15 09:35:44 NTLMv2 response: add security buffer

Having said that, I think we can safely drop (at least) NTLMv1 support, 
as it is pretty hard to set up a system to support that - easiest way is 
to grab a legacy Windows server system (e.g. Windows Server 2003) but 
nobody should run that anyways. Or put another way
  "if your local proxy is running unsupported legacy code in an 
unsecure setup,

   then you will have to resort to openvpn 2.4.x "

or similar.

BTW, do you know who worked on the obfuscation/transport API stuff? Was 
that David S?


cheers,

JJK / Jan Just Keijser



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

Re: [Openvpn-devel] [Openvpn-users] NTLMv1, NTLMv2 HTTP proxy support?

[Jan Just Keijser]

Hi Jason,

On 09/11/21 09:37, Jason Haar wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

How about ditching the NTLM and adding HTTPS proxy support instead? ;-)
Does the privacy aspect of talking to proxies "properly" of course (Basic
is fine over HTTPS)

(and accidentally makes openvpn-over-TCP look like real TLS traffic too...)


this was also discussed at the OpenVPN Hackathon last weekend; I have 
code laying around for it

  https://github.com/jjkeijser/connect-proxy/
which allows you to run a separate HTTPS proxy and then connect OpenVPN 
to it using  127.0.0.1:


This needs to be integrated into OpenVPN in some form - I think we 
decided to use the (delayed-then-forgotten) transport obfuscation plugin 
for this. We talked about it a few years ago, but it was never fully 
implemented.


@Gert, list:  who was working on this and who still has the code for the 
transport obfuscation plugin ?  would be a good clean-up project to move 
all proxy (socks, http AND https) code into this plugin.


cheers,

JJK


On 2021-11-07 at 13:55, g...@greenie.muc.de wrote:

Hi Community,

OpenVPN supports HTTP proxies that require NTLM authentication,
supporting NTLMv1 and NTLMv2 protocols.

This is old code, which was written in the dark ages, is not currently
unit/client tested, and uses DES which got deprecated in OpenSSL 3.0.0...

That said, if people still *use* it, we are likely to keep it - otherwise
it might just become lost :-)

So - if you use HTTP proxy in OpenVPN, and that proxy authenticates
against a Windows AD domain, and you use NTLMv1 or NTLMv2 authentication,
please speak up and tell us about your use case!





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

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

[Jan Just Keijser]

On 20/05/21 23:12, tincantech wrote:

[...]

So, why switch to .pem when it has never been used before by openvpn?
If you are all happy to let it go that way then so-be-it,

Hopefully this clarifies things:

-   the default output format of OpenSSL is PEM-encoded ; openssl uses the
 default extension .pem

-   the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but
 they've just been named differently by the easy-rsa tools to ensure that
 the files can be easily loaded on Windows

-   FTR: nearly all webservers I have ever seen are configured to use a
 hostcert.pem and hostkey.pem and my guess is that there are (still)
 more  Linux-based webservers out there than OpenVPN clients and servers.

 Having said that, I do agree that after using .crt/.key files left and
 right (to accomodate Windows users) for over 15 years, it does seem
 confusing to start using files named .pem for peer-fingerprinting all
 of  sudden. On the other hand, with peer-fingerprinting you don't
 HAVE a .crt file (at least, you don't need one, technically) but only
 a .key file. So choosing a different extension for peer-fingerprinting
 does have its merits.

FTR: Openvpn still exchanges the full certificates in peer-fingerprint mode.


meh ... I guess it was easier to implement it that way at the TLS level...

IMO that does add a "+1" to using .crt/.key  extensions - otherwise it 
might confuse the heck out of end users (like overwriting the private 
key with the public cert etc ... )
How do the examples distinguish between the cert and the private key in 
this case then?


JJK


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

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

[Jan Just Keijser]

Hi,

On 20/05/21 21:49, tincantech via Openvpn-devel wrote:



Hi,
again, I do not understand why openvpn choose to switch to .pem
for this tutorial.  PEM -> Private Email, which this is not.
You have a certificate and a key and every other openvpn tutorial
on openvpn and probably the entire planet uses .crt and .key.
This seems to be a poor decision in my opinion.

pem as extension for keys is pretty common and specifies more the
encoding than the type. E.g. there is also the der encoding.

Arne

I accept the principle but openvpn *only* uses PEM-enc, that I know of.

So, why switch to .pem when it has never been used before by openvpn?

If you are all happy to let it go that way then so-be-it,



Hopefully this clarifies things:
- the default output format of OpenSSL is PEM-encoded ; openssl uses the 
default extension .pem
- the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but 
they've just been named differently by the easy-rsa tools to ensure that 
the files can be easily loaded on Windows


- FTR: nearly all webservers I have ever seen are configured to use a 
hostcert.pem and hostkey.pem and my guess is that there are (still) 
more  Linux-based webservers out there than OpenVPN clients and servers.


Having said that, I do agree that after using .crt/.key files left and 
right (to accomodate Windows users) for over 15 years, it does seem 
confusing to start using files named .pem for peer-fingerprinting all 
of  sudden. On the other hand, with peer-fingerprinting you don't  
*HAVE* a .crt file (at least, you don't need one, technically) but only 
a .key file. So choosing a different extension for peer-fingerprinting 
does have its merits.


HTH,

JJK



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

Re: [Openvpn-devel] [PATCH] Allow PKCS#11 uri to be used as --cert and --key file names

[Jan Just Keijser]

Hi Selva,
On 05/05/21 15:29, Selva Nair wrote:

On Wed, May 5, 2021 at 4:00 AM Jan Just Keijser  wrote:


On 05/05/21 07:18, selva.n...@gmail.com wrote:

From: Selva Nair 

If either --cert or --key is specified as a PKCS#11 uri, try to
load the certificate and key from any accessible PKCS#11 device.
This does not require linking with any pkcs11 library, but needs
pkcs11 engine to be available on the target machine.

In its simplest form, just have

--cert pkcs11:token=...;serial=... etc..

Either do not specify --key, or use the same uri for --key.

That's all what is required if pkcs11 engine is installed in the
right location and optionally set up to load any necessary provider
libraries (e.g., via openssl.cnf or via PKCS11_MODULE_PATH).

If both cert and key are specified, the last entry takes precedence
and is used to locate both the certificate and key. Use of different
uri's for the cert and key are not supported -- at least not in
this version. Specifying --cert as a file and --key as a uri or
vice versa is treated as a usage error.

If the engine cannot be automatically loaded or a custom engine object
has to be loaded, the engine name or shared libraryx may be embedded
in the PKCS#11 uri. The module shared object path also may be so
embedded. For example,

pkcs11:token=..;serial=...;engine=pkcs11.so;provider=libsofthsm2.so

will use engine with id=pkcs11 and load libsofthsm2.so.

Full path to the libraries may be included as required. These extra,
optional attributes in the URI are stripped before presented to the
PKCS#11 subsystem. Do not include type=cert or type=private in the uri
as the same uri is used for both certificate and private key.

Requires building with OpenSSL engine support although the pkcs11 or
a compatible engine and provider libraries are required only at
run time.

Great patch, but I see one possible security issue upsream with the
ability to specify the pkcs11 driver:

Right now, Linux tools like NetworkManager-openvpn allow a non-root user
to specify certain parameters, like cert, key etc in either a GUI or a
config file.
These tools will *all* need to be updated to take into account (or most
likely : BLOCK) the use of
cert pkcs11: 
as otherwise a rogue user can specify a pkcs11 driver with a backdoor,
which NetworkManager would then happily pass on to the openvpn which
runs as root 

I had first had --pkcs11-id  used for this but currently all pkcs11
related options are conditional on ENABLE_PKCS11 which depends on
pkcs11-helper. Allowing a subset of those options leads to messy
ifdefs which I didn't like.

Maybe I'll have to resurrect that idea or require --script-security 2
for this? In either case the core code will stay the same -- will wait
for a review and/or more comments before changing anything.

wouldn't it make more sense to use the (existing) "--engine" parameter 
for this?   this is closely related to OpenSSL engines (even though the 
pkcs11 module is not loaded directly) .


That way it will be fairly easy for tools like NetworkManager-openvpn to 
filter out any unwanted stuff.


Also, another option would be to allow the loading of a pkcs11 module 
but *only* from predefined locations (e.g. /usr/lib or /usr/lib64) . 
This predefined location would then need to be configured at compile time.


JM2CW,

JJK



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

Re: [Openvpn-devel] [PATCH] Allow PKCS#11 uri to be used as --cert and --key file names

[Jan Just Keijser]

Hi Selva,

On 05/05/21 07:18, selva.n...@gmail.com wrote:

From: Selva Nair 

If either --cert or --key is specified as a PKCS#11 uri, try to
load the certificate and key from any accessible PKCS#11 device.
This does not require linking with any pkcs11 library, but needs
pkcs11 engine to be available on the target machine.

In its simplest form, just have

--cert pkcs11:token=...;serial=... etc..

Either do not specify --key, or use the same uri for --key.

That's all what is required if pkcs11 engine is installed in the
right location and optionally set up to load any necessary provider
libraries (e.g., via openssl.cnf or via PKCS11_MODULE_PATH).

If both cert and key are specified, the last entry takes precedence
and is used to locate both the certificate and key. Use of different
uri's for the cert and key are not supported -- at least not in
this version. Specifying --cert as a file and --key as a uri or
vice versa is treated as a usage error.

If the engine cannot be automatically loaded or a custom engine object
has to be loaded, the engine name or shared libraryx may be embedded
in the PKCS#11 uri. The module shared object path also may be so
embedded. For example,

pkcs11:token=..;serial=...;engine=pkcs11.so;provider=libsofthsm2.so

will use engine with id=pkcs11 and load libsofthsm2.so.

Full path to the libraries may be included as required. These extra,
optional attributes in the URI are stripped before presented to the
PKCS#11 subsystem. Do not include type=cert or type=private in the uri
as the same uri is used for both certificate and private key.

Requires building with OpenSSL engine support although the pkcs11 or
a compatible engine and provider libraries are required only at
run time.
Great patch, but I see one possible security issue upsream with the 
ability to specify the pkcs11 driver:


Right now, Linux tools like NetworkManager-openvpn allow a non-root user 
to specify certain parameters, like cert, key etc in either a GUI or a 
config file.
These tools will *all* need to be updated to take into account (or most 
likely : BLOCK) the use of

  cert pkcs11: 
as otherwise a rogue user can specify a pkcs11 driver with a backdoor, 
which NetworkManager would then happily pass on to the openvpn which 
runs as root 


cheers,

JJK


Signed-off-by: Selva Nair 
---
  Changes.rst  |   6 +
  doc/man-sections/tls-options.rst |  26 
  src/openvpn/options.c|  49 ++-
  src/openvpn/options.h|   3 +
  src/openvpn/ssl.c|  13 +-
  src/openvpn/ssl_backend.h|   3 +
  src/openvpn/ssl_openssl.c| 221 ++-
  7 files changed, 317 insertions(+), 4 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 9185b55f..19d311e3 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -4,6 +4,12 @@ Overview of changes in 2.6
  
  New features

  
+Specification of private key and certificates as PKCS#11 URI
+``--cert`` and ``--key`` options can take RFC7512 PKCS#11
+URI's pointing to certificate and key in a token. Both cert
+and key must use the same URI. Requires OpenSSL with engine
+support and pkcs11 (or compatible) engine installed.
+
  Keying Material Exporters (RFC 5705) based key generation
  As part of the cipher negotiation OpenVPN will automatically prefer
  the RFC5705 based key material generation to the current custom
diff --git a/doc/man-sections/tls-options.rst b/doc/man-sections/tls-options.rst
index 00ea063a..f41d12f3 100644
--- a/doc/man-sections/tls-options.rst
+++ b/doc/man-sections/tls-options.rst
@@ -116,6 +116,29 @@ certificates and keys: https://github.com/OpenVPN/easy-rsa
authority functions, you must set up the files :code:`index.txt` (may be
empty) and :code:`serial` (initialize to :code:`01`).
  
+--cert pkcs11-uri

+  The local peer's certificate in a PKCS#11 token specified as a RFC 7512
+  uri with optional custom attributes described below. Cannot be used with
+  ``--key file``. ``--key`` must be left unspecified or point to the same
+  uri. All other requrements for the certificate described under
+  ``--cert file`` applies.
+
+  Requires OpenSSL with pkcs11 engine installed and configured. Optionally,
+  the engine and provider module may be included as custom attributes in the
+  uri as in the example below:
+
+  ::
+
+--cert 
'pkcs11:token=foo;serial=bar;id=nnn;engine=pkcs11;provider=p11-kit-proxy.so'
+
+  Here the engine name :code:`pkcs11` could be a valid engine-id or path to a
+  shared object. Shared objects in non-standard locations would need to be
+  specified with full path.
+
+  As the same uri is used for certificate and private key, do not include type
+  attribute (i.e., :code: `type=cert;` or :code: `type=private;` should not
+  be included)
+
  --crl-verify args
Check peer certificate against a Certificate Revocation List.
  
@@ -208,6 +231,9 @@ certificates and keys: https://github.com/OpenVPN/easy-rsa

Re: [Openvpn-devel] [PATCH 2/3] Remove --ncp-disable option

[Jan Just Keijser]

Hi Arne, Antonio,

On 09/04/21 11:53, Arne Schwabe wrote:

Am 09.04.21 um 11:24 schrieb Jan Just Keijser:

On 08/04/21 17:52, Gert Doering wrote:

On Thu, Apr 08, 2021 at 05:30:52PM +0200, Jan Just Keijser wrote:

I don't have any evidence with 2.5 right now but this is just a matter
of use/principle to me: I can very well see that I would like to have a
setup *without* NCP as I simply do not need it (e.g. my cipher is
hardwired to aes-256-gcm)  and in that case I don't *want* NCP to ensure
my setup is 100% predictable.

By setting "--data-ciphers AES-256-GCM" on the client side, you achieve
a 100% predictable outcome.  No other cipher will be offered or accepted.

Ah a new 2.5 option - I assume the same thing is true for adding this on
the server side?

And I see that --data-ciphers works only in combination with NCP, that
is, if you do
   --data-ciphers aes-256-gcm --ncp-disable
then --data-ciphers is effectively ignored.  Nice  ;)

Yes data-ciphers (and data-ciphers-fallback) are meant to replace all
other cipher related options eventually.




and I was hoping that this would be resolved before removing something
like --ncp-disable. Having said that, I now see that with openvpn 2.5,
the server mtu is still 1379 in my setup, regardless of whether I use
--ncp-disable or not  - seems to me that is still too low.



Yes DATA_V2 adds 3 bytes compared to DATA_V1.
I understand the 3 bytes (--peerid and such) but is there any way to NOT 
have such a low server-side MTU?
Also note that having a different server-side MTU versus client-side MTU 
makes it even harder to tune the performance

On the client side I now see even more confusing fun:

Server has --ncp-disable set:
- with  --cipher aes-256-cbc  the client side MTU is 1428
- with  --cipher aes-256-gcm  the client side MTU is 1376  <--- huh?

Server does not have --ncp-disable set:
- with  --cipher aes-256-cbc  the client side MTU is 1428
- with  --cipher aes-256-gcm  the client side MTU is 1448
(ok I understand the latter).

What I'd really like to see is a way to get the server-side MTU to also
be 1428/1448 using the right magic options - any idea if that's possible?
The lower the MTU on either side, the lower the maximum bandwidth -
which will hurt especially over low-bandwidth links.

Also, when this option is dropped, does that mean that a 2.4/2.5 client
with the option set can no longer connect to a 2.6 server?

I am not sure how you came to that conclusion. I have written a fairly
comprehensible documentation how NCP in 2.5 works for our manpage:
https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst

That should also answer your question.


Conclusion: a further overhaul of the ncp/cipher/data-ciphers logic
might be in order...
Which is one of my gut reasons for saying : don't remove --ncp-disable
until this mess is thoroughly sorted out.

Please don't mix two things here. Yes the MTU calculation and MTU in
general is broken but shouldn't pollute this discussion here.

And yes we will look into MTU related issues before 2.6 is released but
having a non NCP and a NCP code path for MTU is not helping to reduce
the complexity.


thanks for all the clarifications - esp the cipher-negotiation.rst was 
very helpful.
And I understand the argument about "polluting the discussion" but to me 
the *order* in which things are done is important. That is, for the 2.6 
release all MTU issues should be resolved , so that noone will ever have 
a need to debug MTU issues by dis- or enabling NCP.

So I guess if things were done in the order
  1) fix the MTU issues on both client and server side
  2) drop --ncp-disable
then you would not have heard any complaints from me.

cheers,

JJK



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

Re: [Openvpn-devel] [PATCH 2/3] Remove --ncp-disable option

[Jan Just Keijser]

Hi,

On 08/04/21 17:52, Gert Doering wrote:

Hi,

On Thu, Apr 08, 2021 at 05:30:52PM +0200, Jan Just Keijser wrote:

I don't have any evidence with 2.5 right now but this is just a matter
of use/principle to me: I can very well see that I would like to have a
setup *without* NCP as I simply do not need it (e.g. my cipher is
hardwired to aes-256-gcm)  and in that case I don't *want* NCP to ensure
my setup is 100% predictable.

By setting "--data-ciphers AES-256-GCM" on the client side, you achieve
a 100% predictable outcome.  No other cipher will be offered or accepted.
Ah a new 2.5 option - I assume the same thing is true for adding this on 
the server side?


And I see that --data-ciphers works only in combination with NCP, that 
is, if you do

  --data-ciphers aes-256-gcm --ncp-disable
then --data-ciphers is effectively ignored.  Nice  ;)


Disabling this option means you give me less control over the setup and
I don't like that, thus Feature-NAK.

Removing that option means "less confusing code variants that can lead
to 'it works with NCP but not with NCP disabled'".

Since I test all these variants, and find the confusing corner cases, it
would be good to have less code paths throughout OpenVPN, especially
in the server option negotiation and key setup phases.



I'd say that removing the ability to disable NCP  can happen *only* when
all negative side-effects of enabling it have been mitigated fully.  On
a slow link the NCP overhead can be quite disastrous and not just during
connection setup, but during the *whole* session. To me, yet another
reason for Feature-NAK

The overhead of NCP is roughly "some 100 bytes sent extra from client to
server in the TLS handshake phase" (to announce the acceptable ciphers)
and "cipher xxx" in the PUSH_REPLY.

There is no overhead in the data phase.

Please explain how this can be "quite disastrous"?


(Of course, if NCP negotiates a cipher with more overhead than you'd
like to use, that would be "more overhead" - but this is fully under
the client's control with --data-ciphers.  It even works with "none",
provided both client and server permit this)

I was thinking about this email discussion we had in October 2018:


On 29/10/18 18:08, Gert Doering wrote:

On Mon, Oct 29, 2018 at 05:40:04PM +0100, Jan Just Keijser wrote:

So, the '32' is easily explained. However, the rest of the MTU
calculation baffles me.

Part of this is "peer-id" (+3 bytes) and "the theoretical maximum
crypto + hmac overhead" which 2.3 calculates "for the cipher chosen"
and 2.4 needs to calculale for the worst-case cipher+auth, since it does
not know what the server will push.

In other words, you do not want to know - and the whole "match
configured client/server tun-mtu/link-mtu OCC thingie" is a real 
nuisance.


so I now understand the client MTU:
  openvpn 2.3.18 -> mtu = 1431
  openvpn 2.4.6 -> mtu = 1428 which accounts for peer-id (+3)

but the *server* mtu?!?!?!  I would have expected that with 
--ncp-disable added I would end up with more or less the same MTU as 
with the 2.3 code. Instead I see

  openvpn 2.3.18 -> mtu = 1431
  openvpn 2.4.6 -> mtu = 1379
which is 62 bytes LESS , so even with peer-id subtracted (does it 
apply to the server MTU?)  I end up with 59 bytes unaccounted for *in 
tun mode*.


and I was hoping that this would be resolved before removing something 
like --ncp-disable. Having said that, I now see that with openvpn 2.5, 
the server mtu is still 1379 in my setup, regardless of whether I use 
--ncp-disable or not  - seems to me that is still too low.


On the client side I now see even more confusing fun:

Server has --ncp-disable set:
- with  --cipher aes-256-cbc  the client side MTU is 1428
- with  --cipher aes-256-gcm  the client side MTU is 1376  <--- huh?

Server does not have --ncp-disable set:
- with  --cipher aes-256-cbc  the client side MTU is 1428
- with  --cipher aes-256-gcm  the client side MTU is 1448
(ok I understand the latter).

What I'd really like to see is a way to get the server-side MTU to also 
be 1428/1448 using the right magic options - any idea if that's possible?
The lower the MTU on either side, the lower the maximum bandwidth - 
which will hurt especially over low-bandwidth links.


Also, when this option is dropped, does that mean that a 2.4/2.5 client 
with the option set can no longer connect to a 2.6 server?


Conclusion: a further overhaul of the ncp/cipher/data-ciphers logic 
might be in order...
Which is one of my gut reasons for saying : don't remove --ncp-disable 
until this mess is thoroughly sorted out.



JM2CW,

JJK


=
Client config:

client
proto udp
remote $SERVER
port 1194
dev tun
nobind
remote-cert-tls server
ca   ca.crt
cert client1.crt
key  client1.key
cipher aes-256-cbc
auth   sha256
link-mtu 1500
frag

Re: [Openvpn-devel] [PATCH 2/3] Remove --ncp-disable option

[Jan Just Keijser]

On 08/04/21 16:55, Arne Schwabe wrote:

Am 08.04.21 um 16:36 schrieb Jan Just Keijser:

Hi,

On 08/04/21 16:02, Arne Schwabe wrote:

NCP has proven to be stable and apart from the one VPN Provider doing
hacky things with homebrewed NCP we have not had any reports about
ncp-disable being required. Remove ncp-disable to simplify code paths.

Note: This patch breaks client without --pull. The follow up patch
for P2P NCP will restore that. But to avoid all the NCP/non-NCP special
cases to be implemented in P2P. P2P will directly switch from always
non-NCP to always NCP.

I would Feature-NAK this :   disabling NCP is a valuable option. IMHO.

I disagree here. NCP in 2.5 is mature mature enough that disabling NCP
is not necessary any more. If you have any evidence otherwise, please
explain a bit more since I personally don't see the value in it.


I don't have any evidence with 2.5 right now but this is just a matter 
of use/principle to me: I can very well see that I would like to have a 
setup *without* NCP as I simply do not need it (e.g. my cipher is 
hardwired to aes-256-gcm)  and in that case I don't *want* NCP to ensure 
my setup is 100% predictable.


Disabling this option means you give me less control over the setup and 
I don't like that, thus Feature-NAK.

Also, is the MTU calculation part on the server side now done
correctly?    I remember that with 2.4 the server would subtract (or
add, depending on point of iew) far too many bytes to handle NCP


Not fully yet but the case where NCP cipher == original cipher has a
workaround.


I'd say that removing the ability to disable NCP  can happen *only* when 
all negative side-effects of enabling it have been mitigated fully.  On 
a slow link the NCP overhead can be quite disastrous and not just during 
connection setup, but during the *whole* session. To me, yet another 
reason for Feature-NAK


JJK



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

Re: [Openvpn-devel] [PATCH 2/3] Remove --ncp-disable option

[Jan Just Keijser]

Hi,

On 08/04/21 16:02, Arne Schwabe wrote:

NCP has proven to be stable and apart from the one VPN Provider doing
hacky things with homebrewed NCP we have not had any reports about
ncp-disable being required. Remove ncp-disable to simplify code paths.

Note: This patch breaks client without --pull. The follow up patch
for P2P NCP will restore that. But to avoid all the NCP/non-NCP special
cases to be implemented in P2P. P2P will directly switch from always
non-NCP to always NCP.

I would Feature-NAK this :   disabling NCP is a valuable option. IMHO.

Also, is the MTU calculation part on the server side now done 
correctly?    I remember that with 2.4 the server would subtract (or 
add, depending on point of iew) far too many bytes to handle NCP


JJK


Signed-off-by: Arne Schwabe 
---
  Changes.rst   |  4 +++
  doc/man-sections/protocol-options.rst |  8 ++
  src/openvpn/init.c| 17 -
  src/openvpn/multi.c   |  4 ---
  src/openvpn/options.c | 36 +++
  src/openvpn/options.h |  1 -
  src/openvpn/ssl.c |  3 +--
  src/openvpn/ssl_common.h  |  1 -
  src/openvpn/ssl_ncp.c |  4 ---
  9 files changed, 16 insertions(+), 62 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 457dfc07e..d6ccc1c92 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -47,6 +47,10 @@ Deprecated features
  is considered "too complicated", using ``--peer-fingerprint`` makes
  TLS mode about as easy as using ``--secret``.
  
+``ncp-disable`` has been removed

+This option mainly served a role as debug option when NCP was first
+introduced. It should now no longer be necessary.
+
  Overview of changes in 2.5
  ==
  
diff --git a/doc/man-sections/protocol-options.rst b/doc/man-sections/protocol-options.rst

index 4b6928c68..fe8ca8fd1 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -65,8 +65,8 @@ configured in a compatible way between both the local and 
remote side.
The default is :code:`BF-CBC`, an abbreviation for Blowfish in Cipher
Block Chaining mode. When cipher negotiation (NCP) is allowed,
OpenVPN 2.4 and newer on both client and server side will automatically
-  upgrade to :code:`AES-256-GCM`.  See ``--data-ciphers`` and
-  ``--ncp-disable`` for more details on NCP.
+  upgrade to :code:`AES-256-GCM`.  See ``--data-ciphers`` for more details
+  on NCP.
  
Using :code:`BF-CBC` is no longer recommended, because of its 64-bit

block size. This small block size allows attacks based on collisions, as
@@ -230,10 +230,6 @@ configured in a compatible way between both the local and 
remote side.
  have been configured with `--enable-small`
  (typically used on routers or other embedded devices).
  
---ncp-disable

-  **DEPRECATED** Disable "Negotiable Crypto Parameters". This completely
-  disables cipher negotiation.
-
  --secret args
**DEPRECATED** Enable Static Key encryption mode (non-TLS). Use pre-shared 
secret
``file`` which was generated with ``--genkey``.
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 28d183aa0..4a6b84914 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2226,18 +2226,14 @@ pull_permission_mask(const struct context *c)
  | OPT_P_EXPLICIT_NOTIFY
  | OPT_P_ECHO
  | OPT_P_PULL_MODE
-| OPT_P_PEER_ID;
+| OPT_P_PEER_ID
+| OPT_P_NCP;
  
  if (!c->options.route_nopull)

  {
  flags |= (OPT_P_ROUTE | OPT_P_IPWIN32);
  }
  
-if (c->options.ncp_enabled)

-{
-flags |= OPT_P_NCP;
-}
-
  return flags;
  }
  
@@ -2734,8 +2730,6 @@ do_init_crypto_tls_c1(struct context *c)

  *
  * Therefore, the key structure has to be initialized when:
  * - any non-BF-CBC cipher was selected; or
-* - BF-CBC is selected and NCP is disabled (explicit request to
-*   use the BF-CBC cipher); or
  * - BF-CBC is selected, NCP is enabled and fallback is enabled
  *   (BF-CBC will be the fallback).
  * - BF-CBC is in data-ciphers and we negotiate to use BF-CBC:
@@ -2745,12 +2739,12 @@ do_init_crypto_tls_c1(struct context *c)
  * Note that BF-CBC will still be part of the OCC string to retain
  * backwards compatibility with older clients.
  */
-if (!streq(options->ciphername, "BF-CBC") || !options->ncp_enabled
-|| (options->ncp_enabled && tls_item_in_cipher_list("BF-CBC", 
options->ncp_ciphers))
+if (!streq(options->ciphername, "BF-CBC")
+|| tls_item_in_cipher_list("BF-CBC", options->ncp_ciphers)
  || options->enable_ncp_fallback)
  {
  /* Do not warn if the if the cipher is used only in OCC */
-bool warn = !options->ncp_enabled || options->enable_ncp_fallback;
+

Re: [Openvpn-devel] is it possible to store saved password in tpm instead of registry ?

[Jan Just Keijser]

Hi,

On 13/01/21 19:29, Илья Шипицин wrote:



ср, 13 янв. 2021 г. в 22:01, Jan Just Keijser <mailto:janj...@nikhef.nl>>:


Hi,

On 13/01/21 17:20, Илья Шипицин wrote:
> Hello,
>
> if user save password, it might be stolen from well known location
> (there are popular password stealers).
>
> in theory, is it possible to keep password in tpm ? will it prevent
> password from being stolen ?
>
in theory, yes, but as always, it depends on the circumstances.

With TPM 1.2 you can only store a very limited amount of data in
the TPM
chip; the (open source) implementation I have seen (tss, trousers)
store


I meant openvpn-gui + user/password authentication + password is kept 
in registry encrypted by data protection api (not clear text, but 
might be decrypted and stolen easily).


trousers is linux, right ?

ah yes, indeed, trousers is Linux; I guess I defaulted to Open source 
software for an open source VPN ;)


As for storing any old password in a TPM: yes that seems possible in 
Windows 10 (with the right TPM support, I presume). For example, this

https://superuser.com/questions/1527685/how-to-remove-webauthn-credentials-from-onboard-tpm-on-win10-device?rq=1

posts that someone wants to *get rid* of edge/chrome authn details 
stored in the TPM.
Could be that support for this is also present in chromium, which means 
you should be able to find the source code that does this.


HTH,

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

Re: [Openvpn-devel] is it possible to store saved password in tpm instead of registry ?

[Jan Just Keijser]

Hi,

On 13/01/21 17:20, Илья Шипицин wrote:

Hello,

if user save password, it might be stolen from well known location 
(there are popular password stealers).


in theory, is it possible to keep password in tpm ? will it prevent 
password from being stolen ?



in theory, yes, but as always, it depends on the circumstances.

With TPM 1.2 you can only store a very limited amount of data in the TPM 
chip; the (open source) implementation I have seen (tss, trousers) store 
a key in the TPM to scramble other data with; thus, you can encrypt a 
private key or password with a key stored on the TPM and only if you 
have the TPM will you be able to decrypt it.
I've never been particularly impressed with the security of this setup, 
however, as trousers seems to suggest to store the actualy decryption 
key in an environment variable...


With TPM 2.0 you can store more data in the chip, including a full 
private key. This makes it behave more like a regular PKCS#11 device, 
where you store the private key, not the user password on it. Of course, 
it will/should also be possible to store a user password on it.


cheers,

JJK



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

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

[Jan Just Keijser]

On 21/12/20 18:22, Selva Nair wrote:



On Mon, Dec 21, 2020 at 2:04 AM Gert Doering > wrote:


Hi,

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

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

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


For those who have lost the original threads:

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

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

That was in Nov-Dec 2017. Actually, I was also thinking of reviving 
this only the other day when intimating users about some updates 
came up.. Somehow such itches re-surface at the end of the year :)


sorry to chip on so late, but at some point we did have a way to push 
env vars to the client (back in v2.2 at least):


inside a client-connect script you can/could do

echo "push \"setenv-safe MSG1 'hello'\"" > $1
echo "push \"setenv-safe MSG2 'download version 2.5 please'\"" >> $1

and then on the client-side you'd simply have to process them (as 
OPENVPN_MSG1 and OPENVPN_MSG2) - couldn't we reuse that to send messages 
to a connected client?


Sending messages to an unauthenticated client - other than "wrong 
password , go away" - seems dangerous to me.


JM2CW,

JJK


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

Re: [Openvpn-devel] weird issue with server failover when *Not* using keepalive

[Jan Just Keijser]

Hi,

On 04/12/20 16:24, Arne Schwabe wrote:

If I change the client config to list only a single
   remote  1194 udp
line then this reconnect behavior does NOT occur ?!?!?!?


This might be a bug in the initialisation order. That the ping timer is
armed before next_connection_entry is called. If you force it reconnect
by restarting server or kill -USR1, does it then also show the
disconnect after 120s behaviour?


Following up to myself here. There are probably three problems here
mixed together:

a) --pull implies --ping-restart and --ping pushed by the server for UDP
but the next_connection entry/update currently does not work correctly
so it is not working all the time.

where is this implied in the code? I couldn't find it in the 2.4.9 codebase

b) the ping related options are missing in the options_pre_pull, so they
also get applied to connections after an UDP setting.

c) the warning for keepalive in server mode + UDP should be a lot
stronger as the timeout after 120s+UDP is intended behaviour.

if 'keepalive' is a *requirement* for server mode + UDP but not for 
server mode + TCP then it's still a bug, as a config file with entries


remote server 1194 udp
remote server 1194 tcp

fails with the observed behaviour  if the tcp server does not have 
keepalive se.


Also, if 'keepalive' is a *requirement* then it should be set 
mandatorily in server mode with sane defaults (like 'keepalive 10 60' ) .


The original bug still stands:

If I have a working setup, e.g.  server mode+TCP with no keepalive 
(which makes sense) and on the client side I add a line

  remote server 1194 udp

then the *TCP* server config should continue to work instead of 
restarting every 120 seconds, regardless of how I configurd my UDP server.


JJK


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

Re: [Openvpn-devel] [ovpn-dco] AES-CCM available for testing

[Jan Just Keijser]

Hi Antonio,

On 07/12/20 10:56, Antonio Quartulli wrote:

Hi Jan Just, Tony,

On 07/12/2020 10:10, Jan Just Keijser wrote:

Thank you very much for adding this so quickly; it won't help Tony He
though, as he is stuck using a rather old AL314 + R9000 chip which does
not support CCM or GCM. I just checked the driver code and indeed there
is no HW support for GCM.  They *do* support some AEAD algorithms:

   authenc-hmac-sha256-cbc-aes
   authenc-hmac-sha384-cbc-aes

which are listed as the (true) AEAD equivalent of AES+SHA ; the question
is : how hard would it be to add support for this (and would it be worth
it?)

I would ask the same question to the vendor: how hard would it be to
support AES-GCM in the current HW engine?

Any info about that?
They are the best recipient for such feature request I think.

As far as I understood the HW engine is also open source, so actually
anybody with the right motivation could take up that task.
I fully agree; however, the last change to the kernel driver for that 
hardware was made over 3 years ago , so I suspect that it will be hard 
to get GCM support for it.


Forcing ourselves to sticking to legacy algorithms is not the right
move, imho (especially when there are solutions - see above).
To answer your question: my feeling is that working on it is not worth
the benefit.


again, I tend to agree *but* when you say that 'openvpn-dco only 
supports AEAD crypto algorithms" you can expect that sooner or later 
someone will ask the question "how about authenc-hmac-sha256-cbc-aes ?"  
because that *IS* an AEAD algorithm after all.


But without support in OpenVPN 2.x for this the point is moot, as far as 
I am concerned, as supporting something only in the kernel driver will 
make it interoperable with the open source  community version of OpenVPN.


cheers,

JJK



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

Re: [Openvpn-devel] [ovpn-dco] AES-CCM available for testing

[Jan Just Keijser]

Hi Antonio,

On 06/12/20 17:09, Antonio Quartulli wrote:

Hi all,

Some people have expressed interest in ovpn-dco supporting AES-CBC.

However, since ovpn-dco is currently using the AEAD kernel crypto API
only, introducing support for CBC mode would require quite some
refactoring and we do not really want to do that (the community believes
that as of now AEAD ciphers should always be preferred moving forward).

In a previous discussion on this mailing list, it was highlighted that
AES-CCM is nothing else than AES-CBC in disguise as AEAD cipher.

(for the curious: it is AES "Counter with CBC-MAC", known as CCM and
described in RFC3610).

For this reason I decided to give AES-CCM a try and I implemented in it
the "aes-ccm" branch of the ovpn-dco repo.

I am not sure if we're going to merge it to master yet, but for now it
would be interesting to gather feedback from those interested in this
cipher.

Please note that OpenVPN3 does not yet support this cipher, therefore
the only way to test AES-CCM in ovpn-dco is to use the ovpn-cli tool
provided in the tests/ folder.


To do so, just specify "aes-ccm" as algorithm when setting a new key.




excellent news!
Thank you very much for adding this so quickly; it won't help Tony He 
though, as he is stuck using a rather old AL314 + R9000 chip which does 
not support CCM or GCM. I just checked the driver code and indeed there 
is no HW support for GCM.  They *do* support some AEAD algorithms:


  authenc-hmac-sha256-cbc-aes
authenc-hmac-sha384-cbc-aes

which are listed as the (true) AEAD equivalent of AES+SHA ; the question 
is : how hard would it be to add support for this (and would it be worth 
it?)


cheers,

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

Re: [Openvpn-devel] weird issue with server failover when *Not* using keepalive

[Jan Just Keijser]

Hi,

On 04/12/20 15:38, Arne Schwabe wrote:

Am 04.12.20 um 11:59 schrieb Jan Just Keijser:

hey guys,

I'm posting this on behalf of the eduVPN team. François Kooman spent a
long time debugging an issue and finally managed to find the piece of
code that causes the weird behavior.
Let me explain:

For eduVPN, multiple openvpn instances are offered , both on UDP and TCP
ports and the client config that is used lists all of these instances.
The client can then do automatic roll-over to a TCP based setup if UDP
is not working (blocked) for some reason.
Now François had *not* set the keepalive option in the TCP setup, as a
TCP connection has a keepalive of its own, more or less and this caused
some very odd behaviour:

1) the client tries to connect to a UDP based server; server is
down/blocked, hence openvpn does a failover to the next client
2) openvpn connects but after exactly 2 minutes the connection is restarted
3) the reconnects keep happening every 2 minutes suggesting it is a
ping-restart/keepalive setting

We've tracked this down to the following piece of code, which has been
present in the OpenVPN code base since v2.1 (which was the first version
to support connection entries). File is init.c, here from v2.4.9:

  188 static void
  189 update_options_ce_post(struct options *options)
  190 {
  191 #if P2MP
  192 /*
  193  * In pull mode, we usually import --ping/--ping-restart
parameters from
  194  * the server.  However we should also set an initial default
--ping-restart
  195  * for the period of time before we pull the --ping-restart
parameter
  196  * from the server.
  197  */
  198 if (options->pull
  199 && options->ping_rec_timeout_action == PING_UNDEF
  200 && proto_is_dgram(options->ce.proto))
  201 {
  202 options->ping_rec_timeout = PRE_PULL_INITIAL_PING_RESTART;
  203 options->ping_rec_timeout_action = PING_RESTART;
  204 }
  205 #endif
  206 }

When failing over, this function 'update_options_ce_post' is called and
for UDP based connections, the ping_rec_timeout is updated.
*Why?*
Note that ping_rec_timeout is a GLOBAL option and affects all connection
entries, both TCP and UDP based. Comment out the call to
'update_options_ce_post' and the restarts are gone.
Shall we just comment out/remove this particular piece of code altogether?

No it still serves a purpose in normal/other setups. It just breaks
*your* setup. Without this a client can be stuck forever if the
connection times out after the control channel has been established but
not received a PUSH_REPLY if my quick analysis here is correct.
No, this happens even without ANY control channel establishment if 
that were the case we should change the logic to set a ping-rec timer 
for UDP connections after the control channel has been established (or 
whenever we've received ANY reply from the server). My example shows 
that this timer is set even if the first server never responds at all.

But the logic of is_dgram and how it is set is strange, I definitively
grant you that. This might also a bug that got more exposed by my
removal of the non-connection logic in OpenVPN 2.4. Before OpenVPN 2.4
we had completely different code paths for profiles containing
 and profiles without for handling those.


This code path is present from 2.1 on, in more or less unaltered form

JJK


JJK

PS This leads me to think that perhaps the ping-* options should be made
connection-entry specific.  That way, you can have different behavior
for TCP based setups and UDP based setups. Also note (see below) that
this problem also affect failover from one UDP based server to the next
, if --keepalive is disabled, so it's not "just" UDP vs TCP.

Normally keepalive settings should be by the server since a mismatching
keepalive between client and server is not a good idea anyway.
yes but like you said, sometimes it may be wise to set keepalive timers 
*before* the connection has been established. Also, with server 
failover, the keepalive timers should be reset from connection entry to 
connection entry.



I managed to recreate this setup and I can even get the same odd
behaviour in a 100% UDP based setup.
Server config:
###
proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
dh   dh2048.pem
ca   ca.crt
cert server.crt
key  server.key
persist-key
persist-tun
topology subnet
user  nobody
group nobody  # use "group nogroup" on some distros
cipher aes-256-cbc
auth   sha256
###

(yes, I know the server blurts out
   WARNING: --keepalive option is missing from server config
on startup)

Client config:
###
client
remote  1195 udp  ## use a non available port first
remote  1194 udp
### remote  1195 tcp
dev tun
nobind
remote-cert-tls server
ca   ca.crt
cert client1.crt
key  client1.key
cipher aes-256-cbc
auth   sha256
##

[Openvpn-devel] weird issue with server failover when *Not* using keepalive

[Jan Just Keijser]

hey guys,

I'm posting this on behalf of the eduVPN team. François Kooman spent a 
long time debugging an issue and finally managed to find the piece of 
code that causes the weird behavior.

Let me explain:

For eduVPN, multiple openvpn instances are offered , both on UDP and TCP 
ports and the client config that is used lists all of these instances. 
The client can then do automatic roll-over to a TCP based setup if UDP 
is not working (blocked) for some reason.
Now François had *not* set the keepalive option in the TCP setup, as a 
TCP connection has a keepalive of its own, more or less and this caused 
some very odd behaviour:


1) the client tries to connect to a UDP based server; server is 
down/blocked, hence openvpn does a failover to the next client

2) openvpn connects but after exactly 2 minutes the connection is restarted
3) the reconnects keep happening every 2 minutes suggesting it is a 
ping-restart/keepalive setting


We've tracked this down to the following piece of code, which has been 
present in the OpenVPN code base since v2.1 (which was the first version 
to support connection entries). File is init.c, here from v2.4.9:


 188 static void
 189 update_options_ce_post(struct options *options)
 190 {
 191 #if P2MP
 192 /*
 193  * In pull mode, we usually import --ping/--ping-restart 
parameters from
 194  * the server.  However we should also set an initial default 
--ping-restart
 195  * for the period of time before we pull the --ping-restart 
parameter

 196  * from the server.
 197  */
 198 if (options->pull
 199 && options->ping_rec_timeout_action == PING_UNDEF
 200 && proto_is_dgram(options->ce.proto))
 201 {
 202 options->ping_rec_timeout = PRE_PULL_INITIAL_PING_RESTART;
 203 options->ping_rec_timeout_action = PING_RESTART;
 204 }
 205 #endif
 206 }

When failing over, this function 'update_options_ce_post' is called and 
for UDP based connections, the ping_rec_timeout is updated.

*Why?*
Note that ping_rec_timeout is a GLOBAL option and affects all connection 
entries, both TCP and UDP based. Comment out the call to 
'update_options_ce_post' and the restarts are gone.

Shall we just comment out/remove this particular piece of code altogether?

JJK

PS This leads me to think that perhaps the ping-* options should be made 
connection-entry specific.  That way, you can have different behavior 
for TCP based setups and UDP based setups. Also note (see below) that 
this problem also affect failover from one UDP based server to the next 
, if --keepalive is disabled, so it's not "just" UDP vs TCP.


-
For completeness:

I managed to recreate this setup and I can even get the same odd 
behaviour in a 100% UDP based setup.

Server config:
###
proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
dh   dh2048.pem
ca   ca.crt
cert server.crt
key  server.key
persist-key
persist-tun
topology subnet
user  nobody
group nobody  # use "group nogroup" on some distros
cipher aes-256-cbc
auth   sha256
###

(yes, I know the server blurts out
  WARNING: --keepalive option is missing from server config
on startup)

Client config:
###
client
remote  1195 udp  ## use a non available port first
remote  1194 udp
### remote  1195 tcp
dev tun
nobind
remote-cert-tls server
ca   ca.crt
cert client1.crt
key  client1.key
cipher aes-256-cbc
auth   sha256


So the client first connects to a (non-existent) server, and then fails 
over to the second entry, and we get a connection. Then, every 2 minutes 
we get a connection restart.


If I change the client config to list only a single
  remote  1194 udp
line then this reconnect behavior does NOT occur ?!?!?!?

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

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

[Jan Just Keijser]

hi Tony,

On 04/12/20 11:12, Tony He wrote:

Hi Jan,

>what HW engine is this?  I think your best bet is to actually get the 
engine to support GCM; with AES and SHA acceleration in place there is 
very little to stop the HW engine from not being able to support GCM..
The HW engine is a part of SoC al314. It connects with A15 CPU via PCI 
in SoC. Chip vendor will not support GCM due to all kinds of reasons.



ah pity, and the source code to this HW engine is closed source?
>the numbers do suggest some form of cryptodev acceleration - can you 
unload the cryptodev module or block access to it (e.g. chmod 000 
/dev/crypto) ?
In my second set of test numbers, I uploaded the cryptodev moduled. 
You can see the CCM performance is almost same.


actually, I see the same on my i5-6800 with OpenSSL 1.0.2m but NOT with 
OpenSSL 1.1.1g; this leads me to believe that CCM support in the openssl 
1.0.x speed command is screwed up.   It will be worthwhile to build 
openssl 1.1.1 for the AL314 just to see if aes-128-ccm is a viable 
option or not.


JJK

Jan Just Keijser mailto:janj...@nikhef.nl>> 
于2020年12月4日周五 下午5:49写道：


Hi Tony,

On 04/12/20 08:41, Tony He wrote:

Hi Jan,
Yeah, need option " -elapsed" because OpenSSL counts user time
instead of total time(user+sys time) without this option. You can
see:
* aes-128-cbc and sha1 are accelerated by HW engine. I believe
speed is faster for openvpn dco module because it uses the HW
engine in kernel space and bypasses the path between openssl and
cryptodev.

that is correct the openvpn dco module sits in kernel space and
does need to pass the userspace<->kernelspace barrier and thus
should have better performance

* aes-128-gcm is NOT accelerated by HW engine.

what HW engine is this?  I think your best bet is to actually get
the engine to support GCM; with AES and SHA acceleration in place
there is very little to stop the HW engine from not being able to
support GCM...

* aes-128-ccm is NOT accelerated by HW engine but it seems that
it is accelerated by HW instruction or other. I don't know my
device has such function. SoC type is al314.

the numbers do suggest some form of cryptodev acceleration - can
you unload the cryptodev module or block access to it (e.g. chmod
000 /dev/crypto) ?

The AL314 is a quad core Cortex A15 CPU @ 1.7 GHz ; the numbers
*without* cryptodev look about right for that particular CPU.

Most modern crypto packages use AES-GCM or chacha20-poly1305 as
they are considered more secure. CBC is considered a bit outdated
and as far as I know no openvpn release supports CCM thus far
(which is a shame, really).

HTH,

JJK




With cryptodev: # openssl speed -evp aes-128-cbc -elapsed You
have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 252783 aes-128-cbc's
in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 253044
aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size
blocks: 251746 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on
1024 size blocks: 190306 aes-128-cbc's in 3.00s Doing aes-128-cbc
for 3s on 8192 size blocks: 122657 aes-128-cbc's in 3.00s
.. type 16 bytes 64 bytes 256 bytes 1024
bytes 8192 bytes aes-128-cbc 1348.18k 5398.27k 21482.33k
64957.78k 334935.38k # openssl speed -evp aes-128-gcm -elapsed
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-gcm for 3s on 16 size blocks: 3509485 aes-128-gcm's
in 3.00s Doing aes-128-gcm for 3s on 64 size blocks: 900678
aes-128-gcm's in 3.00s Doing aes-128-gcm for 3s on 256 size
blocks: 228961 aes-128-gcm's in 3.00s Doing aes-128-gcm for 3s on
1024 size blocks: 57475 aes-128-gcm's in 3.00s Doing aes-128-gcm
for 3s on 8192 size blocks: 7189 aes-128-gcm's in 3.00s
.. type 16 bytes 64 bytes 256 bytes 1024 bytes
8192 bytes aes-128-gcm 18717.25k 19214.46k 19538.01k 19618.13k
19630.76k
# openssl speed -evp aes-128-ccm -elapsed You have chosen to
measure elapsed time instead of user CPU time. Doing aes-128-ccm
for 3s on 16 size blocks: 10179383 aes-128-ccm's in 3.00s Doing
aes-128-ccm for 3s on 64 size blocks: 10179215 aes-128-ccm's in
3.00s Doing aes-128-ccm for 3s on 256 size blocks: 10179785
aes-128-ccm's in 3.00s Doing aes-128-ccm for 3s on 1024 size
blocks: 10182095 aes-128-ccm's in 3.00s Doing aes-128-ccm for 3s
on 8192 size blocks: 10179225 aes-128-ccm's in 3.00s
.. type 16 bytes 64 bytes 256 bytes 1024 bytes
8192 bytes aes-128-ccm 54290.04k 217156.59k 868674.99k
3475488.43k 27796070.40k # openssl speed -evp sha1 -elapsed You
have chosen to measure elapsed time instead of user CPU time.
Doing s

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

[Jan Just Keijser]

128-gcm's in 3.00s Doing aes-128-gcm for 
3s on 256 size blocks: 228857 aes-128-gcm's in 3.00s Doing aes-128-gcm 
for 3s on 1024 size blocks: 57411 aes-128-gcm's in 3.00s Doing 
aes-128-gcm for 3s on 8192 size blocks: 7188 aes-128-gcm's in 3.00s 
 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 
bytes aes-128-gcm 18706.25k 19222.10k 19529.13k 19596.29k 19628.03k
# openssl speed -evp aes-128-ccm -elapsed You have chosen to measure 
elapsed time instead of user CPU time. Doing aes-128-ccm for 3s on 16 
size blocks: 10170897 aes-128-ccm's in 3.00s Doing aes-128-ccm for 3s 
on 64 size blocks: 10167692 aes-128-ccm's in 3.00s Doing aes-128-ccm 
for 3s on 256 size blocks: 10166117 aes-128-ccm's in 3.00s Doing 
aes-128-ccm for 3s on 1024 size blocks: 10167095 aes-128-ccm's in 
3.00s Doing aes-128-ccm for 3s on 8192 size blocks: 10172046 
aes-128-ccm's in 3.00s . type 16 bytes 64 bytes 256 
bytes 1024 bytes 8192 bytes aes-128-ccm 54244.78k 216910.76k 
867508.65k 3470368.43k 27776466.94k
openssl speed -evp sha1 -elapsed You have chosen to measure elapsed 
time instead of user CPU time. Doing sha1 for 3s on 16 size blocks: 
1877571 sha1's in 3.00s Doing sha1 for 3s on 64 size blocks: 1250523 
sha1's in 3.00s Doing sha1 for 3s on 256 size blocks: 603090 sha1's in 
3.00s Doing sha1 for 3s on 1024 size blocks: 198963 sha1's in 3.00s 
Doing sha1 for 3s on 8192 size blocks: 27380 sha1's in 3.00s 
... type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 
sha1 10013.71k 26677.82k 51463.68k 67912.70k 74765.65k

Tony

Jan Just Keijser mailto:janj...@nikhef.nl>> 
于2020年12月2日周三 下午11:24写道：


Hi Tony,

On 02/12/20 15:51, Jan Just Keijser wrote:


On 02/12/20 15:22, Tony He wrote:

Hi Jan,

Welcome to join the discussion.

>the second set of numbers doesn't make sense, and a much better
test is to do an actual encryption test
I don't compile cryptodev kernel module for my PC and can not
reproduce this issue for now.  You don't understand  the reason
why the performance is much worse with cryptodev module for
*big* blocks, right?
If yes, I guess the reason maybe kernel assign the work to multi
cores while OpenSSL uses one core. Would you share the output of
command "mpstat -P ALL 2"?


sure, while using the cryptodev I see this:

15:28:36 CPU    %usr   %nice    %sys %iowait    %irq %soft 
%steal  %guest  %gnice   %idle
15:28:38 all    1.87    0.00   23.19    0.12 0.00    0.00   
0.00    0.00    0.00   74.81
15:28:38   0    0.00    0.00    0.00    0.50 0.00    0.00   
0.00    0.00    0.00   99.50
15:28:38   1    7.00    0.00   93.00    0.00 0.00    0.00   
0.00    0.00    0.00    0.00
15:28:38   2    0.00    0.00    0.00    0.00 0.00    0.00   
0.00    0.00    0.00  100.00
15:28:38   3    0.00    0.00    0.00    0.00 0.00    0.00   
0.00    0.00    0.00  100.00

15:28:38 CPU    %usr   %nice    %sys %iowait    %irq %soft 
%steal  %guest  %gnice   %idle
15:28:40 all    0.75    0.00   24.19    0.00 0.00    0.00   
0.00    0.00    0.00   75.06
15:28:40   0    0.00    0.00    0.00    0.50 0.00    0.00   
0.00    0.00    0.00   99.50
15:28:40   1    3.50    0.00   96.50    0.00 0.00    0.00   
0.00    0.00    0.00    0.00
15:28:40   2    0.00    0.00    0.00    0.00 0.00    0.00   
0.00    0.00    0.00  100.00
15:28:40   3    0.00    0.00    0.00    0.00 0.00    0.00   
0.00    0.00    0.00  100.00

on a 4 core box; this means that 1 core is used 100% (which is
what I expected).


I suspect the main reason the cryptodev results on my i5-6800 go
off the rails is due to this:
(look at the "Doing aes-128-cbc lines")

$ ./openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 2835368 aes-128-cbc's
in 1.14s
Doing aes-128-cbc for 3s on 64 size blocks: 2720745 aes-128-cbc's
in 1.01s
Doing aes-128-cbc for 3s on 256 size blocks: 2377830
aes-128-cbc's in *0.74s*
Doing aes-128-cbc for 3s on 1024 size blocks: 1538693
aes-128-cbc's in *0.40s*
Doing aes-128-cbc for 3s on 8192 size blocks: 370202
aes-128-cbc's in *0.11s*
OpenSSL 1.0.2m  2 Nov 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial)
idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV
-DUSE_CRYPTODEV_DIGESTS -Wa,--noexecstack -m64 -DL_ENDIAN -O3
-Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL

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

[Jan Just Keijser]

Hi Tony,

On 02/12/20 15:51, Jan Just Keijser wrote:


On 02/12/20 15:22, Tony He wrote:

Hi Jan,

Welcome to join the discussion.

>the second set of numbers doesn't make sense, and a much better test 
is to do an actual encryption test
I don't compile cryptodev kernel module for my PC and can not 
reproduce this issue for now.  You don't understand  the reason why 
the performance is much worse with cryptodev module for *big* blocks, 
right?
If yes, I guess the reason maybe kernel assign the work to multi 
cores while OpenSSL uses one core. Would you share the output of 
command "mpstat -P ALL 2"?



sure, while using the cryptodev I see this:

15:28:36 CPU    %usr   %nice    %sys %iowait    %irq   %soft 
%steal  %guest  %gnice   %idle
15:28:38 all    1.87    0.00   23.19    0.12    0.00 0.00    
0.00    0.00    0.00   74.81
15:28:38   0    0.00    0.00    0.00    0.50    0.00 0.00    
0.00    0.00    0.00   99.50
15:28:38   1    7.00    0.00   93.00    0.00    0.00 0.00    
0.00    0.00    0.00    0.00
15:28:38   2    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00    0.00  100.00
15:28:38   3    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00    0.00  100.00


15:28:38 CPU    %usr   %nice    %sys %iowait    %irq   %soft 
%steal  %guest  %gnice   %idle
15:28:40 all    0.75    0.00   24.19    0.00    0.00 0.00    
0.00    0.00    0.00   75.06
15:28:40   0    0.00    0.00    0.00    0.50    0.00 0.00    
0.00    0.00    0.00   99.50
15:28:40   1    3.50    0.00   96.50    0.00    0.00 0.00    
0.00    0.00    0.00    0.00
15:28:40   2    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00    0.00  100.00
15:28:40   3    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00    0.00  100.00


on a 4 core box; this means that 1 core is used 100% (which is what I 
expected).



I suspect the main reason the cryptodev results on my i5-6800 go off 
the rails is due to this:

(look at the "Doing aes-128-cbc lines")

$ ./openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 2835368 aes-128-cbc's in 1.14s
Doing aes-128-cbc for 3s on 64 size blocks: 2720745 aes-128-cbc's in 1.01s
Doing aes-128-cbc for 3s on 256 size blocks: 2377830 aes-128-cbc's in 
*0.74s*
Doing aes-128-cbc for 3s on 1024 size blocks: 1538693 aes-128-cbc's in 
*0.40s*
Doing aes-128-cbc for 3s on 8192 size blocks: 370202 aes-128-cbc's in 
*0.11s*

OpenSSL 1.0.2m  2 Nov 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) 
idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM 
-DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes    256 bytes   1024 bytes 8192 
bytes
aes-128-cbc  39794.64k   172403.64k   822600.65k  3939054.08k 
27569952.58k



The timing for how quickly the results are returned are way off and 
probably just wrong. The Openssl speed test is supposed to run for 3 
seconds. The actual results returned for 8192 byte blocks is


Doing aes-128-cbc for 3s on 8192 size blocks: 370202 aes-128-cbc's in 
*0.11s*


whereas without cryptodev I see

Doing aes-128-cbc for 3s on 8192 size blocks: 457255 aes-128-cbc's in 
*3.00s*


So you can see that without cryptodev the i5-6800 actually says it's 
doing more blocks (457,255 vs 370,202) but with cryptodev it is doing 
it in WAY less time.  This leads me to believe the openssl speed code 
when using cryptodev just "goes wrong".
It will be very interesting to see what the encryption test will bring 
- that is a much better real-life-like example than a simple speed test.


as a follow-up : someone whispered in my ear (thanks, André ;) ) that 
one should use the -elapsed option for this, so here are new results:


*with* cryptodev:

./openssl speed -evp aes-128-cbc -elapsed
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 2825786 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 2716822 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 2369723 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 1536054 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 369984 aes-128-cbc's in 3.00s
[...]
aes-128-cbc  15,070.86k    57,958.87k   202,216.36k 524,306.43k  
1,010,302.98k


*without* cryptodev:

$ openssl speed -evp aes-128-cbc -elapsed
You have chosen to measure el

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

[Jan Just Keijser]

Hi Tony,

On 02/12/20 15:22, Tony He wrote:

Hi Jan,

Welcome to join the discussion.

>the second set of numbers doesn't make sense, and a much better test 
is to do an actual encryption test
I don't compile cryptodev kernel module for my PC and can not 
reproduce this issue for now.  You don't understand  the reason why 
the performance is much worse with cryptodev module for *big* blocks, 
right?
If yes, I guess the reason maybe kernel assign the work to multi cores 
while OpenSSL uses one core. Would you share the output of command 
"mpstat -P ALL 2"?



sure, while using the cryptodev I see this:

15:28:36 CPU    %usr   %nice    %sys %iowait    %irq   %soft %steal  
%guest  %gnice   %idle
15:28:38 all    1.87    0.00   23.19    0.12    0.00    0.00 0.00    
0.00    0.00   74.81
15:28:38   0    0.00    0.00    0.00    0.50    0.00    0.00 0.00    
0.00    0.00   99.50
15:28:38   1    7.00    0.00   93.00    0.00    0.00    0.00 0.00    
0.00    0.00    0.00
15:28:38   2    0.00    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00  100.00
15:28:38   3    0.00    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00  100.00


15:28:38 CPU    %usr   %nice    %sys %iowait    %irq   %soft %steal  
%guest  %gnice   %idle
15:28:40 all    0.75    0.00   24.19    0.00    0.00    0.00 0.00    
0.00    0.00   75.06
15:28:40   0    0.00    0.00    0.00    0.50    0.00    0.00 0.00    
0.00    0.00   99.50
15:28:40   1    3.50    0.00   96.50    0.00    0.00    0.00 0.00    
0.00    0.00    0.00
15:28:40   2    0.00    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00  100.00
15:28:40   3    0.00    0.00    0.00    0.00    0.00    0.00 0.00    
0.00    0.00  100.00


on a 4 core box; this means that 1 core is used 100% (which is what I 
expected).



I suspect the main reason the cryptodev results on my i5-6800 go off the 
rails is due to this:

(look at the "Doing aes-128-cbc lines")

$ ./openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 2835368 aes-128-cbc's in 1.14s
Doing aes-128-cbc for 3s on 64 size blocks: 2720745 aes-128-cbc's in 1.01s
Doing aes-128-cbc for 3s on 256 size blocks: 2377830 aes-128-cbc's in 
*0.74s*
Doing aes-128-cbc for 3s on 1024 size blocks: 1538693 aes-128-cbc's in 
*0.40s*
Doing aes-128-cbc for 3s on 8192 size blocks: 370202 aes-128-cbc's in 
*0.11s*

OpenSSL 1.0.2m  2 Nov 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) 
idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM 
-DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes    256 bytes   1024 bytes 8192 bytes
aes-128-cbc  39794.64k   172403.64k   822600.65k  3939054.08k 
27569952.58k



The timing for how quickly the results are returned are way off and 
probably just wrong. The Openssl speed test is supposed to run for 3 
seconds. The actual results returned for 8192 byte blocks is


Doing aes-128-cbc for 3s on 8192 size blocks: 370202 aes-128-cbc's in 
*0.11s*


whereas without cryptodev I see

Doing aes-128-cbc for 3s on 8192 size blocks: 457255 aes-128-cbc's in 
*3.00s*


So you can see that without cryptodev the i5-6800 actually says it's 
doing more blocks (457,255 vs 370,202) but with cryptodev it is doing it 
in WAY less time.  This leads me to believe the openssl speed code when 
using cryptodev just "goes wrong".
It will be very interesting to see what the encryption test will bring - 
that is a much better real-life-like example than a simple speed test.


HTH,

JJK


>My advice is to rerun your tests *without* the cryptodev module and 
then decide wheter you really need CBC+CCM hmacs.
Yes, I confirm that without the cryptodev the performance is very bad 
for my device. I don't have that device in my hand right now. But I 
saved one aes-256-cbc result in my web notebook as below:


type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 19626.95k 24289.71k 25054.46k 25347.75k 25337.86k
Please note, there are two modes to accelerate encryption/decryption.
1. HW instructions like intel x86 CPU.
2. Using a crypto engine.
When your device is 2 and its CPU is not powerful, normally with 
cryptodev speed is much faster at least for big blocks. Maybe for 
small blocks it's slower because
it needs the time to push the work to kernel and then HW engine and 
the time spent is may longer than the time costed by OpenSSL direc

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

[Jan Just Keijser]

hi Tony,

On 01/12/20 02:50, Tony He wrote:

Hi Arne,

openssl speed -evp aes-128-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 
20035.60k 123261.54k 267081.60k 1094764.09k 9181370.18k

openssl speed -evp aes-128-gcm
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm 
18738.76k 19284.91k 19524.44k 19606.87k 19685.46k

openssl speed -evp aes-128-ccm
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-ccm 
53859.07k 215581.12k 862070.02k 3460786.43k 27566347.61k

openssl speed -evp sha1
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha1 3108.57k 
12177.79k 57325.18k 181610.34k 1207364.27k

openssl speed -evp chacha20-poly1305
chacha20-poly1305 is an unknown cipher or digest
Using old openssl, so chacha20-poly1305 is not supported.


these numbers look suspiciously like you're using the linux cryptodev 
module. Openssl speed results for the linux cryptodev module are totally 
unreliable and I'd even go so far as to say that the *only* numbers I 
trust in the output above are for aes-128-gcm


For example, if I do the same on an i5-6800 I get *without* the 
cryptodev module:

  $ openssl speed -evp aes-128-cbc
  aes-128-cbc    1,104,599.38k  1,208,651.07k  1,231,766.70k 
1,237,545.64k  1,248,793.94k


and with the module I get
  aes-128-cbc  45,087.41k   127,822.72k   581,517.17k 2,256,593.19k 
27,583,804.51k


the second set of numbers doesn't make sense, and a much better test is 
to do an actual encryption test, e.g.


*without* the module
cat BIGFILE | openssl aes-256-cbc -e -pass  pass:thisisabadpassword |  
pv > /dev/null

2.93GB 0:00:05 [ 549MB/s] [ <=> ]

('pv' aka 'pipeview' is a handy tool to measure the throughput of a UNIX 
pipe)


and with the module:
cat BIGFILE | ./openssl aes-256-cbc -e -pass pass:thisisabadpassword 
-engine cryptodev|  pv > /dev/null

engine "cryptodev" set.
2.93GB 0:00:07 [ 426MB/s] [  <=>

so you see that using the cryptodev module actually slows things down - 
which is to be expected, as the application needs to do more work using 
the cryptodev module.


My advice is to rerun your tests *without* the cryptodev module and then 
decide wheter you really need CBC+CCM hmacs.


HTH,

JJK


Arne Schwabe mailto:a...@rfc2549.org>> 
于2020年11月26日周四 下午6:40写道：


Am 26.11.20 um 10:41 schrieb Tony He:
> Hi Arne,
>
>>Since the original thread was not on the mailing list I am
missing your
>>goal but if your crypto acelator already works with OpenSSL, then it
>>will also work with the "normal" OpenVPN
>
> Yes, it wokrs with "normal" OpenVPN(OpenVPN2), but according to
the test
> result, it's still not fast(about 60Mbps).
> The bottleneck is not encryption operation any more. It comes
from the
> switch of user space and kernel space in the OpenVPN2,
> which makes the poor CPU of  embedded device very busy. That's
why we
> need OpenVPN3 running in the kernel space.


What numbers are we are talking in crypto speed? Could you provide
from
your "poor" device:


openssl speed -evp aes-128-cbc
openssl speed -evp aes-128-gcm
openssl speed -evp aes-128-ccm
openssl speed -evp sha1
openssl speed -evp chacha20-poly1305

I want to what difference/gain in terms of raw crypto speed we are
talking here.

Arne






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


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

[Openvpn-devel] [PATCH] [V5] Added support for DHCP option 119 (dns search suffix, list) for Windows. As of Windows 10 1809 Windows finally supports this so it, makes sense to add support to OpenVPN a

[Jan Just Keijser]

Hi,

On 11/07/20 12:44, Gert Doering wrote:

On Fri, Jul 10, 2020 at 06:42:18PM +0200, Jan Just Keijser wrote:

On 08/07/20 10:24, Gert Doering wrote:

Can I have a v4, please? :-)

V4:

Okay, here we go...
thanks for the review, I incorporated your suggestions and comments 
almost verbatim ;)

See attached V5.

cheers,

JJK




Generally speaking, it works now :-)

In the "ipconfig /all" output, I can now see a long list of DNS suffixes.

Together with a DNS search list on the LAN *and* block-outside-dns, this
seems to have interesting effects on Win10 - namely, it tries all the
search domains it has (on all interfaces), but it will try the "LAN"
search domains only via the "LAN" nameservers - and these are blocked,
so there might be interesting side effects if both are used togehter -
*or* it might be a way to get Win10 DNS to behave better even without
block-outside-DNS (by configuring a search domain on the TAP side).


Codewise, a few remarks...



@@ -1145,6 +1146,19 @@ parse_hash_fingerprint(const char *str, int nbytes, int 
msglevel, struct gc_aren
  #ifndef ENABLE_SMALL
  
  static void

+show_dhcp_option_list(const char *name, const char * const*array, int len)
+{
+int i;
+for (i = 0; i < len; ++i)
+{
+msg(D_SHOW_PARMS, "  %s[%d] = %s",
+name,
+i,
+array[i] );
+}
+}

This is not "forbidden" by the style guide, but I think a more compact
form would increase readability - the old openvpn style of having
individual function calls spread over 10+ lines because each parameter
is getting its own line is not really something we do anymore.  So:


+msg(D_SHOW_PARMS, "  %s[%d] = %s", name, i, array[i] );

... which is well below the 80 character limit and which I find more
readable, tbh.



+/*
+ * RFC3397 states that multiple searchdomains are encoded as follows:
+ *  - at start the length of the entire option is given
+ *  - each subdomain is preceded by its length
+ *  - each searchdomain is separated by a NUL character
+ * e.g. if you want "openvpn.net" and "duckduckgo.com" then you end up with
+ *  0x13  0x7 openvpn 0x3 net 0x00 0x0A duckduckgo 0x3 com 0x00

While at it, 0x1D :-)


+ */
+static void
+write_dhcp_search_str(struct buffer *buf, const int type, const char * const 
*str_array,
+  int array_len, bool *error)
+{
+char tmp_buf[256];
+int  i;
+int  len = 0;
+
+for (i=0; i < array_len; i++)
+{
+const char  *ptr = str_array[i], *dotptr = str_array[i];
+int  j, k;
+
+msg(M_INFO, "Processing '%s'", ptr);

This line should not stay as it is - if you see it in the log, it's
mostly unclear "it's processing 'domain' - what for?", and M_INFO is
too high for unspecific info.

Most other DHCP activities do not log anything (unless error), so for
consistency I would just remove it.  But if we keep it, it needs to
be more clear, like


+msg(D_DHCP_OPT, "dhcp search domain '%s'", ptr);

or something like that.



+if (strlen(ptr) + len + 1 > sizeof(tmp_buf))
+{
+*error = true;
+msg(M_WARN, "write_dhcp_search_str: temp buffer overflow building DHCP 
options");
+return;
+}
+/* Loop over all subdomains separated by a dot and replace the dot
+   with the length of the subdomain */
+while ((dotptr = strchr(ptr, '.')) != NULL)
+{
+j = dotptr - ptr;
+tmp_buf[len++] = j;
+for (k=0; k < j; k++) tmp_buf[len++] = ptr[k];

Side note: this violate coding style - for(), as if(), mandates brackets.


+for (k=0; k < j; k++)

{
   tmp_buf[len++] = ptr[k];
}


+ptr = dotptr + 1;
+}
+
+/* Now do the remainder after the last dot */
+j = strlen(ptr);
+tmp_buf[len++] = j;
+for (k=0; k < j; k++) tmp_buf[len++] = ptr[k];

same here.


+
+/* And close off with an extra NUL char */
+tmp_buf[len++] = 0;
+}


With these required brackets, the nested loops get long - and I do not
find them overly elegant anyway (one could do a memcpy(), which would
make more clear what is done, but it's still double-looping).

For this, I had the idea to code it as follows (mentioned yesterday, but
now actually written down) - single pass, no nested loops:

 /* Loop over all subdomains separated by a dot and replace the dot
with the length of the subdomain */

 /* label_length_pos points to the byte to be replaced by the length
  * of the following domain label */
 int label_length_pos = len++;

 while(true)
 {
 if (*ptr == '.' || *ptr == '\0' )
{
 

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi all,


On 08-Jul-20 10:24, Gert Doering wrote:

On Tue, Jul 07, 2020 at 06:14:25PM +0200, Jan Just Keijser wrote:

This one works(!), so generally, Win10 accepts this DHCP option - but
it seems to want "all domains in one".

Can you send a v3?


not sure if all went well , but here's V3.

Unfortunately not, that one seems to be based on your V1 patch, so
we have "remove 'SEARCH', add 'DOMAIN-SEARCH'" hunks...


diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index e59b22b..85f1d8a 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -726,7 +726,7 @@ static const char usage_message[] =
  "which allow multiple addresses,\n"
  "--dhcp-option must be repeated.\n"
  "DOMAIN name : Set DNS suffix\n"
-"SEARCH name : Set DNS domain search list\n"
+"DOMAIN-SEARCH entry : Add entry to DNS domain search 
list\n"

This is ok for me to have a look, but to actually merge I need something
that applies "as it is" on top of master...


diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index eed9ae6..60a149c 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5567,46 +5567,70 @@ write_dhcp_str(struct buffer *buf, const int type, 
const char *str, bool *error)
  buf_write(buf, str, len);
  }
  
+/*

+ * RFC3397 states that multiple searchdomains are encoded as follows:
+ *  - at start the length of the entire option is given
+ *  - each subdomain is preceded by its length
+ *  - each searchdomain is separated by a NUL character
+ * e.g. if you want "openvpn.net" and "duckduckgo.com" then you end up with
+ *  0x13  0x7 openvpn 0x3 net 0x00 0x0A duckduckgo 0x3 com 0x00
+ */

Richard commented on IRC that the "0x13" does not seem to be right here
- adding up all of it (1+7+1+3+1+1+10+1+3+1 = 29).  Can you double-check?

It's just a comment, but if that is wrong, it's not helpful in trying to
understand the code.


just submitted patch v4 but forgot to fix that:   richard is right 29 
decimal is  0x1D -  or just 29, I guess  - not 0x13


Want a v5 for that :P ?

cheers,

JJK



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

[Openvpn-devel] [PATCH] [V4] Added support for DHCP option 119 (dns search suffix, list) for Windows. As of Windows 10 1809 Windows finally supports this so it, makes sense to add support to OpenVPN a

[Jan Just Keijser]

On 08/07/20 10:24, Gert Doering wrote:

Can I have a v4, please? :-)


V4:


>From fe0592df3235f3eb9bc9820586651ba8fc8bade0 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser 
Date: Fri, 10 Jul 2020 18:40:43 +0200
Subject: [PATCH] Added support for DHCP option 119 (dns search suffix list)
 for Windows. As of Windows 10 1809 Windows finally supports this so it makes
 sense to add support to OpenVPN as well.

Signed-off-by: Jan Just Keijser 
---
 src/openvpn/options.c | 27 +++
 src/openvpn/tun.c | 74 +++
 src/openvpn/tun.h |  6 +
 3 files changed, 107 insertions(+)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index b93fd4f..ff3a116 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -732,6 +732,7 @@ static const char usage_message[] =
 "DNS addr: Set domain name server address(es) (IPv4 and IPv6)\n"
 "NTP : Set NTP server address(es)\n"
 "NBDD: Set NBDD server address(es)\n"
+"DOMAIN-SEARCH entry : Add entry to DNS domain search list\n"
 "WINS addr   : Set WINS server address(es)\n"
 "NBT type: Set NetBIOS over TCP/IP Node type\n"
 "  1: B, 2: P, 4: M, 8: H\n"
@@ -1145,6 +1146,19 @@ parse_hash_fingerprint(const char *str, int nbytes, int msglevel, struct gc_aren
 #ifndef ENABLE_SMALL
 
 static void
+show_dhcp_option_list(const char *name, const char * const*array, int len)
+{
+int i;
+for (i = 0; i < len; ++i)
+{
+msg(D_SHOW_PARMS, "  %s[%d] = %s",
+name,
+i,
+array[i] );
+}
+}
+
+static void
 show_dhcp_option_addrs(const char *name, const in_addr_t *array, int len)
 {
 struct gc_arena gc = gc_new();
@@ -1179,6 +1193,7 @@ show_tuntap_options(const struct tuntap_options *o)
 show_dhcp_option_addrs("WINS", o->wins, o->wins_len);
 show_dhcp_option_addrs("NTP", o->ntp, o->ntp_len);
 show_dhcp_option_addrs("NBDD", o->nbdd, o->nbdd_len);
+show_dhcp_option_list("DOMAIN-SEARCH", o->domain_search_list, o->domain_search_list_len);
 }
 
 #endif /* ifndef ENABLE_SMALL */
@@ -7460,6 +7475,18 @@ add_option(struct options *options,
 {
 dhcp_option_address_parse("NBDD", p[2], o->nbdd, &o->nbdd_len, msglevel);
 }
+else if (streq(p[1], "DOMAIN-SEARCH") && p[2])
+{
+if (o->domain_search_list_len < N_SEARCH_LIST_LEN)
+{
+o->domain_search_list[o->domain_search_list_len++] = p[2];
+}
+else
+{
+msg(msglevel, "--dhcp-option %s: maximum of %d search entries can be specified",
+p[1], N_SEARCH_LIST_LEN);
+}
+}
 else if (streq(p[1], "DISABLE-NBT") && !p[2])
 {
 o->disable_nbt = 1;
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 2a2df27..75d5b04 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5673,6 +5673,72 @@ write_dhcp_str(struct buffer *buf, const int type, const char *str, bool *error)
 buf_write(buf, str, len);
 }
 
+/*
+ * RFC3397 states that multiple searchdomains are encoded as follows:
+ *  - at start the length of the entire option is given
+ *  - each subdomain is preceded by its length
+ *  - each searchdomain is separated by a NUL character
+ * e.g. if you want "openvpn.net" and "duckduckgo.com" then you end up with
+ *  0x13  0x7 openvpn 0x3 net 0x00 0x0A duckduckgo 0x3 com 0x00
+ */
+static void
+write_dhcp_search_str(struct buffer *buf, const int type, const char * const *str_array,
+  int array_len, bool *error)
+{
+char tmp_buf[256];
+int  i;
+int  len = 0;
+
+for (i=0; i < array_len; i++)
+{
+const char  *ptr = str_array[i], *dotptr = str_array[i];
+int  j, k;
+
+msg(M_INFO, "Processing '%s'", ptr);
+
+if (strlen(ptr) + len + 1 > sizeof(tmp_buf))
+{
+*error = true;
+msg(M_WARN, "write_dhcp_search_str: temp buffer overflow building DHCP options");
+return;
+}
+/* Loop over all subdomains separated by a dot and replace the dot
+   with the length of the subdomain */
+while ((dotptr = strchr(ptr, '.')) != NULL)
+{   
+j = dotptr - ptr;
+tmp_buf[len++] = j;
+for (k=0; k < j; k++) tmp_buf[len++] = ptr[k];
+ptr = dotptr + 1;
+}   
+
+/* Now do the remainder after the l

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi,

On 06/07/20 18:15, Gert Doering wrote:

Hi,

On Tue, Jun 30, 2020 at 04:15:58PM +0200, Jan Just Keijser wrote:

On 30/06/20 16:11, Gert Doering wrote:

On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:

@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const 
struct tuntap_options *o)
   write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, &error);
   write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, &error);
   
+for (int i=0; i < o->domain_search_list_len; i++)

+{
+write_dhcp_search_str(buf, 119, o->domain_search_list[i], &error);
+}

I assume that this won't work.  In the DHCP answer, it must be a single
option with the concatenated list, not multiple answers with a single
domain name each.

see https://tools.ietf.org/html/rfc3397

"

 In the above diagram, Searchstring is a string specifying the
 searchlist.  If the length of the searchlist exceeds the maximum
 permissible within a single option (255 octets), then multiple
 options MAY be used, as described in "Encoding Long Options in the
 Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396 
<https://tools.ietf.org/html/rfc3396>].

"
so you MAY use this option multiple times - and wireshark groks it fine. I 
don't have a Windows 10
client to test it against, however, so I am hoping that someone (Selva?) can do 
that for me.

I did test, and my initial suspicion was correct - Windows accepts the
option, but only one of them.

I am pushing

   dhcp-option DOMAIN-SEARCH v6.de,dhcp-option DOMAIN-SEARCH 
leo.org,dhcp-option DOMAIN-SEARCH ov.greenie.net,dhcp-option DOMAIN-SEARCH 
nekosoft.de

(because these are domains that have more interesting hostnames in than
just "www" and "mail", so I can see if "v4only.v6.de" is found, or
"dict.leo.org")

and "ipconfig /all" only shows the "nekosoft.de" one.

This one works(!), so generally, Win10 accepts this DHCP option - but
it seems to want "all domains in one".


Can you send a v3?


not sure if all went well , but here's V3.

cheers,

JJK

>From 2a7f199252ddaf1bccf1eb399d26adc0a5aca137 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser 
Date: Tue, 7 Jul 2020 18:10:15 +0200
Subject: [PATCH] [V3] Added support for DHCP option 119 (dns search suffix
 list) for Windows. As of Windows 10 1809 Windows finally supports this so it
 makes sense to add support to OpenVPN as well.

Signed-off-by: Jan Just Keijser 
---
 src/openvpn/options.c |  34 ++---
 src/openvpn/tun.c | 101 --
 src/openvpn/tun.h |   9 +++--
 3 files changed, 90 insertions(+), 54 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index e59b22b..85f1d8a 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -726,7 +726,7 @@ static const char usage_message[] =
 "which allow multiple addresses,\n"
 "--dhcp-option must be repeated.\n"
 "DOMAIN name : Set DNS suffix\n"
-"SEARCH name : Set DNS domain search list\n"
+"DOMAIN-SEARCH entry : Add entry to DNS domain search list\n"
 "DNS addr: Set domain name server address(es) (IPv4 and IPv6)\n"
 "NTP : Set NTP server address(es)\n"
 "NBDD: Set NBDD server address(es)\n"
@@ -1150,6 +1150,20 @@ parse_hash_fingerprint(const char *str, int nbytes, int msglevel, struct gc_aren
 #ifndef ENABLE_SMALL
 
 static void
+show_dhcp_option_list(const char *name, const char * const*array, int len)
+{
+int i;
+for (i = 0; i < len; ++i)
+{
+msg(D_SHOW_PARMS, "  %s[%d] = %s",
+name,
+i,
+array[i] );
+}
+}
+
+
+static void
 show_dhcp_option_addrs(const char *name, const in_addr_t *array, int len)
 {
 struct gc_arena gc = gc_new();
@@ -1176,7 +1190,6 @@ show_tuntap_options(const struct tuntap_options *o)
 SHOW_BOOL(dhcp_renew);
 SHOW_BOOL(dhcp_pre_release);
 SHOW_STR(domain);
-SHOW_STR(domain_search_list);
 SHOW_STR(netbios_scope);
 SHOW_INT(netbios_node_type);
 SHOW_BOOL(disable_nbt);
@@ -1185,6 +1198,7 @@ show_tuntap_options(const struct tuntap_options *o)
 show_dhcp_option_addrs("WINS", o->wins, o->wins_len);
 show_dhcp_option_addrs("NTP", o->ntp, o->ntp_len);
 show_dhcp_option_addrs("NBDD", o->nbdd, o->nbdd_len);
+show_dhcp_option_list("DOMAIN-SEARCH", o->domain_search_list, o->domain_search_list_len);
 }
 
 #endif /* ifndef ENABLE_SMALL */
@@ -7329,10 +7343,6 @@ add_option(struct options *options,
  

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi,

On 03/07/20 11:18, Arne Schwabe wrote:

The main purpose of that RFC is to ensure we handle DNS and
--dhcp-options
consistently across all OpenVPN implementations we care about, and
that we
document this properly.


I see one as an implementation issue (can we specify a particular DHCP
option more than once) and one as an OpenVPN protocol issue.
I fully agree that it's time to think about and overhaul the DNS
settings for OpenVPN but I also believe that further abusing the option
'dhcp-option' is not the best way forward.  The option 'dhcp-option'
only really applies to the Windows tap-win adapter as that is the only
adapter where you can use DHCP to add/change settings.

This not even remotely true anymore. Basically all platforms will accept
the dhcp-options for modifying the DNS settings.


AFAIK even the
new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-'
is moot.

Yes. Of course we can specify nicer sounding names for these options and
that also break all kind of backwards compatibility for little gain or
we document that the dhcp- prefix in these options is for historic reasons.



I should have worded it more carefully, but Jonathan beat me to it:

On 03/07/20 11:30, Jonathan K. Bullard wrote:
> If you mean the term 'dhcp' should not be used in the name of the
> option, I agree. Perhaps something like "interface-option" would be
> better.
>
> But the _option_ isn't only for Windows tap-win adaptor. The option's
> arguments are passed to scripts via $foreign_option_* environment
> variables (on macOS, at least, and I think on most or all platforms).
> And the Tunnelblick scripts use them to modify network settings, sort
> of as if they came from DHCP, but not actually using DHCP.


I fully understand that most of those options are supported (or should I 
say, '(ab)used' ) by the other platforms but what I meant was that the 
name 'dhcp-option' is totally misleading as it has nothing to do with 
DHCP *except* when using the tap-win adapter.


Thus, if we want an overhaul of this, let's do it right and change the 
name of this option.


JJK


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

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi,

On 02/07/20 23:04, David Sommerseth wrote:

On 30/06/2020 16:15, Jan Just Keijser wrote:

hi,

On 30/06/20 16:11, Gert Doering wrote:

Hi,

On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:

@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const 
struct tuntap_options *o)
  write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, &error);
  write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, &error);
  
+for (int i=0; i < o->domain_search_list_len; i++)

+{
+write_dhcp_search_str(buf, 119, o->domain_search_list[i], &error);
+}

I assume that this won't work.  In the DHCP answer, it must be a single
option with the concatenated list, not multiple answers with a single
domain name each.

gert


see https://tools.ietf.org/html/rfc3397

"

In the above diagram, Searchstring is a string specifying the
searchlist.  If the length of the searchlist exceeds the maximum
permissible within a single option (255 octets), then multiple
options MAY be used, as described in "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396 
<https://tools.ietf.org/html/rfc3396>].

"


so you MAY use this option multiple times - and wireshark groks it fine. I 
don't have a Windows 10
client to test it against, however, so I am hoping that someone (Selva?) can do 
that for me.


Hi,

Can we please see this discussion also in context of this mail thread, which
tries to look a broader at this challenge?

Message-Id: 
URL:
<https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20101.html>

One change in that RFC since last time is that we will move IV_PROTO to be
only about the OpenVPN wire protocol (features/settings only affecting
protocol for the communication between the OpenVPN end-points themselves).
The DNS settings and more related to host configuration and similar will be
moved into an IV_FEAT field.  Except of that, nothing else has changed from
the initial mail.

The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
consistently across all OpenVPN implementations we care about, and that we
document this properly.



I see one as an implementation issue (can we specify a particular DHCP 
option more than once) and one as an OpenVPN protocol issue.
I fully agree that it's time to think about and overhaul the DNS 
settings for OpenVPN but I also believe that further abusing the option 
'dhcp-option' is not the best way forward.  The option 'dhcp-option' 
only really applies to the Windows tap-win adapter as that is the only 
adapter where you can use DHCP to add/change settings. AFAIK even the 
new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-' 
is moot.


Thus, moving forward, I'd be more in favor of overhauling this 
*completely* and review all 'dhcp-option' flags to see how we can

a) specify then more logically and more neutrally
b) implement these features for each of the different platforms:

Windows+tap-win: use DHCP
Windows+win-tun:   use netsh ?
Linux:  use systemd? use scripts
BSD: scripts? systemd?
MacOS:   just copy what Jonathan is using ;)


JM2CW,

JJK



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

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

hi,

On 30/06/20 16:11, Gert Doering wrote:

Hi,

On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:

@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const 
struct tuntap_options *o)
  write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, &error);
  write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, &error);
  
+for (int i=0; i < o->domain_search_list_len; i++)

+{
+write_dhcp_search_str(buf, 119, o->domain_search_list[i], &error);
+}

I assume that this won't work.  In the DHCP answer, it must be a single
option with the concatenated list, not multiple answers with a single
domain name each.

gert


see https://tools.ietf.org/html/rfc3397

"

   In the above diagram, Searchstring is a string specifying the
   searchlist.  If the length of the searchlist exceeds the maximum
   permissible within a single option (255 octets), then multiple
   options MAY be used, as described in "Encoding Long Options in the
   Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396 
<https://tools.ietf.org/html/rfc3396>].

"


so you MAY use this option multiple times - and wireshark groks it fine. I 
don't have a Windows 10
client to test it against, however, so I am hoping that someone (Selva?) can do 
that for me.

cheers,

JJK

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

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi,

On 24/06/20 12:28, Gert Doering wrote:

Hi,

On Tue, Jun 23, 2020 at 03:53:52PM -0400, Selva Nair wrote:

So what option do we want?

--dhcp-option SEARCH
--dhcp-option DOMAIN-SEARCH
--dhcp-option SEARCH-DOMAIN

RFC 3397 calls it "Domain Search" so it has to be DOMAIN-SEARCH, in my
view.  Platform scripts accepting other forms in foreign_option is up
to them. We don't have to officially support that.

I like that argument.

(I do not care too much which string it is, in the end, but if we have
an RFC which has a name for it, and that name maps directly to one of
the candidates, this is a strong argument :-) )


On the "shall it be a single occurrance with multiple domains in it" or
"shall it be multiple occurances that are concatenated into a single DHCP
option which then has multiple domains in it", I do not have a truly
strong opinion.  So I'd go with "what Tunnelblick has", which is
"multiple occurances, a single string each".

He who goes first wins :-)

here's V2:
-  allow a user to specify
  dhcp-option DOMAIN-SEARCH
 multiple times
- only a single FQDN per entry

cheers,

JJK

>From a82036c3f81d31af223a574f75de48797ba76698 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser 
Date: Tue, 30 Jun 2020 15:52:58 +0200
Subject: [PATCH] Added support for DHCP option 119 (dns search suffix list)
 for Windows. As of Windows 10 1809 Windows finally supports this so it makes
 sense to add support to OpenVPN as well.

Signed-off-by: Jan Just Keijser 
---
 src/openvpn/options.c | 13 +
 src/openvpn/tun.c | 48 
 src/openvpn/tun.h |  6 ++
 3 files changed, 67 insertions(+)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 2073b4a..376b8e7 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -729,6 +729,7 @@ static const char usage_message[] =
 "which allow multiple addresses,\n"
 "--dhcp-option must be repeated.\n"
 "DOMAIN name : Set DNS suffix\n"
+"DOMAIN-SEARCH entry : Add entry to DNS domain search list\n"
 "DNS addr: Set domain name server address(es) (IPv4 and IPv6)\n"
 "NTP : Set NTP server address(es)\n"
 "NBDD: Set NBDD server address(es)\n"
@@ -7460,6 +7461,18 @@ add_option(struct options *options,
 {
 dhcp_option_address_parse("NBDD", p[2], o->nbdd, &o->nbdd_len, msglevel);
 }
+else if (streq(p[1], "DOMAIN-SEARCH") && p[2])
+{
+if (o->domain_search_list_len < N_SEARCH_LIST_LEN)
+{
+o->domain_search_list[o->domain_search_list_len++] = p[2];
+}
+else
+{
+msg(msglevel, "--dhcp-option %s: maximum of %d search entries can be specified",
+p[1], N_SEARCH_LIST_LEN);
+}
+}
 else if (streq(p[1], "DISABLE-NBT") && !p[2])
 {
 o->disable_nbt = 1;
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 5567c44..843c6b2 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5673,6 +5673,49 @@ write_dhcp_str(struct buffer *buf, const int type, const char *str, bool *error)
 buf_write(buf, str, len);
 }
 
+
+static void
+write_dhcp_search_str(struct buffer *buf, const int type, const char *str, bool *error)
+{
+const char  *ptr = str, *dotptr = str;
+int  i, j;
+
+const int len = strlen(str) + 2;
+if (!buf_safe(buf, 2 + len))
+{
+*error = true;
+msg(M_WARN, "write_dhcp_str: buffer overflow building DHCP options");
+return;
+}
+if (len < 1 || len > 255)
+{
+*error = true;
+msg(M_WARN, "write_dhcp_search_str: string '%s' must be > 0 bytes and <= 255 bytes", str);
+return;
+}
+
+buf_write_u8(buf, type);
+buf_write_u8(buf, len);
+
+/* Loop over all subdomains separated by a dot and replace the dot
+   with the length of the subdomain */
+while ((dotptr = strchr(ptr, '.')) != NULL)
+{
+i = dotptr - ptr;
+buf_write_u8(buf, i);
+for (j=0; j< i; j++) buf_write_u8(buf, ptr[j]);
+ptr = dotptr + 1;
+}
+
+/* Now do the remainder after the last dot */
+i = strlen(ptr);
+buf_write_u8(buf, i);
+for (j=0; j< i; j++) buf_write_u8(buf, ptr[j]);
+
+/* And close off with an extra NUL char */
+buf_write_u8(buf, 0);
+}
+
 static bool
 build_dhcp_options_string(struct buffer *buf, const struct tuntap_options *o)
 {
@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const struct tu

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi,

On 21/06/20 17:14, Selva Nair wrote:

On Sun, Jun 21, 2020 at 7:14 AM Gert Doering  wrote:


going through OpenVPN threads that went stale - I think this is
actually a nice addition (read: other people have already asked
me if this can be done).

On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote:

So, for what it's worth, I've dusted off the patch again and rebased it
to the current openvpn master tree. See attached. Note that I did only
rudimentary testing, as I don't use Windows 10 a lot and I was testing
using a mingw cross-compile only. In wireshark I *do* see that the
correct DHCP offer is sent to the tap-win adapter.

Also note that I implemented multiple search domains by separating them
using semi-colons, e.g.

 --dhcp-option SEARCH example.com;example.org;example.nl;example.de

etc as that was easier to implement

The patch looks okay-ish on quick reading.

Feature wise yes, but some improvements needed..

I do not like that option format

"example.com; example.org" with quotes will parse right and fail later
on because of the space, for example. And, we support multiple
statements of dhcp options like DNS, so this is counter-intuitive.
It's only a little more work to support a more forgiving format.
actually, the patch will be a bit more invasive if we add that; parsing 
DNS/WINS etc is already there and it parses an option into an IP/IPv6 
address. changing the dns-search option to an array of strings will 
require more work. I did look into that initially but decided not to do 
it as the patch would be lengthier.


Note that "multiple domain" option is also not support, really. The 
domain is stored in the tuntap_options struct as


 90 const char *domain;  /* DOMAIN (15) */

so it's "last option wins"  ; the fact that some platforms abuse this 
option to actually set multiple search domains is a different matter.



Also note that I did not fully implement the RFC3397 encoding of the
search list, as that requires one to merge domain names that occur more
than once - that would have made the code far more complicated.

Indeed.  I haven't looked at what other DHCP implementations do, but
"correct" encoding definitely sounds like quite a bit of extra code just
to save a few bytes on the wire - might come handy if you have many
subdomains of a long internal DNS domain, though, but this can be
added "if needed".

Same as my thoughts, the encoding part could be kept simple as in here
and possibly improved later. But option format is hard to change or
deprecate.



More interesting is the question "which option to use" - it should
be synchronized between openvpn platform handlers.  So if systemd-networkd
uses "SEARCH-DOMAIN" it would make sense to use that for windows
as well.

I think we need both --- the current one retained as the connection
specific suffix which would be just one entry and then this search
list. As we allow multiple entries for DOMAIN right now, a user
friendly approach would be to continue doing so but internally treat
all but the first as a part of --dhcp-option DOMAIN-SEARCH. We could
also deprecate the use of multiple entries in the dhcp-option DOMAIN
keyword.


See above: like I said, multiple DOMAIN entries do not seem to be supported.

So what option do we want?

--dhcp-option SEARCH
--dhcp-option DOMAIN-SEARCH
--dhcp-option SEARCH-DOMAIN

all?

JJK





___
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

[Jan Just Keijser]

On 15/05/20 17:40, David Sommerseth wrote:

On 15/05/2020 17:36, David Sommerseth wrote:

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).

Can we settle on a single CR_TEXT vs CRTEXT terminology?  The 3/5 patch used
crtext in the documentation but cr_text in the commit message.


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(+)

diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index e380ca2b..4b405a9b 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -592,6 +592,32 @@ interface to approve client connections.
  CID,KID -- client ID and Key ID.  See documentation for ">CLIENT:"
  notification for more info.
  
+COMMAND -- client-sso-auth  (OpenVPN 2.5 or higher)

+
+
+Instruct OpenVPN server to send AUTH_PENDING and INFO_PRE signal
+a single sign on url to the client.
+
+client-sso-auth {CID} {EXTRA}

I think we should use a different naming for this than 'sso'.  This is not
tied to only SSO (Single Sign-On).  What about:

  - client-extended-auth
  - client-external-auth
  - client-ext-auth
  - client-additional-auth
  - client-xauth

Another alternative popped up in my head, as CR/Challenge-Response is used a
lot in this context  client-cr-auth   but all of them are just
suggestions to avoid the 'sso' reference.


As long as the name is quite generic, I'm fine with most alternatives.  But it
should be very generic.  We have so many alternative auth methods these days:
Yubico OTP [1], TOTP/HOTP, FIDO/U2F, SAML, OAuth, Kerberos/GSSAPI, etc ...

[1] 


+1 on avoiding the 'sso' reference  - this has nothing to do with 
SSO/SAML/OAuth/OpenID etc etc and I think it would be unwise to suggest 
that OpenVPN does something like "that" kind of SSO auth. Before we know 
it users will start asking how they can link their Hotmail, FB or Google 
account to their OpenVPN config


JM2CW,

JJK





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

Re: [Openvpn-devel] [Openvpn-users] new openssl = new OpenVPN release ?

[Jan Just Keijser]

Hi Arne,

On 22/04/20 10:13, Arne Schwabe wrote:

SSL_check_chain() function".

Which we don't, I just grepped through our source tree.

So, unless I misunderstand something about OpenSSL intricacies, I think
we're safe - no new installers needed, and OpenVPN is not in risk.



the advisory applies only to application that use the SSL_check_chain()
function as part of a TLS 1.3 handshake. AFAIK, iIn OpenVPN 2.4 we don't
do anything with TLS 1.3 just yet, so this security advisory does not
apply to OpenVPN. Also note that this bug appears only in OpenSSL 1.1.1
[d-f] , so anything older is fine as well.

Hu? OpenVPN 2.4 supports TLS 1.3 just fine. We have support for it in
tls-version-min and also tls-ciphersuites which is TLS 1.3 specific.


what I meant was that OpenVPN 2.4 does not do any *specific* with any of 
the new features of TLS 1.3, like the new psk callbacks etc. If the 
control session is negotiated using TLS 1.3 then sure, OpenVPN will use 
that, but other that OpenVPN does not make use of any of the new 
features or crypto algorithms that come with OpenSSL 1.1.1 or TLS 1.3 
(chacha20 anyone ;) ? )


cheers,

JJK



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

Re: [Openvpn-devel] [Openvpn-users] new openssl = new OpenVPN release ?

[Jan Just Keijser]

Hi Gert,

On 21/04/20 20:59, Gert Doering wrote:

Hi,

On Tue, Apr 21, 2020 at 08:37:35PM +0200, Gert Doering wrote:

On Tue, Apr 21, 2020 at 02:15:43PM -0400, mike tancsa wrote:

     Will the sec issue with OpenSSL force a new release of OpenVPN ?

https://www.openssl.org/news/secadv/20200421.txt

So, speaking to myself again :-) - I've looked at the advisory, and
it talks about "Server or client applications that call the
SSL_check_chain() function".

Which we don't, I just grepped through our source tree.

So, unless I misunderstand something about OpenSSL intricacies, I think
we're safe - no new installers needed, and OpenVPN is not in risk.


the advisory applies only to application that use the SSL_check_chain() 
function as part of a TLS 1.3 handshake. AFAIK, iIn OpenVPN 2.4 we don't 
do anything with TLS 1.3 just yet, so this security advisory does not 
apply to OpenVPN. Also note that this bug appears only in OpenSSL 1.1.1 
[d-f] , so anything older is fine as well.


cheers,

JJK



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

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi all,

On 05/03/20 13:53, Jan Just Keijser wrote:

Hi,

On 01/03/20 16:29, Selva Nair wrote:

On Sun, Mar 1, 2020 at 2:17 AM Gert Doering  wrote:


On Sun, Mar 01, 2020 at 05:37:15AM +, Leroy Tennison via 
Openvpn-users wrote:
Admittedly, and older server version (2.3) but is there a way to 
specify multiple DNS search suffixes for a Windows (10 if that 
makes a difference) client.  The clients are part of a domain but I 
have no control over them via that avenue.  I've tried multiple 
dhcp-option DOMAiN entries and the last one applies, I don't see 
another dhcp-option such as DOMAIN-SEARCH.  Any options would be 
much appreciated.  Thanks.


OpenVPN never had functionality to set the DHCP SEARCH LIST option
on Windows.

So while you could always specify the option multiple times, it would
only use one of them and put it into the DHCP DOMAIN option.

It's not very much missing code, but someone would have to do it (and
the "core team" is very busy with other aspects right now).

IIRC, windows clients never queried DHCP option 119 (domain search).
It seems that has changed since Windows 10, or has it?


I had to dig through my archives for this one - I found an OpenVPN 
2.0.9  (!) source tree to which I had added rudimentary support for 
DHCP domain search, but that was *before* I found out that Windows did 
not support that...
And yes, according to the comment section of 
https://www.normanbauer.com/2018/04/18/configuring-dhcp-option-119-domain-search-list-on-a-windows-dhcp-server/, 
Windows 10 1809+ finally has support for DHCP domain searches.


So, for what it's worth, I've dusted off the patch again and rebased 
it to the current openvpn master tree. See attached. Note that I did 
only rudimentary testing, as I don't use Windows 10 a lot and I was 
testing using a mingw cross-compile only. In wireshark I *do* see that 
the correct DHCP offer is sent to the tap-win adapter.


Also note that I implemented multiple search domains by separating 
them using semi-colons, e.g.


   --dhcp-option SEARCH example.com;example.org;example.nl;example.de

etc as that was easier to implement
Also note that I did not fully implement the RFC3397 encoding of the 
search list, as that requires one to merge domain names that occur 
more than once - that would have made the code far more complicated.




to follow up on this:   I just found Jonathan's update-systemd-resolved 
thingie (https://github.com/jonathanio/update-systemd-resolved)  where 
he mentions that you can push

  --dhcp-option DOMAIN
multiple times to achieve a similar result - but at best that works on 
anything BUT Windows.

I do see that he lists a non-supported option
  --dhcp-option SEARCH-DOMAIN

instead of my 'SEARCH' ; it will be good to sync up with his script/code 
to ensure a smooth cooperation between platforms - provided, that is, 
that my patch is actually acceptable ;)


cheers,

JJK



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

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jan Just Keijser]

Hi,

On 01/03/20 16:29, Selva Nair wrote:

On Sun, Mar 1, 2020 at 2:17 AM Gert Doering  wrote:


On Sun, Mar 01, 2020 at 05:37:15AM +, Leroy Tennison via Openvpn-users 
wrote:

Admittedly, and older server version (2.3) but is there a way to specify 
multiple DNS search suffixes for a Windows (10 if that makes a difference) 
client.  The clients are part of a domain but I have no control over them via 
that avenue.  I've tried multiple dhcp-option DOMAiN entries and the last one 
applies, I don't see another dhcp-option such as DOMAIN-SEARCH.  Any options 
would be much appreciated.  Thanks.


OpenVPN never had functionality to set the DHCP SEARCH LIST option
on Windows.

So while you could always specify the option multiple times, it would
only use one of them and put it into the DHCP DOMAIN option.

It's not very much missing code, but someone would have to do it (and
the "core team" is very busy with other aspects right now).

IIRC, windows clients never queried DHCP option 119 (domain search).
It seems that has changed since Windows 10, or has it?


I had to dig through my archives for this one - I found an OpenVPN 
2.0.9  (!) source tree to which I had added rudimentary support for DHCP 
domain search, but that was *before* I found out that Windows did not 
support that...
And yes, according to the comment section of 
https://www.normanbauer.com/2018/04/18/configuring-dhcp-option-119-domain-search-list-on-a-windows-dhcp-server/, 
Windows 10 1809+ finally has support for DHCP domain searches.


So, for what it's worth, I've dusted off the patch again and rebased it 
to the current openvpn master tree. See attached. Note that I did only 
rudimentary testing, as I don't use Windows 10 a lot and I was testing 
using a mingw cross-compile only. In wireshark I *do* see that the 
correct DHCP offer is sent to the tap-win adapter.


Also note that I implemented multiple search domains by separating them 
using semi-colons, e.g.


   --dhcp-option SEARCH example.com;example.org;example.nl;example.de

etc as that was easier to implement
Also note that I did not fully implement the RFC3397 encoding of the 
search list, as that requires one to merge domain names that occur more 
than once - that would have made the code far more complicated.



share and enjoy,

JJK

>From a969947cd86292c881f7cc1c704ac992e8f6f0d6 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser 
Date: Thu, 5 Mar 2020 13:41:00 +0100
Subject: [PATCH] Added support for DHCP option 119 (dns search suffix list)
 for Windows. As of Windows 10 1809 Windows finally supports this so it makes
 sense to add support to OpenVPN as well.

---
 src/openvpn/options.c |  6 +
 src/openvpn/tun.c | 62 +++
 src/openvpn/tun.h |  3 +++
 3 files changed, 71 insertions(+)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 6c0e52e..e59b22b 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -726,6 +726,7 @@ static const char usage_message[] =
 "which allow multiple addresses,\n"
 "--dhcp-option must be repeated.\n"
 "DOMAIN name : Set DNS suffix\n"
+"SEARCH name : Set DNS domain search list\n"
 "DNS addr: Set domain name server address(es) (IPv4 and IPv6)\n"
 "NTP : Set NTP server address(es)\n"
 "NBDD: Set NBDD server address(es)\n"
@@ -1175,6 +1176,7 @@ show_tuntap_options(const struct tuntap_options *o)
 SHOW_BOOL(dhcp_renew);
 SHOW_BOOL(dhcp_pre_release);
 SHOW_STR(domain);
+SHOW_STR(domain_search_list);
 SHOW_STR(netbios_scope);
 SHOW_INT(netbios_node_type);
 SHOW_BOOL(disable_nbt);
@@ -7327,6 +7329,10 @@ add_option(struct options *options,
 {
 o->domain = p[2];
 }
+else if (streq(p[1], "SEARCH") && p[2])
+{
+o->domain_search_list = p[2];
+}
 else if (streq(p[1], "NBS") && p[2])
 {
 o->netbios_scope = p[2];
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index aa131b2..eed9ae6 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5567,6 +5567,48 @@ write_dhcp_str(struct buffer *buf, const int type, const char *str, bool *error)
 buf_write(buf, str, len);
 }
 
+static void
+write_dhcp_search_str(struct buffer *buf, const int type, const char *str, bool *error)
+{
+const char  *ptr = str, *dotptr = str;
+int  i, j;
+
+const int len = strlen(str) + 2;
+if (!buf_safe(buf, 2 + len))
+{
+*error = true;
+msg(M_WARN, "write_dhcp_str: buffer overflow building DHCP options");
+return;
+}
+if (len < 1 || len > 255)
+{
+  

Re: [Openvpn-devel] [PATCH v2 1/7] Visual Studio: upgrade project files to VS2019

[Jan Just Keijser]

Last version of openvpn for xp/Vista is 2.3, so dropping support for it in the 
build system is a no brainer to me.

JM2CW,

JJK

 Gert Doering  wrote:

>Hi,
>
>On Thu, Nov 07, 2019 at 07:28:36PM +0100, Lev Stipakov wrote:
>> With VS2019 you cannot build for XP,  you would need to install build tools
>> from VS2017 for that.
>> 
>> On the other hand, we do not build releases with VS, so it should not be an
>> issue.
>
>Not sure right now about 2.4, but for master/2.5, we dropped support for
>XP/Vista long ago.  
>
>So "not being able to build for XP" would not be a problem.
>
>gert
>-- 
>"If was one thing all people took for granted, was conviction that if you 
> feed honest figures into a computer, honest figures come out. Never doubted 
> it myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh Mistress
>
>Gert Doering - Munich, Germany g...@greenie.muc.de
>
>___
>Openvpn-devel mailing list
>Openvpn-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

Re: [Openvpn-devel] Tap-windows6 test installer with PRs #84 and #86

[Jan Just Keijser]

Hi,

On 23/10/19 13:20, Samuli Seppänen wrote:

Il 23/10/19 14:19, Samuli Seppänen ha scritto:

Hi,

Here is a new Windows 10 / Server 2016+ tap-windows6 installer. It is
based on the latest code in "master" plus two currently unmerged PRs:

"Introduce TAP adapter as a virtual device"



"constants.h: make driver not halt on suspend"



I have smoke-tested the installer on Windows Server 2016 and it passes
the signature verification just fine.

We hope to later merge these two PRs and push out a new, official
tap-windows6 release.

Samuli


And the link:




Just to confirm: this new driver fixes the HP Envy "wifi drops when tun 
connects" problem under Windows 10.

Thanks very much for the hard work to trace down and fix this nasty bug!


cheers,

JJK



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

Re: [Openvpn-devel] Wintun performance results

[Jan Just Keijser]

Hi David, *

On 15/05/19 19:32, David Sommerseth wrote:

On 15/05/2019 16:49, Илья Шипицин wrote:

it will most probably get lost in mailing list.
can we add it to https://openvpn.net website ? something like "performance
testing" with full configs provided ?

Good idea, but maybe not the official corp web pages just yet.  But we should
definitely have some wiki pages under https://community.openvpn.net/ related
to how to prepare a good setup for performance testing.


a community wiki page on how to prepar a good setup for performance 
testing sounds like a good plan.
However, if I am not mistaken the version of OpenVPN used in the test 
was a *Windows* build of OpenVPN3 with a wintun patch included. That is 
not open source, is it?  I'd *not* be in favour of writing community 
wiki pages on the non-open source version of OpenVPN.


JM2CW,

JJK



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

Re: [Openvpn-devel] Client reconnect issues

[Jan Just Keijser]

Hi Antonio,

On 26/04/19 16:02, Antonio Quartulli wrote:

Hi,

On 26/04/2019 15:57, Jan Just Keijser wrote:

I'd look into the way session tickets are configured and used in
mbedtls, e.g. read up on
https://tls.mbed.org/discussions/generic/what-is-the-correct-way-to-use-session-tickets


For OpenSSL, OpenVPN uses SSL_OP_NO_TICKET, i.e. no session tickets are
allowed. I don't know the mbedtls code base well enough, but as a start,
I'd make sure that mbedtls is also configured to NOT accept session
tickets.

PUSH messages are exchanged on the control channel *after* the TLS
handshake has completed, therefore I am not sure session tickets can
play any role at that point, no?

fully correct, however, my suspicion is that the mbedtls version does 
not see the reconnect as a new connection on the control channel, 
whereas the openssl version does - that could explain the difference in 
push-logic.
Most likely the openssl version also does not like to push messages if 
it "thinks" it is simply a TLS control channel session resumption.

And at any rate, it can't hurt to rule this one out ;)

JJK



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

Re: [Openvpn-devel] Client reconnect issues

[Jan Just Keijser]

Hi Pieter,

On 26/04/19 15:32, Pieter Hulshoff wrote:

Gert,

Op vr 19 apr. 2019 om 13:38 schreef Pieter Hulshoff 
>:


I've been looking at
https://community.openvpn.net/openvpn/ticket/880 for a while now,
and was wondering if there'd been any answers to this problem yet.
It appears that mbedtls (according to krzee the problem
disappeared when using OpenSSL, but since I use OpenVPN-NL that's
not an option for me) refuses to answer a PUSH request for a
connection it considers to already exist. As a result, a reconnect
(e.g. after a client reboot) will stall until the reconnect timer
exceeds the server's time-out, after which the server closes the
connection, and accepts the following reconnect attempt. Reconnect
from a 2.3.9 client is stalled indefinitely, since the re-connect
seems fixed at 2 seconds.

Using nobind will also solve the issue, since the server will see
it as a new connection, but I'm not sure nobind is a proper
solution for everyone.

Any thoughts on this matter? Is it true that this only happens
with mbedtls, and as such should this issue be taken up with that
community in stead of this one? Any idea on why the server would
refuse a PUSH request for an already existing connection?


You were looking into this matter in 2017. Did you ever figure out 
what the cause of this issue was, and if so how it could be remedied?



I'd look into the way session tickets are configured and used in 
mbedtls, e.g. read up on

https://tls.mbed.org/discussions/generic/what-is-the-correct-way-to-use-session-tickets

For OpenSSL, OpenVPN uses SSL_OP_NO_TICKET, i.e. no session tickets are 
allowed. I don't know the mbedtls code base well enough, but as a start, 
I'd make sure that mbedtls is also configured to NOT accept session tickets.


An easy way to test my hypothesis would be to
- allow session tickets in the OpenSSL version (i.e. modify one line in 
ssl_opensls.c)

- build OpenVPN using OpenSSL
- use this patched OpenVPN binary to connect to your (mbedtls) server to 
see if the problem now also occurs with an openssl-linked version of OpenVPN
If so, then you know it's a session ticket issue. If not, then you can 
(most likely) rule out session tickets as the root cause of the problem.


HTH,

JJK

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

Re: [Openvpn-devel] Issue with smartcard authentication for openvpn

[Jan Just Keijser]

Hi Selva,

On 17/04/19 17:52, Selva Nair wrote:


On Wed, Apr 17, 2019 at 10:50 AM Jan Just Keijser <mailto:janj...@nikhef.nl>> wrote:



On 10/04/19 19:09, Selva Nair wrote:



On Wed, Apr 10, 2019 at 12:59 PM Jan Just Keijser
mailto:janj...@nikhef.nl>> wrote:



snipped...


patching pkcs11-helper does not seem too difficult for this
particular case - but how can we test it? I have access to hw
tokens but I don't know how to trigger the "raw signature" bit.


If both server and client are built with OpenSSL 1.1.1 and TLS
version is >= 1.2, PSS padding will get used and trigger this.
OpenSSL does PSS padding internally and passes the padded data to
the rsa_priv_enc calback for raw signature.

This is based on my tests for our Windows cryptoapi and
management-external-key patches for the same -- never tried this
using pkcs11-helper, but I expect the same behaviour.



The good news: I can reproduce this with
- openvpn 2.4.7
- openssl 1.1.1b
- pkcs11helper 1.25.1
- Safenet etoken
- client+server CentOS 7

The bad news: I don't have a fix yet.


What I has in mind was a very simple patch like the one attached 
(totally untested).
But I guess you tried that already and it doesn't work? Is it because 
the token

does not support raw signature (not all do) or something else?


I had not written a patch when I wrote my earlier email, but your patch 
is exactly what I had in mind; getting it all to compile and run with 
OpenSSL 1.1.1b + OpenVPN 2.4.7 was a bit of a challenge, but I finally 
managed...


and yes, your patch works admirably - I can connect again using TLSv1.3 
+ token.  If I comment out your patch, do a rebuild of 
libpkcs11helper.so then it fails again, proving your patch works.


Can you do a pull request for your pkcs11-helper patch on the 
pkcs11helper github page?  or shall we simply patch pkcs11-helper ourselves?


cheers,

JJK

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

Re: [Openvpn-devel] Issue with smartcard authentication for openvpn

[Jan Just Keijser]

Hi Selva,

On 10/04/19 19:09, Selva Nair wrote:



On Wed, Apr 10, 2019 at 12:59 PM Jan Just Keijser <mailto:janj...@nikhef.nl>> wrote:


On 10/04/19 17:58, Selva Nair wrote:

Hi,

This is more relevant to OpenVPN than OpenSSL, so copying to the
openvpn-devel list.

On Wed, Apr 10, 2019 at 10:11 AM Francois Gelis
mailto:francois.ge...@gmail.com>> wrote:

Hi all,

I have a working openvpn setup with client certificate and
private key stored on my laptop. Then, I have loaded them
into a smartcard (Yubico 5 NFC), and modified accordingly the
openvpn client config. But running the openvpn client now
fails with an error that seems to originate inside openssl.
Here is a verbose openvpn log (only the portion that seems
relevant for this error, but I have the full log if useful):

Sat Apr  6 15:57:20 2019 us=467260 Incoming Ciphertext -> TLS
Sat Apr  6 15:57:20 2019 us=467271 SSL state (connect):
SSLv3/TLS read server hello
Sat Apr  6 15:57:20 2019 us=467468 VERIFY OK: depth=1, CN=FG-CA
Sat Apr  6 15:57:20 2019 us=467598 VERIFY KU OK
Sat Apr  6 15:57:20 2019 us=467609 Validating certificate
extended key usage
Sat Apr  6 15:57:20 2019 us=467615 ++ Certificate has EKU
(str) TLS Web Server Authentication, expects TLS Web Server
Authentication
Sat Apr  6 15:57:20 2019 us=467620 VERIFY EKU OK
Sat Apr  6 15:57:20 2019 us=467625 VERIFY OK: depth=0, CN=tx2
Sat Apr  6 15:57:20 2019 us=467650 SSL state (connect):
SSLv3/TLS read server certificate
Sat Apr  6 15:57:20 2019 us=467735 SSL state (connect):
SSLv3/TLS read server key exchange
Sat Apr  6 15:57:20 2019 us=467763 SSL state (connect):
SSLv3/TLS read server certificate request
Sat Apr  6 15:57:20 2019 us=467771 SSL state (connect):
SSLv3/TLS read server done
Sat Apr  6 15:57:20 2019 us=467845 SSL state (connect):
SSLv3/TLS write client certificate
Sat Apr  6 15:57:20 2019 us=468012 SSL state (connect):
SSLv3/TLS write client key exchange
Sat Apr  6 15:57:20 2019 us=468053 PKCS#11:
__pkcs11h_openssl_rsa_enc entered - flen=256,
from=0x559d078d6e70, to=0x559d078d6bc0, rsa=0x559d078b3630,
padding=3
Sat Apr  6 15:57:20 2019 us=468060 PKCS#11:
__pkcs11h_openssl_rsa_enc - return rv=112-'CKR_MECHANISM_INVALID'
Sat Apr  6 15:57:20 2019 us=468070 SSL alert (write): fatal:
internal error
Sat Apr  6 15:57:20 2019 us=468085 OpenSSL:
error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
Sat Apr  6 15:57:20 2019 us=468092 TLS_ERROR: BIO read
tls_read_plaintext error
Sat Apr  6 15:57:20 2019 us=468097 TLS Error: TLS object ->
incoming plaintext read error
Sat Apr  6 15:57:20 2019 us=468101 TLS Error: TLS handshake
failed

Somehow, it seems that __pkcs11h_openssl_rsa_enc was called
with an unexpected padding. Any ideas on what might be the
cause of this?


As I replied to the openssl-users list[*], pkcs11-helper only
supports PKCS1 signatures, not raw signature needed in this case.

We have to either patch pkcs11-helper or switch to something else.



patching pkcs11-helper does not seem too difficult for this
particular case - but how can we test it? I have access to hw
tokens but I don't know how to trigger the "raw signature" bit.


If both server and client are built with OpenSSL 1.1.1 and TLS version 
is >= 1.2, PSS padding will get used and trigger this. OpenSSL does 
PSS padding internally and passes the padded data to the rsa_priv_enc 
calback for raw signature.


This is based on my tests for our Windows cryptoapi and 
management-external-key patches for the same -- never tried this using 
pkcs11-helper, but I expect the same behaviour.




The good news: I can reproduce this with
- openvpn 2.4.7
- openssl 1.1.1b
- pkcs11helper 1.25.1
- Safenet etoken
- client+server CentOS 7

The bad news: I don't have a fix yet.

I will keep the list posted on any progress I make,

JJK

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

Re: [Openvpn-devel] openvpn with udp lost event.

[Jan Just Keijser]

On 15/04/19 14:29, wei wang wrote:

Hi,

For function multi_process_io_udp receive many events, but only
process one at a time. Doest it cause the event to be lost?

yes it does

In our test, we had create thousands of client. When clients connect
to server at a time, for the clients which already connected on this
server will not receive packet from tun device.
that is correct - this is known limitation of  the OpenVPN 2 code base. 
Fixing this limitation is far from trivial, however.


HTH,

JJK



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

Re: [Openvpn-devel] Why does the tun-mtu default to 1500 bytes?

[Jan Just Keijser]

Hi Marcus,

On 17/04/19 00:11, Marcus Wichelmann wrote:

Hello,

I'm wondering what the reason is that OpenVPN Community sets the 
default TUN-MTU to 1500 bytes, as seen here: 
https://github.com/OpenVPN/openvpn/blob/ed31cf2ab718d879615dea81e6a17d26537ab43a/src/openvpn/mtu.h#L70
In my understanding, because of the additional overhead that the VPN 
tunnel adds to the transmitted packages, the resulting packages on the 
link interface can be larger than 1500 bytes and willl not fit through 
a regular link. This should result in fragmentation which hurts the 
tunnel throughput.
this is why OpenVPN 2 by default uses fragmentation - encrypted packets 
are fragmented by OpenVPN itself before sent over the link. The default 
fragment value is 1450 bytes, ensuring that the underlying network does 
not do extra fragmentation in most cases.




So do the default settings assume that the VPN tunnel is built using a 
link that supports jumbo-frames? How does it make sense to expect a 
link with jumbo-frame-support when probably most OpenVPN connections 
will be made over the internet?


Could somebody please explain to me, what the idea behind this 
decision was? I'm very interested in if I've overlooked something.
Wouldn't it be more helpful to most OpenVPN users when the TUN-MTU is 
dynamically calculated based on the LINK-MTU which could default to 
1500 (or even 1492 to support DSL/PPPoE internet connections)?


there's been discussion on this, esp since OpenVPN 3 does not currently 
support the 'fragment' option. However, in a real life (remote) network 
setup there is no guarantee that the local MTU value is the lowest MTU 
along the link to the remote endpoint - thus even if OpenVPN would do 
something like

  tun-mtu = local link-mtu - offset
then there is no guarantee that the packets will go through. For that 
we'd need path mtu discovery. There is some code in OpenVPN to handle 
this, but it does not cover all corner cases, so we'll still have to 
support some method to overrule any automagically determined values.


The main reason for keeping the tun-mtu at 1500 was Windows support: in 
the past, the Windows TUN driver would install with a default MTU value 
of 1500 bytes. This value could be changed, but a restart was required 
for the new value to take effect. In other words, it was not possible to 
change the tun-mtu value on the fly.  Since Windows Vista/7 we can now 
change the MTU value on the fly, and there are some checkins in the 2.5 
branch for this. I expect that in the future we'll be changing the 
tun-mtu in favor of using --fragment.


HTH,

JJK

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

Re: [Openvpn-devel] Issue with smartcard authentication for openvpn

[Jan Just Keijser]

On 10/04/19 17:58, Selva Nair wrote:

Hi,

This is more relevant to OpenVPN than OpenSSL, so copying to the 
openvpn-devel list.


On Wed, Apr 10, 2019 at 10:11 AM Francois Gelis 
mailto:francois.ge...@gmail.com>> wrote:


Hi all,

I have a working openvpn setup with client certificate and private
key stored on my laptop. Then, I have loaded them into a smartcard
(Yubico 5 NFC), and modified accordingly the openvpn client
config. But running the openvpn client now fails with an error
that seems to originate inside openssl. Here is a verbose openvpn
log (only the portion that seems relevant for this error, but I
have the full log if useful):

Sat Apr  6 15:57:20 2019 us=467260 Incoming Ciphertext -> TLS
Sat Apr  6 15:57:20 2019 us=467271 SSL state (connect): SSLv3/TLS
read server hello
Sat Apr  6 15:57:20 2019 us=467468 VERIFY OK: depth=1, CN=FG-CA
Sat Apr  6 15:57:20 2019 us=467598 VERIFY KU OK
Sat Apr  6 15:57:20 2019 us=467609 Validating certificate extended
key usage
Sat Apr  6 15:57:20 2019 us=467615 ++ Certificate has EKU (str)
TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr  6 15:57:20 2019 us=467620 VERIFY EKU OK
Sat Apr  6 15:57:20 2019 us=467625 VERIFY OK: depth=0, CN=tx2
Sat Apr  6 15:57:20 2019 us=467650 SSL state (connect): SSLv3/TLS
read server certificate
Sat Apr  6 15:57:20 2019 us=467735 SSL state (connect): SSLv3/TLS
read server key exchange
Sat Apr  6 15:57:20 2019 us=467763 SSL state (connect): SSLv3/TLS
read server certificate request
Sat Apr  6 15:57:20 2019 us=467771 SSL state (connect): SSLv3/TLS
read server done
Sat Apr  6 15:57:20 2019 us=467845 SSL state (connect): SSLv3/TLS
write client certificate
Sat Apr  6 15:57:20 2019 us=468012 SSL state (connect): SSLv3/TLS
write client key exchange
Sat Apr  6 15:57:20 2019 us=468053 PKCS#11:
__pkcs11h_openssl_rsa_enc entered - flen=256, from=0x559d078d6e70,
to=0x559d078d6bc0, rsa=0x559d078b3630, padding=3
Sat Apr  6 15:57:20 2019 us=468060 PKCS#11:
__pkcs11h_openssl_rsa_enc - return rv=112-'CKR_MECHANISM_INVALID'
Sat Apr  6 15:57:20 2019 us=468070 SSL alert (write): fatal:
internal error
Sat Apr  6 15:57:20 2019 us=468085 OpenSSL: error:141F0006:SSL
routines:tls_construct_cert_verify:EVP lib
Sat Apr  6 15:57:20 2019 us=468092 TLS_ERROR: BIO read
tls_read_plaintext error
Sat Apr  6 15:57:20 2019 us=468097 TLS Error: TLS object ->
incoming plaintext read error
Sat Apr  6 15:57:20 2019 us=468101 TLS Error: TLS handshake failed

Somehow, it seems that __pkcs11h_openssl_rsa_enc was called with
an unexpected padding. Any ideas on what might be the cause of this?


As I replied to the openssl-users list[*], pkcs11-helper only supports 
PKCS1 signatures, not raw signature needed in this case.


We have to either patch pkcs11-helper or switch to something else.


patching pkcs11-helper does not seem too difficult for this particular 
case - but how can we test it? I have access to hw tokens but I don't 
know how to trigger the "raw signature" bit.


JJK

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

Re: [Openvpn-devel] New tap-windows6 driver for Windows 7/8/8.1/Server 2012r2 ready for testing

[Jan Just Keijser]

Hi Samuli,

On 05/04/19 16:00, Samuli Seppänen wrote:

Hi,

A new pre-release tap-windows6 driver (9.23.1) is available for testing.
It should work on Windows 7/8/8.1/Server 2012r2. It _will not_ work  on
Windows 10 or Windows Server 2016/2019.

The driver includes several new features such as support for NDIS 6.30
arm64 support, improvements in driver version display, etc.

Download the installer from here:

https://build.openvpn.net/downloads/snapshots/tap-windows-9.23.1-I601.exe

For those who want the raw, signed driver files please download the zip
file:

https://build.openvpn.net/downloads/snapshots/tap-windows-9.23.1.zip

I install-tested driver on Windows Server 2012r2 and there were no
obvious problems.

It would be great if other people could smoke-test the new driver - just
install it on top of existing OpenVPN installation. In particular
running OpenVPN with the driver would be useful.

I've installed the driver on my Win 7 Pro laptop and it installed and 
runs just fine.
I also ran some performance tests and it seems the performance 
characteristics have changed a bit:
iperf download speeds are reported higher (195 Mbps vs 150 Mbps) as long 
as you don't specify any tuning options. Funnily enough you need to 
specify these options if you want to get full performance on a regular 
Ethernet interface (in which case I get 930 Mbps).


cheers,

JJK


___
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 (Wed, 12th Mar 2019)

[Jan Just Keijser]

Hi Samuli,

On 13/03/19 13:00, Samuli Seppänen wrote:

Hi,

Here's the summary of the IRC meeting.


Talked about release OpenVPN 2.x Windows installers with OpenSSL 1.1.1.
Agreed that this makes sense as people (on forums for example) already
take 2.4.x and replace the OpenSSL libraries forcibly. Mattock tested
openvpn-build with OpenSSL 1.1.1b and there were no issues - a NSI
installer was produced. The next Windows installer release will thus
have latest OpenSSL 1.1.1 version. If serious issues are found we can
always have separate installer releases for OpenSSL 1.1.0 and 1.1.1
versions.


as always, thanks for the summary and chatlog; I really wanted to attend 
this morning but got stuck in a work meeting. There was something 
related to OpenSSL 1.1.1 support that I wanted to bring up:


OpenSSL 1.1.1 does TLS v1.3; does OpenVPN support TLS v1.3 (for the 
control channel) already?  If so, then it might be a good chance to 
change the internal key derivation stuff in OpenVPN:


TLS < 1.2   --> use the sha1+md5 routines (which is basically what TLS 
itself does for TSL < 1.1
TLS >= 1.3 --> use the "export_keying_material" routines in OpenSSL, 
which will create (sha2) keys for you, based on the connection parameters.


That way, we can slowly migrate users away from the sha1+md5 stuff , 
which will help with fips compliance as well.


Thought, anyone?

JJK

PS it would also be useful to add something to the handshake protocol to 
allow the server to tell a *client* which version it is running; I am 
not aware of any way to do , currently. Push-peer-info is 
client-to-server only.





___
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 (Wed, 19th Dec 2018)

[Jan Just Keijser]

Hi list,

as a follow-up to the discussion we had in the community meeting:

(13:38:08) dazo: janjust: if you get a chance to verify whether using 
non-ncp-listed cipher works with ccd, that's a good detail to know


the answer is: yes and no ;)

Yes, it is possible to specify a *NEW* list of ncp ciphers in a CCD 
file, overruling what is specified globally, provided that this same 
"new" list of NCP ciphers is specified on the client side. This means 
that the maximum *cipher* length is dependent on whatever is specified 
in a CCD file. However, most ciphers used nowadays are 256 bits (32 
bytes) in length anyways, so the impact on the maximum cipher length is 
quite small.


No, it is NOT possible to specify a new "auth" parameter, e.g. "auth 
sha512" as this would break many things, including tls-crypt. Thus, 
there is no need to do a "worst case" calculation inside 
"crypto_max_overhead()" to determine the biggest HMAC value possible. 
Whatever is specified globally is as big as it will get.


My current conclusion is that the crypto_max_overhead function needs a 
significant rewrite. The current code is:


 755 size_t
 756 crypto_max_overhead(void)
 757 {
 758 return packet_id_size(true) + OPENVPN_MAX_IV_LENGTH
 759    +OPENVPN_MAX_CIPHER_BLOCK_SIZE
 760    +max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH);
 761 }

Question:   is the packet_id part of the crypto?  or is packet_id used, 
regardless of whether crypto is used at all? If so, then the 
packet_id_size needs to be removed from this function.


I'd be in favor of updating the above code to
- take into account the space allocated for the default/globally 
specified crypto; if the default/globally specified crypto is at the 
maximum value (currently 256 bits) then don't bother calculating a worst 
case value
- determine *at runtime* the worst case scenario for the crypto 
overhead, possibly by checking if client-config-dir and/or 
client-connect script or plugin is specified. If one of those IS 
specified, then allocate more space, otherwise use the largest cipher 
length from the first step.
- figure out whether the OPENVPN_MAX_IV_LENGTH is needed whenever an 
AEAD cipher is used - in which case the overhead needs to be calculated 
differently.


I hope others like syzzer can comment on my proposal :)

share and enjoy,

JJK



___
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 (Wed, 28th Nov 2018)

[Jan Just Keijser]

Hi Lev,

On 29/11/18 16:18, Lev Stipakov wrote:


Some background information.

In openvpn3 we decided not to implement fragments, because:

 - this is quite a big feature which has to be supported through the 
whole stack (client, server, kernel module)

 - we assume that it is not used by most of users

However, for those who needs --fragment, we'll implement:

 - mssfix support, this should solve problems with tcp-based protocols
 - sending icmp "packet too big" for other protocols, we assume that 
they'll respect icmp response


I'd thoroughly test this with protocols like Google's QUIC, which uses 
UDP underneath. How does it respond to such ICMP messages? what does it 
do to throughput?




--fragment is/was very useful on a system where you do not /
cannot change the tun MTU size. Up to Windows XP, this was not
possible without rebooting the OS. Since Vista, it *is* possible
to change the MTU of an adapter on the fly (as explained in my
trusty old cookbook, of course ;))


As James wrote a while ago (13 years ago :)

https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html

> A lot of experience gained during the OpenVPN 1.x releases showed 
that it's best to fix the tunnel MTU at
> 1500 and vary the other parameters (and use --mssfix to prevent 
fragmentation rather than a lower tunnel MTU).
Don't know if still holds. Assuming that we can change tun-mtu on any 
supported platforms, do you think that it is better

to do _that_, rather than have mssfix/icmp ptb workaround?

With that, it would be possible to fix the link-mtu to 1500 (or
whatever is set on the outbound interface) and then subtract the
header size to get a meaningful tun-mtu size.


Do you think 1500 is a safe value? Arne just mentioned today that his 
network interface MTU is 1500 and router's MTU is 1492 due to PPPoE, 
and openvpn2 works because it assumes that mtu is 1450.


I am not sure what a good default value is - it all depends on the 
intermittent networks. What OpenVPN needs is the ability to send a 
single UDP packet containing encapsulated data, knowing that that same 
single UDP packet arrives at the destination. How the underlying 
protocols/networks achieve this, is unknown.


Also, all of this applies only to UDP mode - in TCP mode it is best to 
not fragment at all - simply let the TCP stream take care of the 
encapsulated data, possible with TCP_NODELAY set.



Having said all that, I do have one gripe with the way the link or
tun mtu is calculated in the current codebase:
In the 2.3 code base, the server tun mtu size was equal to the
client tun-mtu size.
In the 2.4+ code base, the server-side tun mtu size is set to some
ridiculous low level (with link-mtu 1500 set) in order to
accomocate all possible encryption ciphers - *even if I add
ncp-disable* . To me, that does not make a whole lot of sense. If I
add '--ncp-disable' I'd expect the client and the server to behave
pretty much like an OpenVPN 2.3 client (with a possible 3
bytes difference to accomodate for the peer id).


With 2.4 codebase I noticed that what man page says is not what 
openvpn2 code does - it does include transport overhead, while

man page says it doesn't (copying my mail here):

              Announce to TCP sessions running over the tunnel that 
they should limit their send packet sizes such that after OpenVPN has 
encapsulated them, the resulting UDP packet size that OpenVPN sends to 
its peer will not exceed max bytes. The  default  value is 1450.


              The max parameter is interpreted in the same way as the 
--link-mtu parameter, i.e. the UDP packet size after encapsulation 
overhead has been added in, but not including the UDP header itself. 
Resulting packet would be at most 28 bytes larger for IPv4 and 48 
bytes for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header).


So it means that with "mssfix" 1300 resulting IPv4 packet size would 
be at most 1328.


This is what I see in Wireshark (server - git master, client 2.4.6):

Internet Protocol Version 4, Src: 128.199.xxx.yyy, Dst: 10.0.200.20
    0100  = Version: 4
     0101 = Header Length: 20 bytes (5)
    Total Length: 1300
    Protocol: UDP (17)
User Datagram Protocol, Src Port: 1194, Dst Port: 1194
    Source Port: 1194
    Destination Port: 1194
    Length: 1280
OpenVPN Protocol
    Type: 0x49 [opcode/key_id]
    Peer ID: 0
    Data (1268 bytes)

While man page statement is technically correct - UDP packet size is 
1300, which is "at most 1328", I think it should say:


> the resulting IP packet size that OpenVPN sends to its peer will not 
exceed max bytes


and

> The max parameter is interpreted in the same way as the --link-mtu 
parameter, i.e. the IP packet size
after encapsulation overhead has been added in, including UDP and IP 
headers.


you seem to be talking about the mssfix size, wheras I am talking about 
the tun-mtu size. When you add

  link-mtu 1500
  ncp-di

Re: [Openvpn-devel] Summary of the community meeting (Wed, 28th Nov 2018)

[Jan Just Keijser]

On 30/11/18 17:27, Kristian McColm wrote:

1500 is not safe on many mobile/cell networks as most have a smaller MTU like 
1460 due to GTP headers used between the PGW and eNodeB. There is also reduced 
MTU when performing NAT64, i.e. packets translated from IPv4 to IPv6 become 20 
bytes larger after translation due to additional IP header bytes.

I believe it is most efficient to implement an application layer fragmentation 
feature, similar to IKEv2 fragmentation (RFC7383) so that the underlying 
network layer does not have to perform IP layer fragmentation which has known 
risks.

that is pretty much what --fragment does...


Additionally, TCP MSS rewriting only works for TCP. Many VPNs use UDP which is 
not helped by MSS fix obviously. If supported by the client/server OS, path MTU 
discovery can be used to determine the MTU of a given connection.
TCP MSS using --mssfix works inside the tunnel only, and only for TCP 
connections. It does not depend on the outside protocol (UDP or TCP).


I fully agree that having PMTUD would be nice to have, but even that has 
its drawbacks...


JM2CW,

JJK


-Original Message-
From: Jan Just Keijser [mailto:janj...@nikhef.nl]
Sent: November 30, 2018 11:16
To: Simon Matter ; Lev Stipakov 
Cc: openvpn-devel@lists.sourceforge.net
Subject: Re: [Openvpn-devel] Summary of the community meeting (Wed, 28th Nov 
2018)

Hi Lev, Simon,

On 30/11/18 07:10, Simon Matter wrote:

Hi Jan Just,

(forgot to add openvpn-devel in previous mail)

Some background information.

In openvpn3 we decided not to implement fragments, because:

   - this is quite a big feature which has to be supported through the
whole stack (client, server, kernel module)
   - we assume that it is not used by most of users

However, for those who needs --fragment, we'll implement:

   - mssfix support, this should solve problems with tcp-based protocols
   - sending icmp "packet too big" for other protocols, we assume that
they'll respect icmp response

--fragment is/was very useful on a system where you do not / cannot
change

the tun MTU size. Up to Windows XP, this was not possible without
rebooting the OS. Since Vista, it *is* possible to change the MTU of
an adapter on the fly (as explained in my trusty old cookbook, of
course ;))


As James wrote a while ago (13 years ago :)

https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html


A lot of experience gained during the OpenVPN 1.x releases showed
that

it's best to fix the tunnel MTU at

1500 and vary the other parameters (and use --mssfix to prevent

fragmentation rather than a lower tunnel MTU).

Don't know if still holds. Assuming that we can change tun-mtu on any
supported platforms, do you think that it is better to do _that_,
rather than have mssfix/icmp ptb workaround?



With that, it would be possible to fix the link-mtu to 1500 (or
whatever is set on the outbound interface) and then subtract the
header size to get a meaningful tun-mtu size.


Do you think 1500 is a safe value? Arne just mentioned today that his
network interface MTU is 1500 and router's MTU is 1492 due to PPPoE,
and openvpn2 works because it assumes that mtu is 1450.

I also think 1500 isn't safe because different types ob internet
connections may reduce it, like the mentioned PPPoE.



this is why the --fragment feature is so handy - no need to change the mtu 
values on either end, yet you can fiddle with the fragmentation size to tune 
performance.

I agree that in most home environments the MTU size should be lower - if you 
look at e.g. IPsec you will find that it sets the tunnel MTU size to
1360 to ensure that it will "almost always" work.
Having said that, I'd like see a solution that will work in 99% of the cases *AND* that 
will give most users close-to-optimal performance.  If "fragment" is not 
implemented in OpenVPN 3 then what happens if the tun MTU is too high?  where does 
fragmentation occur? at the OS level? at the UDP level?  I'd prefer to leave any 
fragmenting to the underlying OS as much as possible - hence if I want to send packets of 
4000 bytes than either they are fragmented at the tun level (i.e. before they are 
processed by OpenVPN) or at the transport level (i.e. OpenVPN spits out a 4000 byte 
packet over the UDP/TCP connection, which the OS then fragements).  The problem with 
fragmenting at the UDP level is that you need to keep track of the fragments in order to 
reassemble them - TCP does this for you.

cheers,

JJK



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




___
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 (Wed, 28th Nov 2018)

[Jan Just Keijser]

Hi Lev, Simon,

On 30/11/18 07:10, Simon Matter wrote:

Hi Jan Just,

(forgot to add openvpn-devel in previous mail)

Some background information.

In openvpn3 we decided not to implement fragments, because:

  - this is quite a big feature which has to be supported through the whole
stack (client, server, kernel module)
  - we assume that it is not used by most of users

However, for those who needs --fragment, we'll implement:

  - mssfix support, this should solve problems with tcp-based protocols
  - sending icmp "packet too big" for other protocols, we assume that
they'll respect icmp response

--fragment is/was very useful on a system where you do not / cannot change

the tun MTU size. Up to Windows XP, this was not
possible without rebooting the OS. Since Vista, it *is* possible to
change
the MTU of an adapter on the fly (as explained in my
trusty old cookbook, of course ;))


As James wrote a while ago (13 years ago :)

https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html


A lot of experience gained during the OpenVPN 1.x releases showed that

it's best to fix the tunnel MTU at

1500 and vary the other parameters (and use --mssfix to prevent

fragmentation rather than a lower tunnel MTU).

Don't know if still holds. Assuming that we can change tun-mtu on any
supported platforms, do you think that it is better
to do _that_, rather than have mssfix/icmp ptb workaround?



With that, it would be possible to fix the link-mtu to 1500 (or
whatever is set on the outbound interface) and then subtract the header
size to get a meaningful tun-mtu size.


Do you think 1500 is a safe value? Arne just mentioned today that his
network interface MTU is 1500 and router's MTU is 1492 due to
PPPoE, and openvpn2 works because it assumes that mtu is 1450.

I also think 1500 isn't safe because different types ob internet
connections may reduce it, like the mentioned PPPoE.


this is why the --fragment feature is so handy - no need to change the 
mtu values on either end, yet you can fiddle with the fragmentation size 
to tune performance.


I agree that in most home environments the MTU size should be lower - if 
you look at e.g. IPsec you will find that it sets the tunnel MTU size to 
1360 to ensure that it will "almost always" work.
Having said that, I'd like see a solution that will work in 99% of the 
cases *AND* that will give most users close-to-optimal performance.  If 
"fragment" is not implemented in OpenVPN 3 then what happens if the tun 
MTU is too high?  where does fragmentation occur? at the OS level? at 
the UDP level?  I'd prefer to leave any fragmenting to the underlying OS 
as much as possible - hence if I want to send packets of 4000 bytes than 
either they are fragmented at the tun level (i.e. before they are 
processed by OpenVPN) or at the transport level (i.e. OpenVPN spits out 
a 4000 byte packet over the UDP/TCP connection, which the OS then 
fragements).  The problem with fragmenting at the UDP level is that you 
need to keep track of the fragments in order to reassemble them - TCP 
does this for you.


cheers,

JJK



___
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 (Wed, 28th Nov 2018)

[Jan Just Keijser]

Hi,

On 29/11/18 09:03, Samuli Seppänen wrote:

[...]



Had a discussion about --fragment. Agreed that if we can fix internal
fragmentation without needing a change in frame format then we can
definitely deprecate --fragment in the long-term. Also noted that lack
of tun-mtu support on Windows might be for historic reasons and might
not apply to tap-windows6. Also questioned whether the default MTU of
1500 is the best possible choice.


I wish I'd known about this discussion - I saw the topic list and figured I 
wouldn't be able to contribute much to the discussion.
Regarding MTU/fragment however.

--fragment is/was very useful on a system where you do not / cannot change the tun MTU size. Up to Windows XP, this was not 
possible without rebooting the OS. Since Vista, it *is* possible to change the MTU of an adapter on the fly (as explained in my 
trusty old cookbook, of course ;))


--fragment is also quite useful in combination with compression, to ensure that the payload never exceeded a particular size 
*after* compression+encryption+encapsulation.


Now that Windows XP and below are gone, and now that compression+encryption is considered evil (voracle) it might be possible to 
better calculate/predict the maximum encrypted payload size. With that, it would be possible to fix the link-mtu to 1500 (or 
whatever is set on the outbound interface) and then subtract the header size to get a meaningful tun-mtu size.


As for mtu=1500 being the best possible choice: that depends if you are doing routing on your VPN or not. 95+ % of all Ethernet 
LANs have the MTU set to 1500 - increasing the tun MTU to 9000 does not increase performance, as forwarded packets are coming in 
from the LAN at 1500 bytes. If we can come up with an efficient method to gather a bunch of packets before processing them 
inside OpenVPN then I am all for increasing the MTU to something higher (why not go for 65000?). However, until we can do that 
increasing the tun mtu size will do little to improve (routing/forwarding) performance.


Having said all that, I do have one gripe with the way the link or tun mtu is 
calculated in the current codebase:
In the 2.3 code base, the server tun mtu size was equal to the client tun-mtu 
size.
In the 2.4+ code base, the server-side tun mtu size is set to some ridiculous low level (with link-mtu 1500 set) in order to 
accomocate all possible encryption ciphers - *even if I add ncp-disable* . To me, that does not make a whole lot of sense. If I 
add '--ncp-disable' I'd expect the client and the server to behave pretty much like an OpenVPN 2.3 client (with a possible 3 
bytes difference to accomodate for the peer id).


JM2CW,

JJK



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

Re: [Openvpn-devel] foreign_option_2 not set in 2.4

[Jan Just Keijser]

Hi,

On 22/11/18 15:43, Arne Schwabe wrote:

Am 22.11.18 um 14:46 schrieb Cyril Scetbon:

OpenVPN 2.4.6 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4]
[EPOLL] [MH/PKTINFO] [AEAD] built on Jul  8 2018

Output with —verb 4 https://pastebin.com/huQmnGaU


Read your log closer. This is not a bug in OpenVPN but rather a broken
config what we accepted in 2.3:

Thu Nov 22 13:34:56 2018 us=235164 PUSH: Received control message:
'PUSH_REPLY,route 10.0.0.0 255.0.0.0,route 192.168.174.0
255.255.255.0,route 193.252.149.32 255.255.255.224,route 193.252.121.96
255.255.255.224,dhcp-option DNS 10.201.67.120,dhcp-option DOMAIN
cyril.net cyril2.net,route 10.252.12.150,topology net30,ping
5,ping-restart 30,ifconfig 10.252.12.158 10.252.12.157'

Thu Nov 22 13:34:56 2018 us=235314 Options error: Unrecognized option or
missing or extra parameter(s) in [PUSH-OPTIONS]:6: dhcp-option (2.4.6)

OpenVPN gets 'dhcp-option DOMAIN cyril.net cyril2.net' via push and
using two arguments after DOMAIN is wrong but OpenVPN 2.3 ignored the
second argument while 2.4 gives you an error and ignores the whole option.

so what Arne is trying to say is:

with 2.4, do not use
  push "dhcp-option DOMAIN cyril.net cyril2net"
but use
  push 'dhcp-option "DOMAIN cyril.net cyril2net"'
instead.
Having said, that, pushing two DOMAINS does not make sense, AFAIK: Windows will 
only pick up one of them...

HTH,

JJK



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

Re: [Openvpn-devel] Adding Google Analytics code to Trac?

[Jan Just Keijser]

Hi,

On 24/10/18 13:47, Samuli Seppänen wrote:

Hi,

The OpenVPN Inc. webmaster would like to add Google Analytics to
community.openvpn.net, i.e. our Trac wiki/bug tracker. I said we need to
consult the community first because GA can be seen as a form of spying.
Here's our webmaster's view on this subject:

---

"The goal of this would be to understand what information first-time
users are finding the most valuable on community.openvpn.net."

"As this is a publicly accessible community without the requirement to
join to read the articles, it would be advantageous for all to
understand which pieces of content the public are finding the most
useful, what encourages them to become a part of the community, and what
potentially persuaded them to use start using a commercial product."

"As openvpn.net links to community.openvpn.net and vice versa this will
also help us to understand the complete journey of a user and help to
improve the website experience, which can only be seen as a positive."

---

In today's community meeting there was some concern about the spying
aspect of Google Analytics, but nobody was strongly opposed. This was I
believe, in part, because it is fairly easy to block Google Analytics if
one so wishes.



just make sure to remain GDPR compliant:

- update the privacy policy to CLEARLY state that you are doing this and why:
    What information is being collected?
    Who is collecting it?
    How is it collected?
    Why is it being collected?
    How will it be used?
    Who will it be shared with?
    What will be the effect of this on the individuals concerned?
    Is the intended use likely to cause individuals to object or complain?
- this privacy policy must be presented to the user the first time {s}he access 
Trac, asking for consent
- build an opt-in/opt-out mechanism
- honor a user's GDPR right to be "forgotten" ie offer the ability to remove my 
data whenever I request it.

Having said that, my browser always blocks GA so you'll learn nothing from me ;)

but in short: do you REALLY want to go through all that trouble just to collect 
some lousy statistics?

Even shorter answer: I strongly oppose adding GA and might/will refrain from 
using OpenVPN Trac as a result.

JM2CW,

JJK




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

Re: [Openvpn-devel] [Openvpn-users] disabling compression on the fly?

[Jan Just Keijser]

Hi Ralf,

On 09/10/18 13:35, Ralf Hildebrandt wrote:

Currently we're suppling our user with a charite.ovpn File containing:

...
compress lzo
...

In some cases, we're overriding this on the server side by using:

if (defined $ENV{'IV_LZ4'}) {
$logger->info("$username lz4: available");
push @outline, 'compress lz4';
push @outline, 'push "compress lz4"';
# push old style and new style options!
}

Now a recent version of openvpn.connect on IOS (3.0.2) has broken
this, by disabling compression by default.

My idea: Since the client config already enables framing for
compression, why not turn compression off - on the fly - for every
client?

How would I push an "empty" compression parameter?
Is this feasible at all?

very interesting question...  and I had to dive into the source code to 
find the following:


7420 VERIFY_PERMISSION(OPT_P_COMP);
7421 if (p[1])
7422 {
7423 if (streq(p[1], "stub"))
7424 {
7425 options->comp.alg = COMP_ALG_STUB;
7426 options->comp.flags = 
(COMP_F_SWAP|COMP_F_ADVERTISE_STUBS_ONLY);

7427 }
7428 else if (streq(p[1], "stub-v2"))
7429 {
7430 options->comp.alg = COMP_ALGV2_UNCOMPRESSED;
7431 options->comp.flags = COMP_F_ADVERTISE_STUBS_ONLY;
7432 }

which means that if you would use
  compress stub-v2
then you'd basically end up with bogus compression - this does not seem 
to be documented and I have no idea what the main difference is between 
'stub' and 'stub-v2'.


YMMV,

JJK




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

Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle

[Jan Just Keijser]

On 27/08/18 14:46, David Sommerseth wrote:

On 24/08/18 21:16, Gert Doering wrote:

You do not need to agree with me on this, you just need to accept this
as a fact of life.  I will resist any change that removes useful
functionality from the "swiss tool kit of VPN" side of OpenVPN just
because users could "get it wrong".

The only thing I am willing to agree to here, is that we have very different
views of how to ensure OpenVPN provides a secure VPN solution and how to
achieve that goal.

 From my point of view, in the moment a VPN is susceptible to not provide a
solid protection of a connections content, it is no longer a Virtual _Private_
Network.  It is just a virtual network.  And that is an entirely different
product.

I'm not going to argue the other points of yours, as I do not see this leading
this discussion forward.  I just disagree with your point of view and think
they do not move OpenVPN in the right direction of the security requirements
of the 21th century.  My stance is clear: Compression and encryption does not
belong together.
I don't think anyone disagrees with you taht compression+encryption is 
unsafe. However, the dangers or compression+encryption are overstated, 
IMHO.
However, I happen to agree with Gert that OpenVPN is a Swiss army knife 
VPN toolbox, and if one of those tools makes a user's VPN unsafe, then 
so be it.   I have good use for disabling encryption in a VPN tunnel - 
fully well knowing that it makes things unsafe. I may be warned about 
this, but if a tool prohibits me from doing something stupid then it is 
IMO a bad tool.



No, because this is silly.   By your own argument, people are not expected
to compile openvpn nowadays ("this is what distribution maintainers will
do for you"), and we're *removing* #ifdefs, not adding new ones.

Wrong.  We have those #ifdefs already, it just needs to be reverted and add an
additional logic in configure.ac to "unlock" unsafe features.  Look for
ENABLE_LZO and ENABLE_LZ4 in the code.

And I still believe features which enables known attack vectors mandates
compile time configuration.  Those sites really requiring this feature should
be capable of rolling their own builds.

Further, some metrics would be good to have in this discussion as well:

  - How efficient is compression on today's tunnels? Both in special use case
scenarios as well as the more common and average use cases.

  - How many sites demands and depends on compression, where their use case
really results in a noticeable results with compression?

This kind of metrics is the only thing which truly can make me reconsider my
view.  And it needs to be a considerable amount of use cases, as it is waste
of time and energy to keep specific features alive if there is just 2-3% of
the user base really needing and requiring it - especially when the risk for
weakened security for the 97-98% of users is considerably higher.
These are interesting metrics - and I suspect that for more users 
compression does more harm than good in terms of performance. However, I 
do not think it is up to the developers (you/we) to decide whether a 
user can enable encryption or not.



But, there is one aspect we have not touched.  Things are moving forward with
the transport plug-in patches, even though the primary goal currently is to
handle obfuscation.  It should be investigated whether compression can be put
in as part of this plug-in API.  This means you can have your compression
feature and the core of OpenVPN itself can be without compression.  I will not
object to such an approach.

A transport plugin to handle encryption/obfuscation would work, I guess, 
but then you run into the problem of running OpenVPN with "safe" or 
"unsafe" plugins - should we warn users about that? prohibit it?  Again, 
I would not like a tool that prohibits me from doing stupid : that's the 
whole Unix/Linux philosophy I guess. Since when can I not type in

  rm -rf /
any more ?  did someone build in a flag into the "rm" command to stop me 
from doing so? I sure hope not.


JM2CW,

JJK



--
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] [PATCH v2] Fix typo in IPv6 address in comment.

[Jan Just Keijser]

Hi Gert,

On 15/07/18 22:43, Gert Doering wrote:

Comment talks about ff02::1::ff00:8, correct address is ff02::1:ff00:8,
and about fe80::1 where fe80::8 is the proper magic number.


thanks for this patch!
What the CVE for this ?  when do we get an emergency patch? will this change be 
backported to OpenVPN 2.3?

;)

JJK


Signed-off-by: Gert Doering 
---
  src/txpath.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/txpath.c b/src/txpath.c
index 97b9862..5b61177 100644
--- a/src/txpath.c
+++ b/src/txpath.c
@@ -108,8 +108,8 @@ HandleIPv6NeighborDiscovery(
  // - it's either a multicast MAC, or the userland destination MAC
  // but since the TAP driver is point-to-point, all packets are "for us"
  
-// IPv6 target address must be ff02::1::ff00:8 (multicast for

-// initial NS) or fe80::1 (unicast for recurrent NUD)
+// IPv6 target address must be ff02::1:ff00:8 (multicast for
+// initial NS) or fe80::8 (unicast for recurrent NUD)
  if ( memcmp( ipv6->daddr, IPV6_NS_TARGET_MCAST,
  sizeof(IPV6ADDR) ) != 0 &&
  memcmp( ipv6->daddr, IPV6_NS_TARGET_UNICAST,



--
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] Does the OpenVPN protocol itself handle windowing?

[Jan Just Keijser]

Following up on myself

On 05/06/18 14:25, Jan Just Keijser wrote:


On 01/06/18 02:50, Derek Zimmer wrote:
I'm still working on this, as I think it is worthwhile for us to 
explore and get some hard data on how all of these things perform in 
a real world environment.


I've been stalled by transitioning to a new job.

>Same here. I guess this interacts with other properties, like the delay
>OpenVPN itself adds.  And that is where AES-GCM, with it's blazingly
>fast hardware acceleration, outperforms AES-CBC + HMAC-SHA in orders of
>magnitude (at the crypto level).

This might be interesting, and it also might be why my real world 
testing doesn't match what we see at 
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux

<https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux>

It looks like this experiment was conducted on machines on a LAN with 
virtually no latency / forwarding being done, so while it does show 
us some theoretical numbers they don't seem to apply to the 
real-world use-cases that we are hoping to get these types of 
performance figures for.


As soon as we start adding latency and jitter performance seems to 
tank with these optimizations.


So that I am not chasing phantoms, do we have any real-world examples 
of the claim by janj...@nikhef.nl <http://nikhef.nl> or are we just 
going off of the Gigabit_Networks_Linux page? If we have real world 
examples of configurations that can push more than 250Mbit (on a 1Gb 
controller) or 2.5Gbit (on a 10Gb controller) over connections with 
more than 10ms of latency then it would allow me to significantly 
narrow my search for problem areas.




the experiment *was* conducted on a LAN with virtually no latency at 
that time. However, I've just repeated the experiment going from a 
university to my institute (~ 50 km distance) using a 1 Gbps 
connection. The results are nearly identical:


[  5] local 10.200.0.2 port 34072 connected with 10.200.0.1 port 5001
[  5]  0.0-10.0 sec   707 MBytes   592 Mbits/sec
[  4] local 10.200.0.2 port 5001 connected with 10.200.0.1 port 51086
[  4]  0.0-10.0 sec   874 MBytes   731 Mbits/sec

(where the LAN performance is ~ 910 Mbps).
Server:  Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz
Client:  Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz

so as you see I am using 4+ year old hardware for this.

I am happy to work with you to figure out what is causing the 
performance to tank. I've got access to 1 & 10 Gbps (and possible 
higher) internet links and am very curious  what is causing the jitter 
on your end.


For higher latency links, the main option to tweak seems to be 
--txqueuelen : increase this to at least 1000 to improve performance.




after I add an artificial latency of 20 ms on both ends using |
  tc qdisc add dev eth0 root netem delay 20ms|
I do see quite a difference:
  outside the tunnel performance ~ 500 Mbps both ways
  inside the tunnel:
        client->server:  40 Mbps ;
        server->client: ~200 Mbps

It's not an iperf connection issue, if I reverse the client and server 
(i.e iperf -s and iperf -c ) then the numbers are swapped - hence it 
seems that the *tunnel itself* is slower in one direction than the other 
. Both client and server are running the same OS and the same version of 
OpenVPN.


Ping time between hosts is now 42 ms (2+2x20)
So for some strange reason an assymmetry is introduced; playing with 
--txqueuelen, --rcvbuf or --sndbuf did not help to remove this 
assymmetry. Also, when I read

http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/
I am not surprised that performance drops off with a higher latency ... 
it is always worth investigating how to reduce the latency over a 
LAN/WAN before attempting to tweak a VPN connection.


The assymmetry part is what puzzles me the most - I will keep looking 
into that.


cheers,

JJK

--
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] Does the OpenVPN protocol itself handle windowing?

[Jan Just Keijser]

Hi,

On 01/06/18 02:50, Derek Zimmer wrote:
I'm still working on this, as I think it is worthwhile for us to 
explore and get some hard data on how all of these things perform in a 
real world environment.


I've been stalled by transitioning to a new job.

>Same here. I guess this interacts with other properties, like the delay
>OpenVPN itself adds.  And that is where AES-GCM, with it's blazingly
>fast hardware acceleration, outperforms AES-CBC + HMAC-SHA in orders of
>magnitude (at the crypto level).

This might be interesting, and it also might be why my real world 
testing doesn't match what we see at 
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux

<https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux>

It looks like this experiment was conducted on machines on a LAN with 
virtually no latency / forwarding being done, so while it does show us 
some theoretical numbers they don't seem to apply to the real-world 
use-cases that we are hoping to get these types of performance figures 
for.


As soon as we start adding latency and jitter performance seems to 
tank with these optimizations.


So that I am not chasing phantoms, do we have any real-world examples 
of the claim by janj...@nikhef.nl <http://nikhef.nl> or are we just 
going off of the Gigabit_Networks_Linux page? If we have real world 
examples of configurations that can push more than 250Mbit (on a 1Gb 
controller) or 2.5Gbit (on a 10Gb controller) over connections with 
more than 10ms of latency then it would allow me to significantly 
narrow my search for problem areas.




the experiment *was* conducted on a LAN with virtually no latency at 
that time. However, I've just repeated the experiment going from a 
university to my institute (~ 50 km distance) using a 1 Gbps connection. 
The results are nearly identical:


[  5] local 10.200.0.2 port 34072 connected with 10.200.0.1 port 5001
[  5]  0.0-10.0 sec   707 MBytes   592 Mbits/sec
[  4] local 10.200.0.2 port 5001 connected with 10.200.0.1 port 51086
[  4]  0.0-10.0 sec   874 MBytes   731 Mbits/sec

(where the LAN performance is ~ 910 Mbps).
Server:  Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz
Client:  Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz

so as you see I am using 4+ year old hardware for this.

I am happy to work with you to figure out what is causing the 
performance to tank. I've got access to 1 & 10 Gbps (and possible 
higher) internet links and am very curious  what is causing the jitter 
on your end.


For higher latency links, the main option to tweak seems to be 
--txqueuelen : increase this to at least 1000 to improve performance.



Please contact me off-list if you want to work together on this.

HTH,

JJK / Jan Just Keijser

On Sun, May 6, 2018 at 8:04 AM, Steffan Karger <mailto:stef...@karger.me>> wrote:


Hi,

On 04-05-18 17:45, Jan Just Keijser wrote:
> On 04/05/18 16:41, Derek Zimmer wrote:
>> What conclusions can we draw from this?
>>
> My main conclusion has always been that OpenVPN is limited by
the number
> of user-to-kernel space transitions , not by anything else.

Same here. I guess this interacts with other properties, like the
delay
OpenVPN itself adds.  And that is where AES-GCM, with it's blazingly
fast hardware acceleration, outperforms AES-CBC + HMAC-SHA in
orders of
magnitude (at the crypto level).

Some while ago, I looked a bit into this, and started at looking to
improve the user/kernel interfaces.  I posted a proof-of-concept patch
that might be interesting to check out if you're doing performance
testing:

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13699.html

<https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13699.html>

I'd be very interested to know if using recvmmsg() improves the
performance in you measurements.  (I never got to picking this up
again,
because dayjob, bug reports and life in general got in the way...)

-Steffan


--
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
<mailto:Openvpn-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
<https://lists.sourceforge.net/lists/listinfo/openvpn-devel>




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_

Re: [Openvpn-devel] [PATCH 1/2] make tls-auth a per-connection-block option

[Jan Just Keijser]

Hi,

On 04/06/18 09:15, Gert Doering wrote:

On Mon, Jun 04, 2018 at 09:10:23AM +0200, Jan Just Keijser wrote:

What's the particular use case for putting tls-auth files in connection
blocks?

"I have one existing server that is not using tls-auth yet, and a new one
that has tls-auth, and I want both in the same config file"

Plus, what Steffan mentioned: tls-auth rollover

hmmm, of course, some people even asked me what the best way to do 
tls-auth rollover is...


I could also see a use case where you have a single config with "proto 
udp" and "proto tcp" , where the "proto udp" block has a tls-auth key 
but the "proto tcp" does not  -   the use case for "tls-auth" is mostly 
UDP anyways, as TCP connections are not so easy to protect against DoS 
attacks.  I assume that will also be possible?


JJK


--
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] [PATCH 1/2] make tls-auth a per-connection-block option

[Jan Just Keijser]

Hi Antonio,

On 04/06/18 04:15, Antonio Quartulli wrote:

Hi all,

On 02/06/18 11:42, Antonio Quartulli wrote:

Different VPN servers may use different tls-auth keys. For this
reason it is convenient to make tls-auth a per-connection-block
option so that the user is allowed to specify one key per remote.

If no tls-auth option is specified in a given connection block,
the global one, if any, is used.

Trac: #720
Cc: Steffan Karger 
Signed-off-by: Antonio Quartulli 

as reported by Steffan on IRC, this feature breaks when using
"--persist-key".
It happens because, when moving to the next connection block, OpenVPN
won't load the new tls-auth key and therefore will trigger an assertion.

After further discussing this issue, it was agreed that we have two main
options to tackle this issue:

1) pre-load all the tls-auth keyfiles (like if they were embedded in the
config file)
2) make per-connection-block tls-auth keys mutually exclusive with
--persist-key


while point 2) would be the easiest option and would require the least
amount of code, we believe that 1) is still the best from the user
perspective and from the option semantics point of view (as it would not
lead to any behaviour change).

Therefore a v2 patch will be sent implementing approach 1).


this is a very interesting patch ! And I agree, approach 1) is the way 
to go, as we've been advising people to use "persist-key" for a looong 
time now.


What's the particular use case for putting tls-auth files in connection 
blocks?  Does it apply only to tls-auth/tls-crypt files or also the 
certificate/private keys?  I could see a use case for that as well...


JM2CW,

JJK


--
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] [PATCH] Support fingerprint authentication

[Jan Just Keijser]

Hi all,

On 25/05/18 22:56, Simon Rozman wrote:

JJK, I think you are misreading this proposal. No hash is being sent
as a part of the handshake  -- its still client and server
certificates that are exchanged and checked during handshake. The hash
is exchanged by a separate channel (say snail mail:) in advance, and
serves the purpose of establishing trust (ie., the prior knowledge of
hash replaces the prior knowledge of a trusted CA). How the hash is
exchanged is beyond the scope of openvpn or TLS handshake in this
case.

Right to the point, Selva. This is the best description of this proposal.


no, I've heard a lot and talked a lot about this proposal before it ended up
on
the list. I do know what the purpose is, it's just that I have serious
doubts
about replacing
( pub/priv key plus  'trust anchors' such as CA certificates ) by
( we all trust each other because we know each other's SHA2 hashes )
There are downsides to a PKI with certificates but I think we're throwing
out
too much of the good stuff by allowing "just a hash" as the basis for
trust.  And one of my main concerns is that people keep comparing it to
"that's just like how SSH does it" - *THAT* is simply not true.

JJK, I am sorry I brought SSH as an example. I didn't mean "exactly" like SSH.
Just, "kind of like" SSH.

In this proposal, we leave the TLS handshake to handle public key exchange as
usual. No need to modify client<->server communication.
The only difference is how server and client verify peer's certificate
validity. Normally, they check peer's certificate fields like "Not valid
before", "Not valid after", "Issued By" etc. In this proposal, they'd only
check peer certificate by its SHA thumbprint - and skip all other standard
certificate checks.

This would allow you to have a CA-less OpenVPN setup:
- Make self-signed certificate on server and each client (with like 100 years
validity),
- Deploy server certificate hash in client.ovpn,
- List acceptable client certificate hashes in server.ovpn (Or use an external
script to do the hash lookup)




this discussion has muddled along both off and on this mailing list. I apologize in advance for being nitpicky, but when 
touching the "core" security layer of OpenVPN I think we need to be very careful and express very carefully and precisely what 
it is we want to add/change/remove.


As far as I can now oversee, what the original (off-list) proposal has boiled 
down (or watered down) to now, is

1. wouldn't it be great to allow users to specify self-signed certificates instead of having to use a full-blown PKI or CA 
certificate?
For this, an option like "ca none" would useful, esp since this is explicitly allowed since the TLV v1.1 spec (before that, it 
was not clear whether it was allowed or not).

Therefore, I tend to ACK the feature request to allow an 'empty' CA list, so 
that people can more easily use self-signed certs.

Note that it currently is possible to come close to using self-signed certs, by creating CA certificates and use those as 
host/client certs as well (I will need to test this a bit further on different platforms, and I have no clue how mbedTLS likes this)


2. instead of storing a certificate on each side, wouldn't it be nice to be able to store the public key only of the 
certificate, or perhaps even a hash of the public key of the certificate?
To me, storing either the certificate itself is not a problem (I recall Jason Donenfeld wanting to get rid of X509 certs 
altogether - something I strongly disagree with), but storing its public key should also be good - this mimicka SSH pub/priv 
key, so we could even re-use parts of the SSH code for this. One could even imagine getting the public key for a particular user 
out of his/her ~/.ssh/authorized_keys file.
Then, to make things even shorter, it was proposed to add *hashes* of public keys of certificates. To me, the added value of 
using a 256 bit hash instead of a 1024/2048 bit pubkey is limited, and I would like some assurance that this indeed foolproof. 
Other than that, I wouldn't NACK this feature, as long as it remains optional.


3. how a person gets the public key or hash of the client or server side certificate to the "other side" is pretty much out of 
scope: it simply requires "a secure channel". I am fine with that.


Note that browser certificate pinning is something else entirely: that is an *extra* check , on top of the cert chain check, to 
ensure that a server certificate (for, e.g. google.com) was signed by one of the "pinned" CA certificates. Browsers tend to 
trust a large number of CA certs, so this extra check makes sense there. As long as OpenVPN is not configured to trust 100+ CA's 
then this check does not make a lot fo sense in OpenVPN.




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Openvpn-devel] [PATCH] Support fingerprint authentication

[Jan Just Keijser]

Hi Selva,

On 25/05/18 16:07, Selva Nair wrote:

On Fri, May 25, 2018 at 9:51 AM, Jan Just Keijser  wrote:

On 25/05/18 03:41, Simon Rozman wrote:

Private and public key are still used. The patch stil uses
certificates and TLS, it only replaces the check certificate of the
peer's certificate against the CA with a hash check (certificate
pinning if you want).

So basically instead of saying that you trust all certificates signed
by a CA, you only trust only those certifcates of which have hashes. A
certificate pinning of an unknown CA is exactly the same. Since you
cannot verify that certificate you add a one off certificate in your
list of trusted certificates.

Correct me if I'm wrong, but this approach allows for self-signed

certificates

too, right?

Exactly! Client and server can use whatever certificate they like or make
a
self-signed one. All they need to do is to exchange their fingerprints
over
some trustworthy channel.

Simple. Like SSH.



for the record: this is not entirely the same as SSH. What happens when
establishing an SSH connection to a new server is that you send the *public
key* to the server, not a hash; similarly the server sends its public key to
the client. The client needs to accept this new key, otherwise the
connection is aborted. For public/priv authentication to work, the server
must know the public key of the client (listed in the authorized_keys file)
, otherwise the user is prompted for a password. Thus, for SSH a
'trustworthy channel' consists of the user typing 'y' when connecting to a
new server and the server accepting a username+password upon first
connection from a client.

To implement a similar feature in OpenVPN would require a way to send only
the public key upon TLS initialisation, and these public keys would then
need to be stored/listed on the server somewhere. Probably possible, but a
different approach then to what is proposed above. I'd be (slightly) in
favour of sending public keys instead of hashes, BTW, as it them more
closely mimicks what SSH does.

Me too chiming in :)

JJK, I think you are misreading this proposal. No hash is being sent
as a part of the handshake  -- its still client and server
certificates that are exchanged and checked during handshake. The hash
is exchanged by a separate channel (say snail mail:) in advance, and
serves the purpose of establishing trust (ie., the prior knowledge of
hash replaces the prior knowledge of a trusted CA). How the hash is
exchanged is beyond the scope of openvpn or TLS handshake in this
case.


no, I've heard a lot and talked a lot about this proposal before it 
ended up on the list. I do know what the purpose is, it's just that I 
have serious doubts about replacing

  ( pub/priv key plus  'trust anchors' such as CA certificates )
by
  ( we all trust each other because we know each other's SHA2 hashes )
There are downsides to a PKI with certificates but I think we're 
throwing out too much of the good stuff by allowing "just a hash" as the 
basis for trust.  And one of my main concerns is that people keep 
comparing it to "that's just like how SSH does it" - *THAT* is simply 
not true.


JM2CW,

JJK

--
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] [PATCH] Support fingerprint authentication

[Jan Just Keijser]

Hi,

On 25/05/18 03:41, Simon Rozman wrote:

Private and public key are still used. The patch stil uses
certificates and TLS, it only replaces the check certificate of the
peer's certificate against the CA with a hash check (certificate
pinning if you want).

So basically instead of saying that you trust all certificates signed
by a CA, you only trust only those certifcates of which have hashes. A
certificate pinning of an unknown CA is exactly the same. Since you
cannot verify that certificate you add a one off certificate in your
list of trusted certificates.

Correct me if I'm wrong, but this approach allows for self-signed

certificates

too, right?

Exactly! Client and server can use whatever certificate they like or make a
self-signed one. All they need to do is to exchange their fingerprints over
some trustworthy channel.

Simple. Like SSH.


for the record: this is not entirely the same as SSH. What happens when 
establishing an SSH connection to a new server is that you send the 
*public key* to the server, not a hash; similarly the server sends its 
public key to the client. The client needs to accept this new key, 
otherwise the connection is aborted. For public/priv authentication to 
work, the server must know the public key of the client (listed in the 
authorized_keys file) , otherwise the user is prompted for a password. 
Thus, for SSH a 'trustworthy channel' consists of the user typing 'y' 
when connecting to a new server and the server accepting a 
username+password upon first connection from a client.


To implement a similar feature in OpenVPN would require a way to send 
only the public key upon TLS initialisation, and these public keys would 
then need to be stored/listed on the server somewhere. Probably 
possible, but a different approach then to what is proposed above. I'd 
be (slightly) in favour of sending public keys instead of hashes, BTW, 
as it them more closely mimicks what SSH does.


JM2CW,

JJK


--
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] [PATCH] Support fingerprint authentication

[Jan Just Keijser]

Hi Arne,

On 23/05/18 16:46, Arne Schwabe wrote:

I have some strong thoughts on this, mostly related to:  can someone
explain to me why this is safe?

I've seen that OpenSSH 7.7 now implements something similar (xmss
hash-based signatures,
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12,
disabled by default) but that works entirely differently from what is
proposed here; amongst other things, it uses *one time private keys* to
maximize security - do we want to add something like that to our TLS
stuff (my gut answer: no).

How can a hash replace a public key, cryptographically speaking? if you
are not replacing public keys, then who generates, stores, maintains
these public keys?  What about accounting in such a setup? with
certificates, you normally hand out a certificate to a person, with the
name of the person/entity in it. If that person misbehaves, you revoke
the certificate and presto. Is it sufficient to remove the hash from the
config? if so, wouldn't it be better to have a directory with
hash-files, so that you can add and remove hashes without having to
update the server config and/or restart the server to pick up new hashes?


When you sign a certificate you are actually singing the hash of the
certificate. So you essentially are saying: "This certificate with the
hash xxxyyy is trusted by my CA". Traditionally we used the MD5 of the
certificate, then SHA1 and now SHA256 which we signed. (See the weak md5
discussion).

The reason that the hash is signed instead of the public is that this
way you are also signing the other properties of the certificate (e.g.
CN, extensions, etc.). If you can the public key (or any other property
of the certificate) also the hash of the certificate changes.

If you just have a list of hashes that you trust you just cut out the
middle man (the CA) that establishes the trust relationship for you.


I understand that part - it's how certificate pinning etc work. However, 
for a "regular" TLS connection (or any assymmetric encryprion scheme) 
you normally need a public key and a private key in order to establish a 
connection. However, with certificate pinning all you do is *ADD* an 
extra check, not replace a check. You will need and use both the public 
and the private key to establish security. How is this done in the 
proposed patch?


JJK


--
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] [PATCH] Support fingerprint authentication

[Jan Just Keijser]

Hi Steffan,

On 17/05/18 20:31, Steffan Karger wrote:

Hi Jason,

[ Dumping my thoughts so this doesn't remain completely unanswered for
even longer. ]

On 17-04-18 18:50, Jason A. Donenfeld wrote:

OpenVPN traditionally works around CAs. However many TLS-based protocols also
allow an alternative simpler mode in which rather than verify certificates
against CAs, the certificate itself is hashed and compared against a
pre-known set of acceptable hashes. This is usually referred to as
"fingerprint verification". It's popular across SMTP servers, IRC servers,
XMPP servers, and even in the context of HTTP with pinning.

So, I'd like to propose an extremely simple and non-invasive way of
supporting this in OpenVPN, by re-using several features that already
basically support it. Namely, what I propose is:

* Allow specifying 'none' to the --ca parameter, to specify that
  certificates should not be checked against a CA. Note that 'none'
  is already used in other similar options as a special placeholder.

* When '--ca none' is in use, --verify-hash checks all depths instead
  of just level 1.

With these very simple changes, fingerprint authentication is easily achieved
via the --tls-verify script on the server and via --verify-hash on the client.

Adding support for fingerprint authentication sounds like a good idea to
me.  Even if it was just to simplify config for peer-to-peer and small
(home) setups by getting rid of the need to create and maintain a CA.
So: feature Ack.

However, if we were to add this, I think I'd rather make it a
first-class citizen.  For example by adding a peer fingerprint
verification option that works in both client and server configs, and is
mutually exclusive with --ca.  I'd expect such an option to accept an
(inline-able) file that contains a list of fingerprints, so one can make
a config like:


AA:BB:CC:DD:..
AA:BB:CC:DE:..


Or maybe base64 fingerprints, because a lot of people have been trained
by SSH to recognize short base64 strings as fingerprints.

Anyone else from the community that has some thoughts on this?

As for implementation:  I'm already having problems getting to my review
queue, so am not promising to implement this.  I would definitely put a
patch for this on my review queue though :)


I have some strong thoughts on this, mostly related to:  can someone 
explain to me why this is safe?


I've seen that OpenSSH 7.7 now implements something similar (xmss 
hash-based signatures, 
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12, 
disabled by default) but that works entirely differently from what is 
proposed here; amongst other things, it uses *one time private keys* to 
maximize security - do we want to add something like that to our TLS 
stuff (my gut answer: no).


How can a hash replace a public key, cryptographically speaking? if you 
are not replacing public keys, then who generates, stores, maintains 
these public keys?  What about accounting in such a setup? with 
certificates, you normally hand out a certificate to a person, with the 
name of the person/entity in it. If that person misbehaves, you revoke 
the certificate and presto. Is it sufficient to remove the hash from the 
config? if so, wouldn't it be better to have a directory with 
hash-files, so that you can add and remove hashes without having to 
update the server config and/or restart the server to pick up new hashes?


JM2CW,

JJK


--
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] Minimum Linux Version for OpenVPN 2.4.x

[Jan Just Keijser]

Hi,


On 22/05/18 22:47, Gert Doering wrote:

On Tue, May 22, 2018 at 09:10:10PM +0200, David Sommerseth wrote:

On 22/05/18 19:32, Marvin wrote:

Can someone tell me the minimum Linux version that OpenVPN 2.4.x will build
and run on?  We have an older appliance the runs on an older 2.4.31 kernel
(cannot be upgraded -- but it's very hardened so really doesn't need to be for
our use.)


But I do know there has been some
code changes over the years which is strictly 2.6 kernel and newer; but its
quite a long time ago so I don't recall exactly what and when.

For OpenVPN 2.4, I think we kicked out some old method to set up Linux
tunnels.  OTOH, that was 2.2.x stuff, if I remember correctly...
(86e2fa5597fd1ad8e010)



as usual, Gert is right ...
I've  dusted off and fired up a really ancient VM running CentOS 3.9, 
which is based on kernel 2.4.21. After falling off my chair in amazement 
and climbing back on, I then copied over openssl 1.0.2, lzo-2.03 and 
openvpn 2.4.5; openssl builds, as does lzo. As Gert predicted:

OpenVPN 2.4.5 fails to build on tun.c , line 2092: 'TUNSETGROUP' undeclared.

I then copied over openvpn 2.3.18 and built that: it builds and runs 
just fine.
So in short: openvpn 2.3.X is the last version that can be run on a 2.4 
kernel.


Now stop and think about this:
- WHY?!?!?!?!!? would you want to do this?
- as others have said, the 2.4 kernel series is no longer updated , and 
2.4.31 is not even the last version (that's 2.4.37). I would not  
consider any device running a 2.4 kernel secure enough to run a secure 
VPN on it, especially over the internet.
- why do would you need openvpn 2.4.x in the first place for such a 
device?  if it's AES-GCM that you are looking for then there's a good 
chance that  it will be SLOWER on embedded hardware compared to 
AES-256-CBC+SHA256.



JM2CW,

JJK

--
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] Does the OpenVPN protocol itself handle windowing?

[Jan Just Keijser]

Hi Derek,

On 04/05/18 18:02, Derek Zimmer wrote:
Based on the feedback we've gotten so far. I think we need to get some 
hard data on the latency scaling to confirm my earlier observations.



how do you simulate latency? or do you actually have high latency machines?
try playing with
  --sndbuf 0 --rcvbuf 0 --tcp-queue-limit 1

esp in TCP mode - that has helped me sometimes over a long distance link

It is interesting that AES-NI appears to dramatically improve 
performance, as none of the x86 CPUs mentioned in the gigabit 
optimization guide should be anywhere near saturation when doing it in 
software, so the hardware boost is curious as the tunnels are not CPU 
limited to begin with. ( I am aware that the operations are single 
threaded for CBC, which made up the majority of my testing. )


I'll come back with some hard numbers in a week or so, and we can 
analyze what might be going on. If there's a bottleneck somewhere that 
we might be able to eliminate, we could have some opportunities.


To test:
Two 10gig servers at various latencies for throughput tests. iperf vs 
no encryption vs typical tun configuration vs optimized tun 
configuration. Wireshark with throughput analysis. Also check cpu 
utilization and hardware acceleration on/off.


Two 10gig servers operating at 1gb, to test for driver / other 
optimizations explaining the performance differences.


While i'm hammering away at this, are there any other tests with this 
hardware/network that we might find interesting?


Record the specs of both machines carefully, including OS versions and 
OpenSSL versions


also, it'd be interesting to see a more realistic test, e.g. from an 
OpenVPN client to a machine on the LAN/network *behind* the OpenVPN 
server - so the OpenVPN server needs to actually route the traffic.


Also, it'd be interesting to see the effect of virtualization on this, 
and/or any spectre/meltdown patches that are present.
As a final test: test the performance of IPv6 over the link vs IPv4 over 
the link; I've seen a degradation of ~10% but I was expecting something 
of 2% or less.


cheers,

JJK


On Fri, May 4, 2018 at 10:45 AM, Jan Just Keijser <mailto:janj...@nikhef.nl>> wrote:


Hi,

see some comments inline

On 04/05/18 16:41, Derek Zimmer wrote:

Hello everyone,

Derek from OSTIF here. I've been working with OpenVPN for a
few years and there's a few curious performance anomalies that
i've ran into that add up to a possible performance
opportunity. My experience lies closer to networking protocols
and cryptography rather than programming, so i'd need some
help confirming my suspicions to see if this is an opportunity
for us.

I've been having some discussions with Mattock related to
performance, specifically the way that OpenVPN performance
scales on fast networks.

The interesting symptoms:
-OpenVPN performance appears to decrease linearly with
increases in latency.

I have not seen that , but then again, I have not played with
increases in latency either.

-OpenVPN performance seems consistent regardless of the OS of
the client/server.

on Linux-like OSes, yes; Windows and Mac OS don't perform nearly
as well.

-OpenVPN performance seems to adjust/scale with the speed of
the client/server, but always seems limited to roughly 25% of
the line speed of the fastest device when you scale up to
fiber speeds. The interesting part is that 1Gb servers will
top out around 220-275Mbit, and 10Gb servers will top out
around 2.5Gbit.

that depends. Read up on
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
<https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux>

and you will find that with the right settings and CPUs you can
get upto 900 Mbps over a gigabit link using MTU=1500. It all boils
down to high clockspeed CPUs and using AES-GCM suites.


-OpenVPN performance increases when you manually increase the
size of the packets to oversized (MTU 9000+).

yes, but in practice this does not help you much, unless ALL
traffic in your network is run on MTU >= 9000

-Performance is similar between TCP/UDP barring confounding
issues like packet loss.

I've seen this also


What conclusions can we draw from this?

My main conclusion has always been that OpenVPN is limited by the
number of user-to-kernel space transitions , not by anything else.

My network experience points to something going awry with
windowing with TCP, but UDP does not apply any sort of
windowing (no ACKs = no windowing) but the OpenVPN protocol
itself does have an ACK system, which suggests that OpenVPN
may apply its own windo

Re: [Openvpn-devel] Does the OpenVPN protocol itself handle windowing?

[Jan Just Keijser]

Hi,

see some comments inline

On 04/05/18 16:41, Derek Zimmer wrote:

Hello everyone,

Derek from OSTIF here. I've been working with OpenVPN for a few years and there's a few curious performance anomalies that 
i've ran into that add up to a possible performance opportunity. My experience lies closer to networking protocols and 
cryptography rather than programming, so i'd need some help confirming my suspicions to see if this is an opportunity for us.


I've been having some discussions with Mattock related to performance, specifically the way that OpenVPN performance scales on 
fast networks.


The interesting symptoms:
-OpenVPN performance appears to decrease linearly with increases in latency.

I have not seen that , but then again, I have not played with increases in 
latency either.

-OpenVPN performance seems consistent regardless of the OS of the client/server.

on Linux-like OSes, yes; Windows and Mac OS don't perform nearly as well.
-OpenVPN performance seems to adjust/scale with the speed of the client/server, but always seems limited to roughly 25% of the 
line speed of the fastest device when you scale up to fiber speeds. The interesting part is that 1Gb servers will top out 
around 220-275Mbit, and 10Gb servers will top out around 2.5Gbit.

that depends. Read up on
  https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux

and you will find that with the right settings and CPUs you can get upto 900 Mbps over a gigabit link using MTU=1500. It all 
boils down to high clockspeed CPUs and using AES-GCM suites.




-OpenVPN performance increases when you manually increase the size of the 
packets to oversized (MTU 9000+).

yes, but in practice this does not help you much, unless ALL traffic in your 
network is run on MTU >= 9000


-Performance is similar between TCP/UDP barring confounding issues like packet 
loss.

I've seen this also


What conclusions can we draw from this?


My main conclusion has always been that OpenVPN is limited by the number of 
user-to-kernel space transitions , not by anything else.

My network experience points to something going awry with windowing with TCP, but UDP does not apply any sort of windowing (no 
ACKs = no windowing) but the OpenVPN protocol itself does have an ACK system, which suggests that OpenVPN may apply its own 
windowing.

In interesting thing to test as well, is to set
  sndbuf 0
  rcvbuf 0

this should/will cause the *OS* to do Window scaling, so you can rule out any window scaling issues after that. In my 
experience, setting sndbuf=rcvbuf=0 *sometimes* helps.


From my network brain: These 4 factors all point to the same problem with regular TCP networks, not enough packets are 
"allowed" to be in flight by the protocol. This is why performance scales linearly with distance/latency. The maximum number 
of packets in flight gets reached, and the client/server then waits to send more or throttles back the rate to hit the target 
number of packets per second based on the latency (how this is done depends on how windowing is implemented). This is also why 
making the packets larger increases performance. The OpenVPN protocol allows more packets to be in flight indirectly, because 
a 9000 bit packet is broken down into 1500 bit packets by the network protocol outside of OpenVPN, so it sees fewer "packets 
in flight" at the OpenVPN level.


I'm also hesitant to blame issues like task-switching as the primary cause of the issue because of the behavior being OS 
agnostic, and 10Gb connections being able to move 2.5Gbit/sec.


This problem only seems to surface with high latency connections, or 
particularly fast networks (over 1Gb),

Let me know if i'm drawing the wrong conclusions from the evidence here. I think we may have a performance opportunity if we 
hack away at this issue and come to a greater understanding of why OpenVPN behaves this way in these cases. I'm also willing 
to do some Wireshark work to see how OpenVPN behaves in these edge cases if we think it would be valuable.


Increasing performance for long-distance VPNs, and being able to accommodate users in a fiber-to-the-home world would be a 
huge benefit for all OpenVPN users.





thanks for your research, it's great to see someone else is interested in 
high-speed VPNs also :)

cheers,

JJK


--
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] Viscosity patch to TAP driver

[Jan Just Keijser]

Hi,

On 12/04/18 16:50, Gert Doering wrote:

Hi,

On Thu, Apr 12, 2018 at 10:27:08AM -0400, Selva Nair wrote:

This change was made not because of any actual performance gains, but
because of user reports that certain firewall or AV software tries to
QoS the adapter based on its reported adapter speed, which is of course
a problem if the VPN connection is capable of more than 100 Mbit.

[..]

Or am I mistaken -- does this setting really affect the max throughput?

Not normally, but when certain 'helpful' software is around...



as a side note: there is one thing to keep in mind when changing this:
Windows calculates its automatic routing metrics based on the adapter 
speed. So if we increase the speed then there are scenarios possible 
where the tun adapter route will take precedence over a lan route : in 
most cases that is what a user would want, but there are (rare) 
scenarios where that could have nasty side effects (including the 
"biting your own tail" problem)


JM2CW,

JJK


--
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] aes-gcm and iperf on Windows

[Jan Just Keijser]

Hi,

(renamed the topic to reflect what it's about)

On 27/03/18 01:09, fragmentux wrote:

I am not convinced 'iperf -r' is reliable (bold claim maybe .. )

iperf3 have dropped -r in favour of -R "reverse mode"
server sends and client receives. but not both on the same run ..

After numerous hangs and some bazaar results with iperf2
i opted to upgrade to iperf3 .. still some slightly odd results
but no hangs so far ..


I've measured it with 'iperf -s' on Win7 and get the same results.
Important difference: with the Cygwin version of iperf I get a 240 Mbps 
/ 50 Mbps

With the Win32 version (v2.0.8) i get 330 / 100 Mbps (plus or minus 5 %)

The asymmetry is caused by the hardware used - if I use two Linux 
servers I also see asymmetry, as I am pushing the CPU of one of the 
Linux boxen a bit. The difference of my laptop running Linux vs running 
Win 7 is quite huge, however: on Linux I am getting well above 600 Mbps 
both ways.


cheers,

JJK


--
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] Summary of the community meeting (Wed, 21st Mar 2018)

[Jan Just Keijser]

Hi Selva,

On 22/03/18 18:12, Selva Nair wrote:

On Thu, Mar 22, 2018 at 12:16 PM, Jan Just Keijser  wrote:

Hi Eric, all,

On 22/03/18 04:25, Eric Thorpe wrote:

Hi All,

One of the Viscosity developers here. The TAP driver used by Viscosity is
based on the OpenVPN TAP-Windows driver. We're surprised to hear of any
performance differences, as the changes we've made are very minimal.

Besides a name and version number change, the only other modification is a
change to the reported network adapter speed, which has Windows report the
driver as 1000 Mbit instead of 100 Mbit.

This change was made not because of any actual performance gains, but
because of user reports that certain firewall or AV software tries to QoS
the adapter based on its reported adapter speed, which is of course a
problem if the VPN connection is capable of more than 100 Mbit.

Please find a patch file of the changes attached.


first of all, thanks for responding so quickly.
I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 based)
compared to OpenVPN 2.4.5 and I am seeing a performance difference in a
gigabit test setup.  Strangely enough, it turns out that it's the *absence
of* AES256-GCM that makes my Viscosity client faster.
My test setup is as follows:

- server: CentOS 7, openvpn 2.4.4, gigabit ethernet
- client: Win7 Pro, gigabit ethernet:

Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):

viscosity:
380 Mbps +/- 10 Mbps to server
100 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
377 Mbps +/- 10 Mbps to server
   99 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5 (aes256-gcm)
  240 Mbps +/- 8 Mbps to server
   55 Mbps +/- 5 Mpbs from server

So strangely enough it seems that AES-256-GCM is **slower** for Windows
clients. Note that in this setup the server config never changed.

I haven't tested openvpn itself but have noticed in openssl speed
tests that AES-256-CBC is significantly faster than AES-256-GCM on
Windows (opposite to Linux). That was with openssl 1.0.x, probably
1.1.0 is similar (2.4.5 Windows release is built with 1.1.0).

However, the raw cipher speeds are much larger than these throughputs
so its surprising that the change of cipher alone makes such a
difference.

Why is the throughput so asymmetric?


thanks for the confirmation; as for the assymmetry: that can be due to 
many factors, including hardware differences (there is asymmetry on 
Linux as well). It could also be due to the way the tap driver works, 
but I have never been able to get my finger on that , and I don't use 
Windows often enough to bother.


HTH,

JJK


--
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] Summary of the community meeting (Wed, 21st Mar 2018)

[Jan Just Keijser]

Hi Eric, all,

On 22/03/18 04:25, Eric Thorpe wrote:


Hi All,

One of the Viscosity developers here. The TAP driver used by Viscosity 
is based on the OpenVPN TAP-Windows driver. We're surprised to hear of 
any performance differences, as the changes we've made are very minimal.


Besides a name and version number change, the only other modification 
is a change to the reported network adapter speed, which has Windows 
report the driver as 1000 Mbit instead of 100 Mbit.


This change was made not because of any actual performance gains, but 
because of user reports that certain firewall or AV software tries to 
QoS the adapter based on its reported adapter speed, which is of 
course a problem if the VPN connection is capable of more than 100 Mbit.


Please find a patch file of the changes attached.



first of all, thanks for responding so quickly.
I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 
based) compared to OpenVPN 2.4.5 and I am seeing a performance 
difference in a gigabit test setup.  Strangely enough, it turns out that 
it's the *absence of* AES256-GCM that makes my Viscosity client faster.

My test setup is as follows:

- server: CentOS 7, openvpn 2.4.4, gigabit ethernet
- client: Win7 Pro, gigabit ethernet:

Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):

viscosity:
380 Mbps +/- 10 Mbps to server
100 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
377 Mbps +/- 10 Mbps to server
99 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5 (aes256-gcm)
 240 Mbps +/- 8 Mbps to server
  55 Mbps +/- 5 Mpbs from server

So strangely enough it seems that AES-256-GCM is **slower** for Windows 
clients. Note that in this setup the server config never changed.


I hope someone else can verify these results (or refute them and tell me 
what I am doing wrong ;))


HTH,

JJK


On 21/03/2018 10:45 PM, Samuli Seppänen wrote:

Hi,

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

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 21st Mar 2018
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:



The next meeting has not been scheduled yet.

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



SUMMARY

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

--

Janjust initialized the meeting with virtual group hug.

--

Discussed the security issue in tap-windows6 reported to the security
mailing list. While the issue is not critical it needs to be fixed.
Mattock will produce an installer with the fix. Cron2 will compare
unfixed and fixed versions to verify that the problem is gone. Dazo will
get us a CVE for the problem. Once this is done we will release new
Windows installers for OpenVPN 2.4.5.

--

Discussed "multi-port/multi-ip listening support: config format". The
format agreed upon in the meeting was this:

   local IP [port] [proto]

Where IP can be an IPv4 address, and IPv6 address, or * which means
dual-stack IPv4/IPv6. Proto can be either udp or tcp; the udp6 and tcp6
variants are not needed as they can be deduced from the IP address.

Note that on OpenBSD "local *" will bind to IPv6 addresses only. This is
because v4-mapped v6 sockets are not available on that platform.

--

Discussed Viscosity's patches to OpenVPN and their tap-windows adapter.
According to janjust Viscosity's tap-windows6 adapter performs
significantly better than our tap-windows6 adapter. Agreed that we
should first verify that they're using tap-windows6 and not something
they wrote themselves. If yes, we should check if their source code is
available. And if not, we should ask them to publish it according
GPLv2's requirements.

Janjust will do more testing with Viscosity's driver and report the
results to mattock who will start bugging Viscosity as necessary.

--

Discussed the "netlink support: quick roadmap recap" topic. Previously
we have agreed on providing unit tests to check the output of netlink
with what is expected from using ip/route/ifconfig. Agreed that we
should have unit tests in place at merge time. Otherwise we fear the
unit tests will never arrive.

Also agreed that we should try to provide testing Debian/Ubuntu package
for this. While that is doable right now, it requires manual work. It
would thus make more sense to automate the package creation process.

--

Dazo informed that OpenVPN 3 developers will start using openvpn-devel
for their patches. We will need to figure out how to make patchwork
detech whether a patch belongs to openvpn2 or openvpn3.

---

Full chatlog attached.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot


___
Openvpn-devel mailin

Re: [Openvpn-devel] [Openvpn-users] "Reconnect" button in openvpn-gui

[Jan Just Keijser]

Hi,

On 08/02/18 09:15, Samuli Seppänen wrote:

Il 07/02/2018 21:58, David Sommerseth ha scritto:

On 07/02/18 20:32, Илья Шипицин wrote:

After auth-token were introduced, when user press "Reconnect", it leads to
auth fail (saved password is forgotten), we run about 1000 users, nobody
complains.

This is actually expected, I'd say - but smells like a bug on the server side
authentication.

Selva may correct me if I'm wrong, but my understanding of it when clicking
"Reconnect", the local OpenVPN process which caches the auth-token is stopped
and a new OpenVPN process is started.  The client should in this case ask for
username/password again.  So in this case, the server side should treat this
connection as a fresh connection with no initial state.

The step of stopping the local client and starting a new and fresh one is
definitely not a bad feature to have on clients.


It looks like nobody uses that button.

So, I asked several users, they confirmed they do not use Reconnect.

This is no good argument for me.  This is one specific setup with 1000 users.
It would be more valuable with 50 different setups having 20 users each.  Your
conclusion is based on a very homogeneous environment.

I agree. I also agree that the underlying problem should be fixed.

That said, Ilya's message was sent to both openvpn-users and
openvpn-devel and nobody has screamed "do not remove the Reconnect
button" :). The only additional thing we can do is post a message to the
forums. As usual, the only sure way to get feedback (read: complaints)
is to release the changes in an official build/installer.

I won't be screaming "Don't remove that button" as I don't use OpenVPN 
on Windows that often, but I __DO__ find that button to be quite handy 
in the Windows GUI. I remember writing an OpenVPN book where I had to 
test and debug an OpenVPN setup on Windows and I found myself hitting 
that 'reconnect' button over and over. Of course, this was (probably?) 
all before auth tokens and I certainly did not use things like one-time 
passwords, but removing that button would have made the GUI much more 
annoying to me.


JM2CW,

JJK


--
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] [PATCH v3] Use lowest metric interface when multiple interfaces match a route

[Jan Just Keijser]

Hi,

On 26/01/18 16:26, Selva Nair wrote:

On Fri, Jan 26, 2018 at 10:20 AM, Jan Just Keijser  wrote:


On 26-Jan-18 16:08, Selva Nair wrote:


arrrgh, the important line is missing:
   ERROR: Windows route add ipv6 command failed: returned error code 1

Gert has explained the fe80::8 magic.

Here is my guess about the ERROR: The route already existed and so
errored trying to add again -- most likely from a previous run as it
seems we have a problem in deleting the route on exit (I guess this is
on Windows 10) (see Trac 1003:
https://community.openvpn.net/openvpn/ticket/1003 )

"netsh int ipv6 show route" will confirm that.

The route destinations have their host bits zeroed out before setting
route, but those bits reappear (which is strange)  in route delete.
And netsh doesnt like that at least on Windows 10. Gert, any idea why
this happens?


this is on *Windows 7*  and indeed that route is never deleted when OpenVPN
exits. Here's the error associated with *that*:

Fri Jan 26 16:13:08 2018 ERROR: Windows route delete ipv6 command failed:
returned error code 1
Fri Jan 26 16:13:09 2018 NETSH: C:\Windows\system32\netsh.exe interface ipv6
delete address vpn0 2001:610:120::200:0:1001 store=active
Fri Jan 26 16:13:09 2018 TAP: DHCP address released

C:\Users\janjust\OpenVPN\config> C:\Windows\system32\netsh.exe interface
ipv6 delete route 2001:610:120::200:0:1001/112
interface=17 fe80::8 store=active
The parameter is incorrect.

The error is due to the host part (1001) in the route destination --
changing that to
C:\Windows\system32\netsh.exe interface  ipv6 delete route
2001:610:120::200:0:/112
should succeed.

The mystery (at least for me)  is where that host part is coming
from... Its zeroed out before setting the route, and I thought the
same (?) route list pointer is passed in while deleting routes.



that also did not work; what does work is:
  C:\Windows\system32\netsh.exe interface ipv6 delete route 
2001:610:120::200:0:0/112

so indeed, the host part is added at deletion time.

HTH,

JJK


--
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] [PATCH v3] Use lowest metric interface when multiple interfaces match a route

[Jan Just Keijser]

Hi Selva,



On 26-Jan-18 16:08, Selva Nair wrote:

On Fri, Jan 26, 2018 at 8:23 AM, Jan Just Keijser  wrote:

On 26/01/18 14:11, Jan Just Keijser wrote:

the patch works as expected but I did notice something in the openvpn log
:

Fri Jan 26 14:08:09 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Fri Jan 26 14:08:10 2018 NETSH: C:\Windows\system32\netsh.exe interface
ipv6 set address interface=17 2001:610:120::200:0:1001 store=active
Fri Jan 26 14:08:10 2018 add_route_ipv6(2001:610:120::200:0:0/112 ->
2001:610:120::200:0:1001 metric 0) dev vpn0
Fri Jan 26 14:08:10 2018 C:\Windows\system32\netsh.exe interface ipv6 add
route 2001:610:120::200:0:0/112 interface=17 fe80::8 store=active
Fri Jan 26 14:08:10 2018 env_block: add
PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem

the route was added with the default GW of fe80::8 : should I be worried ?
Note that this also happened with the regular 2.4.4 version of OpenVPN and
also note that the TAP adapter on my Win7 laptop is named 'vpn0'


arrrgh, the important line is missing:
  ERROR: Windows route add ipv6 command failed: returned error code 1

Gert has explained the fe80::8 magic.

Here is my guess about the ERROR: The route already existed and so
errored trying to add again -- most likely from a previous run as it
seems we have a problem in deleting the route on exit (I guess this is
on Windows 10) (see Trac 1003:
https://community.openvpn.net/openvpn/ticket/1003 )

"netsh int ipv6 show route" will confirm that.

The route destinations have their host bits zeroed out before setting
route, but those bits reappear (which is strange)  in route delete.
And netsh doesnt like that at least on Windows 10. Gert, any idea why
this happens?

this is on *Windows 7*  and indeed that route is never deleted when 
OpenVPN exits. Here's the error associated with *that*:


Fri Jan 26 16:13:08 2018 ERROR: Windows route delete ipv6 command 
failed: returned error code 1
Fri Jan 26 16:13:09 2018 NETSH: C:\Windows\system32\netsh.exe interface 
ipv6 delete address vpn0 2001:610:120::200:0:1001 store=active

Fri Jan 26 16:13:09 2018 TAP: DHCP address released

C:\Users\janjust\OpenVPN\config> C:\Windows\system32\netsh.exe interface 
ipv6 delete route 2001:610:120::200:0:1001/112

interface=17 fe80::8 store=active
The parameter is incorrect.


HTH,

JJK


--
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] [PATCH v3] Use lowest metric interface when multiple interfaces match a route

[Jan Just Keijser]

On 26/01/18 14:11, Jan Just Keijser wrote:

the patch works as expected but I did notice something in the openvpn log :

Fri Jan 26 14:08:09 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Fri Jan 26 14:08:10 2018 NETSH: C:\Windows\system32\netsh.exe interface ipv6 set address interface=17 2001:610:120::200:0:1001 
store=active

Fri Jan 26 14:08:10 2018 add_route_ipv6(2001:610:120::200:0:0/112 -> 
2001:610:120::200:0:1001 metric 0) dev vpn0
Fri Jan 26 14:08:10 2018 C:\Windows\system32\netsh.exe interface ipv6 add route 2001:610:120::200:0:0/112 interface=17 fe80::8 
store=active

Fri Jan 26 14:08:10 2018 env_block: add 
PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem

the route was added with the default GW of fe80::8 : should I be worried ?
Note that this also happened with the regular 2.4.4 version of OpenVPN and also note that the TAP adapter on my Win7 laptop is 
named 'vpn0'



arrrgh, the important line is missing:
 ERROR: Windows route add ipv6 command failed: returned error code 1

sorry for the noise,

JJK




--
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] [PATCH v3] Use lowest metric interface when multiple interfaces match a route

[Jan Just Keijser]

the patch works as expected but I did notice something in the openvpn log :

Fri Jan 26 14:08:09 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Fri Jan 26 14:08:10 2018 NETSH: C:\Windows\system32\netsh.exe interface 
ipv6 set address interface=17 2001:610:120::200:0:1001 store=active
Fri Jan 26 14:08:10 2018 add_route_ipv6(2001:610:120::200:0:0/112 -> 
2001:610:120::200:0:1001 metric 0) dev vpn0
Fri Jan 26 14:08:10 2018 C:\Windows\system32\netsh.exe interface ipv6 
add route 2001:610:120::200:0:0/112 interface=17 fe80::8 store=active
Fri Jan 26 14:08:10 2018 env_block: add 
PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem


the route was added with the default GW of fe80::8 : should I be worried ?
Note that this also happened with the regular 2.4.4 version of OpenVPN 
and also note that the TAP adapter on my Win7 laptop is named 'vpn0'


JJK


On 24-Jan-18 18:31, selva.n...@gmail.com wrote:

From: Selva Nair 

Currently a route addition using IPAPI or service is skipped if the
route gateway is reachable by multiple interfaces. This changes that
to use the interface with lowest metric. Implemented by

(i)  Do not over-write the return value with TUN_ADAPTER_INDEX_INVALID in
  windows_route_find_if_index() if multiple interfaces match a route.
(ii) Select the interface with lowest metric in adapter_index_of_ip()
  instead of the first one found when multiple interfaces match.

Reported by Jan Just Keijser 

Signed-off-by: Selva Nair 

---
NOTE: depends on https://patchwork.openvpn.net/patch/136/

v3: Simpliyfy the patch using get_interface_metric from block_dns.c
 Simpler is also easier to review :)
 (requires patch 136 https://patchwork.openvpn.net/patch/136/)
v2:
 - Revert an unintented edit of route.c (a_index = ...)
 - Improve the commit message

  src/openvpn/route.c |  1 -
  src/openvpn/tun.c   | 17 +++--
  2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index f121d3f..218ca96 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -2785,7 +2785,6 @@ windows_route_find_if_index(const struct route_ipv4 *r, 
const struct tuntap *tt)
  msg(M_WARN, "Warning: route gateway is ambiguous: %s (%d matches)",
  print_in_addr_t(r->gateway, 0, &gc),
  count);
-ret = TUN_ADAPTER_INDEX_INVALID;
  }
  
  dmsg(D_ROUTE_DEBUG, "DEBUG: route find if: on_tun=%d count=%d index=%d",

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 2644d99..f424f82 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -45,6 +45,7 @@
  #include "manage.h"
  #include "route.h"
  #include "win32.h"
+#include "block_dns.h"
  
  #include "memdbg.h"
  
@@ -4480,6 +4481,7 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,

  struct gc_arena gc = gc_new();
  DWORD ret = TUN_ADAPTER_INDEX_INVALID;
  in_addr_t highest_netmask = 0;
+int lowest_metric = INT_MAX;
  bool first = true;
  
  if (count)

@@ -4493,9 +4495,14 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
  
  if (is_ip_in_adapter_subnet(list, ip, &hn))

  {
+int metric = get_interface_metric(list->Index, AF_INET, NULL);
  if (first || hn > highest_netmask)
  {
  highest_netmask = hn;
+if (metric >= 0)
+{
+lowest_metric = metric;
+}
  if (count)
  {
  *count = 1;
@@ -4509,16 +4516,22 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
  {
  ++*count;
  }
+if (metric >= 0 && metric < lowest_metric)
+{
+ret = list->Index;
+lowest_metric = metric;
+}
  }
  }
  list = list->Next;
  }
  
-dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d",

+dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d 
metric=%d",
   print_in_addr_t(ip, 0, &gc),
   print_in_addr_t(highest_netmask, 0, &gc),
   (int)ret,
- count ? *count : -1);
+ count ? *count : -1,
+ lowest_metric);
  
  if (ret == TUN_ADAPTER_INDEX_INVALID && count)

  {



--
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] [PATCH v3] Use lowest metric interface when multiple interfaces match a route

[Jan Just Keijser]

Works as expected.
Tested-by: Jan Just Keijser 



On 24/01/18 18:31, selva.n...@gmail.com wrote:

From: Selva Nair 

Currently a route addition using IPAPI or service is skipped if the
route gateway is reachable by multiple interfaces. This changes that
to use the interface with lowest metric. Implemented by

(i)  Do not over-write the return value with TUN_ADAPTER_INDEX_INVALID in
  windows_route_find_if_index() if multiple interfaces match a route.
(ii) Select the interface with lowest metric in adapter_index_of_ip()
  instead of the first one found when multiple interfaces match.

Reported by Jan Just Keijser 

Signed-off-by: Selva Nair 

---
NOTE: depends on https://patchwork.openvpn.net/patch/136/

v3: Simpliyfy the patch using get_interface_metric from block_dns.c
 Simpler is also easier to review :)
 (requires patch 136 https://patchwork.openvpn.net/patch/136/)
v2:
 - Revert an unintented edit of route.c (a_index = ...)
 - Improve the commit message

  src/openvpn/route.c |  1 -
  src/openvpn/tun.c   | 17 +++--
  2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index f121d3f..218ca96 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -2785,7 +2785,6 @@ windows_route_find_if_index(const struct route_ipv4 *r, 
const struct tuntap *tt)
  msg(M_WARN, "Warning: route gateway is ambiguous: %s (%d matches)",
  print_in_addr_t(r->gateway, 0, &gc),
  count);
-ret = TUN_ADAPTER_INDEX_INVALID;
  }
  
  dmsg(D_ROUTE_DEBUG, "DEBUG: route find if: on_tun=%d count=%d index=%d",

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 2644d99..f424f82 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -45,6 +45,7 @@
  #include "manage.h"
  #include "route.h"
  #include "win32.h"
+#include "block_dns.h"
  
  #include "memdbg.h"
  
@@ -4480,6 +4481,7 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,

  struct gc_arena gc = gc_new();
  DWORD ret = TUN_ADAPTER_INDEX_INVALID;
  in_addr_t highest_netmask = 0;
+int lowest_metric = INT_MAX;
  bool first = true;
  
  if (count)

@@ -4493,9 +4495,14 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
  
  if (is_ip_in_adapter_subnet(list, ip, &hn))

  {
+int metric = get_interface_metric(list->Index, AF_INET, NULL);
  if (first || hn > highest_netmask)
  {
  highest_netmask = hn;
+if (metric >= 0)
+{
+lowest_metric = metric;
+}
  if (count)
  {
  *count = 1;
@@ -4509,16 +4516,22 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
  {
  ++*count;
  }
+if (metric >= 0 && metric < lowest_metric)
+{
+ret = list->Index;
+lowest_metric = metric;
+}
  }
  }
  list = list->Next;
  }
  
-dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d",

+dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d 
metric=%d",
   print_in_addr_t(ip, 0, &gc),
   print_in_addr_t(highest_netmask, 0, &gc),
   (int)ret,
- count ? *count : -1);
+ count ? *count : -1,
+ lowest_metric);
  
  if (ret == TUN_ADAPTER_INDEX_INVALID && count)

  {



--
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] OVPN vs IPSec performance as a transport

[Jan Just Keijser]

On 05/01/18 00:52, Tom Kunz wrote:

That would explain it if it always worked that way.
But I can get 400%+ wire speed from A to B with compressible data, and 
102% with incompressible data.  If I do the same test from B to A or A 
to B, I get those results.  If I hop off of that to C, speed goes from 
>1Gbps to sub-200Mbps.  In either case, the data has left the kernel 
space to arrive at "nc", so just simply saying "it's kernel vs user" 
doesn't answer it.



actually, it does answer it: I've ran similar tests a few years back and 
got similar results. See

https://homepages.staff.os3.nl/~delaat/rp/2010-2011/p09/report.pdf

for the report.
 Here's what happens:

if you run nc on the VPN endpoints themselves, then the OS can make use 
of the fact that the tun MTU is set to a very high value - thus you can 
easily achieve line speeds. However, as soon as you try to reach a 
machine beyond either VPN endpoint, then all traffic is fragmented to 
the MTU of the LAN , so normally that's 1500, possibly 6000.  On your 
host C, all packets are chopped into 1500 bytes fragments (payload = 
1472 bytes) and *THESE* packets are received by the OpenVPN endpoint, 
then compressed, encrypted, possibly fragmented and sent to the remove 
end. The tun MTU is never reached in this case, as each packet is 
handled separately.
So yes, OpenVPN *IS* capped by the number of kernel-to-userspace 
transitions. On a high clockspeed CPU (e.g. i5-6000 series or higher 
with high turbo speed) you can achieve close to line speed, although I 
have yet to find out what MELTDOWN and the fix for it will to do the 
maximum speeds.


As IPsec runs in kernel space, it does not suffer from the large number 
of transitions and it can thus achieve higher speeds going from A-B->C


Hope this clarifies things,

JJK



On 01/04/2018 06:37 PM, Greg Sloop  wrote:
I'm sure someone else, or a Google search will get you a more 
detailed run-down - but the gist of the "problem" is this;


OpenVPN is run in user-space, not kernel space. IPSec  runs in kernel 
space, and the difference is vastly diminished throughput.


HTH

-Greg

On Jan 4, 2018 3:23 PM, "Tom Kunz" > wrote:


Hi,

I have been testing OVPN 2.4.4 vs StrongSwan IPSec, to be used as
transport, and I have found something that I think might be a
performance issue.  I have 3 linux boxes, A, B, and C. All interfaces
are 1Gbps.  Each has an interface to the next one downstream:

A - eth0=10.10.10.10/24  and
eth1=172.16.0.10/24 

B - eth0=172.16.0.11/24  and
eth1=172.30.0.11/24 

C - eth0=172.30.0.10/24  and
eth1=192.168.168.10/24 

Packets route as usual through this with no encryption, and
throughput
from A to C is at wire speed.  With IPSec between A&B, from
172.16.0.10-172.16.0.11, I can still get wire speed from A to C. 
Then I

turn off IPSec, and I setup A as the server and B as the client, with
A's config being:

=

dev tun

topology subnet
server 172.17.0.0 255.255.255.0
port 1194
proto udp
dh /etc/openvpn/keys/dh2048.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
verb 3
keepalive 10 45
cipher aes-256-cbc
comp-lzo

tun-mtu 5

mssfix 0

fragment 0

client-config-dir ccd

push "route 10.10.10.0 255.255.255.0"

=

and the client B config file is

=

verb 3
client
cipher AES-256-CBC
comp-lzo
tun-mtu 5
mssfix 0
fragment 0
remote 172.16.0.10  1194

dev tun
redirect-private local
tls-client

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key

=

and I setup static routes on each side so that traffic is going
through
the tunnel from A to C and vice versa.

I can pass traffic over this link, however when I do tests for
speed, I
am only getting about 200Mbps instead of 1Gbps.

The funny thing is, I know that each of these machines can easily do
1Gbps.  If I do my performance test from A to B, over the above ovpn
configs, I can get just over 1Gbps because of the MTU overhead being
removed. But as soon as I have it make the leap downstream once
more, I
lose 80+% of the speed.  And again, both non-encrypted traffic
and IPSec
do the exact same test at wire speed or just slightly under wire
speed.

The way I do a speed test is on A:

# nc -l -p  > /dev/null

and over on C:

# dd if=/dev/urandom of=blob.random.1G bs=10M count=100

# time cat blob.random.1G | nc 10.10.10.10 

tcpdumps over each interface confirm traffic is flowing in the
expected
fashion.

Over unencrypted or IPSec, I am loo

Re: [Openvpn-devel] [PATCH] Implement "status 4" (JSON) for management interface

[Jan Just Keijser]

On 14/11/17 09:31, Gert Doering wrote:

On Mon, Nov 13, 2017 at 01:16:46PM +0100, David Sommerseth wrote:

But we should consider if we want to make use of a JSON library
producing the JSON streams.  The reason is to ensure the output is
according to the specification and that escaping if contents is
consistent and proper.  Imagine if someone puts a double-quote into the
CN field of a certificate?

  CN="} Lets explode things, O=Hacktivist0

Or other characters which needs escaping.

I'm not convinced we want to import a new library dependency and a heap
of #ifdef for this.

Escaping on *output* is pretty trivial ("characters from 
need to be encoded ") - and as long as we do not need to parse
*incoming* JSON, a full-blown new library is mainly adding complications
(like, configure flags, #ifdefs, library version dependencies, ...).

But you knew that this response would be coming :-)



+1

JJK


--
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] Possible bug: AEAD Decrypt error: cipher final failed

[Jan Just Keijser]

hi all,

whilst testing some new hardware with OpenVPN I ran into the following messages 
which keep popping up from time to time:

 AEAD Decrypt error: cipher final failed


Config:

server running OpenVPN 2.4.3, basic config, Ubuntu 17, kernel 4.14, openssl 
1.0.2g
client running OpenVPN 2.4.4, basic config, CentOS 7.4, kernel 3.10, openssl 
1.0.2k

it's the client that is throwing the above message during heavy load (900 Mbps VPN traffic). It happens only with NCP ciphers , 
I am not seeing any cipher messages with 'ncp-disable' set.


as soon as I add 'verb 5' or higher, the message goes away, because performance 
drops to below 500 Mbps due to excessive output.
Any idea how to tackle this?

TIA,

JJK



--
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] [PATCH 0/1] add engine keys keys

[Jan Just Keijser]

Hi James,

On 30/10/17 15:09, James Bottomley wrote:

On Sun, 2017-10-29 at 17:03 -0400, Selva wrote:

On Sun, Oct 29, 2017 at 12:04 PM, James Bottomley  wrote:


On Sun, 2017-10-29 at 16:24 +0100, Gert Doering wrote:

On Sat, Oct 28, 2017 at 01:02:27PM +0100, James Bottomley wrote:


Engine keys are an openssl concept for a key file which can
only be
understood by an engine (usually because it's been wrapped by
the
engine itself).  We use this for TPM engine keys, so you can
either
generate them within your TPM or wrap them from existing
private
keys.  Once wrapped, the keys will only function in the TPM
that
generated them, so it means the VPN keys are tied to the
physical
platform, which is very useful.  Engine keys have to be loaded
via
a specific callback, so use this as a fallback in openvpn if an
engine is specified and if the PEM read of the private key
fails.

How does this work in an OpenVPN context, as in, what do I have
to do
to make TPM keys work on client and server?

If you have an existing private key, you convert it to a TPM key
using
the create_tpm[2]_key binary that comes with openssl_tpm[2]_engine.
  The key you create is then locked to the TPM of the system you
create
it on (so save an offline copy of the non-TPM private key).


Do we need a new abstraction layer here somewhere, given that
this
seems to do something similar to using the windows crypto layer
to
access "private keys hidden in windows" (--cryptoapicert) and/or
pkcs11?

I don't really think so.  The engine keys are a bit of an openssl
brainfart: there's no reason why PEM_read_bio_PrivateKey couldn't
actually check for engine keys and have the whole thing transparent
to
all applications, except that openssl didn't want to do it that
way.

These keys are real files, so they're not like tokens, which is the
pkcs11 abstraction.


That means, if one has the tpm_engine for openssl installed and
TPM-wrapped keys, this should just work, is it? And, I suppose, the
patch for openvpn is required only because openssl does not
transparently use available engines.

Yes, and no.  By the time openssl sees the load request, it has a bio,
rather than a file name, so there's a bit of additional glue openssl
would need for transparent engine support.  I proposed a patch a while
ago to the openssl list, but it required an additional engine callback
and wasn't very enthusiastically received.


If so, this looks like a easy way to provide TPM support to
openssl users on some platforms. What about Windows? Is there
an openssl TPM engine and tools to convert the key to a wrapped
TSS blob on Windows?

No idea, I'm afraid.  I would suspect not because windows isn't a great
consumer of openssl, so no-one on the windows development side probably
thought to write an openssl engine for their TPMs.


I would like to see new features transparently supported on Windows
as well without the need for too much extra code and associated
maintenance burden. Our 'cryptoapicert' implementation is already in
need of a major re-write to support TLS 1.2 and newer.

Well, windows supports engines (via dlls), so the engine code will work
for Windows, just not for my use case (their being no engine) and MS
CryptoAPI is one of the supported engines.


 From that point of view, instead of file-based wrapped keys, if a
pkcs11 compatible API can be used to access TPM (that's possible
isn't it?) TPM could be more widely usable without the need of any
additional support in openssl or openvpn.

For TPM 1.2 it is possible to load the key into the TPM and then use
the TPM as a loaded token via PKCS11 but the usual key format is file
based not already present.  For TPM 2, the design is different and the
key has to be loaded each time from offline storage (the file) because
the space in the TPM is so tiny, so treating it as a token is a bit
more difficult.  Obviously with enough pressure, even a square peg will
fit in a round hole, it's just that it won't be elegant.


I'm quite interested in using a TPM to store keys - do you have a set of instructions on how to load a key into the TPM and then 
sign data using that key?  Most of the implementations I've found using something like trousers , which does NOT encrypt data 
using the TPM itself, but uses the TPM as a master key to sign other keys with.


thx,

JJK


--
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] how to roll your own OpenVPN Windows installer

[Jan Just Keijser]

Hi all,

On 11/09/17 09:06, Samuli Seppänen wrote:

Il 08/09/2017 13:10, Jan Just Keijser ha scritto:

hi dev list,

someone asked me this question: how can one roll their own Windows OpenVPN installer, including a signed TAP driver? There's 
no need to rebuild OpenVPN or the TAP driver, but they do need to include other things, such as certificates, config files etc.

Is there a way to repackage the existing TAP driver?  are there instructions 
for that?

TIA,

JJK


Hi,

I meant to answer this earlier, but then apparently forgot. The tap-windows installer is simply embedded into the main OpenVPN 
installer, so the pre-existing, signed tap-windows6 driver can be reused as-is. An OpenVPN installer can be generated in the 
openvpn-build cross-compile environment:


<https://github.com/OpenVPN/openvpn-build>

Usage of openvpn-build is pretty well documented on Trac:

<https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem>

On this page you can find automated cross-compile environment setup scripts 
which work for Ubuntu 14.04 and 16.04:

<https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem>

It is also possible to generate a new installer without actually building anything. The challenge is that the NSI install 
script (openvpn.nsi) in openvpn-build depends on a number of variables set during the build process, and on a certain 
directory structure. So it is generally easier just to rebuild everything.



thanks all for the feedback, this is exactly what my colleague was looking for!
He's now convinced that he no longer wants to rebuild openvpn or the tap driver 
:)

cheers,

JJK



--
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] proper configuring of "tls-verify"

[Jan Just Keijser]

Hi,

On 11/09/17 13:22, Илья Шипицин wrote:

Hello,

is someone actually using "tls-verify" in production ?
we tried to implement additional certificate check using tls-verify


while it works in general, in case when it hits "exit 1", it look like a 
timeout from client point of view. it is not any good


do you mean that when a client is denied access (i.e. the tls-verify script exits 1 on the server) that the client sees this as 
a timeout?  that is "normal" behaviour, as the server does not tell the client *WHY* access is refused - it simply stop 
responding to a client that does not pass authentication/authorization. The client will not hear from the server, and will time 
out after a specified interval.  This is actually the most secure way to do things, as a rogue client cannot DoS a server this way.


HTH,

JJK


--
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] how to roll your own OpenVPN Windows installer

[Jan Just Keijser]

hi dev list,

someone asked me this question: how can one roll their own Windows 
OpenVPN installer, including a signed TAP driver?  There's no need to 
rebuild OpenVPN or the TAP driver, but they do need to include other 
things, such as certificates, config files etc.
Is there a way to repackage the existing TAP driver?  are there 
instructions for that?


TIA,

JJK


--
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] [PATCH] bash: substitute legacy `` with modern $()

[Jan Just Keijser]

Hi,

On 25/08/17 03:41, Antonio Quartulli wrote:


On 25/08/17 04:21, David Sommerseth wrote:

On 24/08/17 21:18, Gert Doering wrote:

(gen-release-tarballs.sh only needs to work on FreeBSD and Linux, and
FreeBSD's /bin/sh is sufficiently modern so so it's likely to work
  - but the test scripts need to run robustly everywhere a user builds,
so never assume "because bash says so!" is a way anywhere but into worlds
of pain.  And yes, we've been there before :-) )

And to avoid style confusions ... as long as we can avoid having "one
style" on the test scripts and "another style" on the dev-tools scripts,
that will be easier to review and maintain.

We can have more slack in dev-tools, but if we deviate, then we need to
properly document it so we won't forget why.

I also think it is a bad idea to have different styles. If we have to
agree on something, it should be valid for every file of that type.

Let's postpone this for when we'll have tested various platforms.


my biggest complaint about the so-called modern $() notation is that it 
clashes/confuses the heck out of me when using proper variable usage, 
e.g. I find

  output=`${SOME_COMMAND} ${SOME_ARGS}`
much better readable than
  output=$(${SOME_COMMAND} ${SOME_ARGS})

especially since you are allowed to **NEST** $() strings, IIRC. Things like

  output=$(${cmd} $(${cmd2}))

work, and in my view, thank god that you cannot do that using backtics ;)

JM2CW,

JJK



--
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] Windows installer with updated pkcs11-helper (1.22) available for testing

[Jan Just Keijser]

On 17/07/17 14:14, Gert Doering wrote:

Hi,

On Mon, Jul 17, 2017 at 02:10:11PM +0200, Jan Just Keijser wrote:

this problem is NOT present in OpenVPN 2.3.17; the same warning appears (route 
gateway is ambiguous) but the route is added
anyway. This seems to be a regression in 2.4.

Can we have a log, please?



attached: config and log (with hostnames anonymized)

JJK

Mon Jul 17 14:18:33 2017 us=360410 Current Parameter Settings:
Mon Jul 17 14:18:33 2017 us=360410   config = 'nikhef-udp-pkcs11.ovpn'
Mon Jul 17 14:18:33 2017 us=360410   mode = 0
Mon Jul 17 14:18:33 2017 us=360410   show_ciphers = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   show_digests = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   show_engines = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   genkey = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   key_pass_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   show_tls_ciphers = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   connect_retry_max = 0
Mon Jul 17 14:18:33 2017 us=360410 Connection profiles [0]:
Mon Jul 17 14:18:33 2017 us=360410   proto = udp
Mon Jul 17 14:18:33 2017 us=360410   local = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   local_port = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   remote = 'vpnserver'
Mon Jul 17 14:18:33 2017 us=360410   remote_port = '1194'
Mon Jul 17 14:18:33 2017 us=360410   remote_float = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   bind_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   bind_local = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   bind_ipv6_only = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   connect_retry_seconds = 5
Mon Jul 17 14:18:33 2017 us=360410   connect_timeout = 120
Mon Jul 17 14:18:33 2017 us=360410   socks_proxy_server = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   socks_proxy_port = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu = 1500
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu_defined = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   link_mtu = 1500
Mon Jul 17 14:18:33 2017 us=360410   link_mtu_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu_extra = 0
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu_extra_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   mtu_discover_type = -1
Mon Jul 17 14:18:33 2017 us=360410   fragment = 0
Mon Jul 17 14:18:33 2017 us=360410   mssfix = 1450
Mon Jul 17 14:18:33 2017 us=360410   explicit_exit_notification = 0
Mon Jul 17 14:18:33 2017 us=360410 Connection profiles END
Mon Jul 17 14:18:33 2017 us=360410   remote_random = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ipchange = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   dev = 'tun'
Mon Jul 17 14:18:33 2017 us=360410   dev_type = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   dev_node = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   lladdr = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   topology = 1
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_local = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_remote_netmask = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_noexec = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_nowarn = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_local = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_netbits = 0
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_remote = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   shaper = 0
Mon Jul 17 14:18:33 2017 us=360410   mtu_test = 0
Mon Jul 17 14:18:33 2017 us=360410   mlock = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   keepalive_ping = 0
Mon Jul 17 14:18:33 2017 us=360410   keepalive_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   inactivity_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_send_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_rec_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_rec_timeout_action = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_timer_remote = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   remap_sigusr1 = 0
Mon Jul 17 14:18:33 2017 us=360410   persist_tun = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   persist_local_ip = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   persist_remote_ip = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   persist_key = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   passtos = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   resolve_retry_seconds = 10
Mon Jul 17 14:18:33 2017 us=360410   resolve_in_advance = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   username = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   groupname = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   chroot_dir = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   cd_dir = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   writepid = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   up_script = '[UNDEF]'
Mon Jul 17 14:18:

Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

[Jan Just Keijser]

Follow-up:

this problem is NOT present in OpenVPN 2.3.17; the same warning appears (route gateway is ambiguous) but the route is added 
anyway. This seems to be a regression in 2.4.


JJK


On 17/07/17 14:01, Jan Just Keijser wrote:

Hi all,

On 17/07/17 12:34, Samuli Seppänen wrote:

On 15/07/2017 00:43, Jan Just Keijser wrote:

Hi Samuli,

On 14/07/17 16:07, Samuli Seppänen wrote:

Hi all,

Those of you who use pkcs11 on Windows: could you please test this new
Windows installer:

<http://build.openvpn.net/downloads/releases/openvpn-install-2.4.3-I602.exe>


The previous installer(s) had pkcs11-helper 1.11. This one has 1.22, so
some regression testing would be good to have.

I'd like to push the updated installer out early next week, preferably
on Monday.


nice to see that pkcs11 support is still included in the Windows
version; I can test the installer on monday morning(no Windows laptop in
my house ;))  I will let you know my findings.

cheers,

JJK


Hi JJK,

Excellent, thanks! I will push out the new installer if everything looks
good at your end.



good news and bad news:

+ the pkcs11 stuff works as expected, no problems there
- with openvpn 2.4.3 my existing setup using "redirect-gateway def1"  stopped 
working!

I'll downgrade OpenVPN to see if this problem was already there in 2.3.XX ; 
what happens is this:
- openvpn wants to add a direct route to the VPN server
- there happen to be TWO gateways to that server with the SAME IP address, one 
via wired ethernet, one via wireless
- openvpn gets confused and says "route gateway is ambiguous" and refuses to 
add it
- after that, all traffic is jammed, as there is no direct route to the VPN server itself, and thus all encrypted traffic is 
fed back into the tunnel, where it is encrypted again, etc etc ("biting your own tail").


Disconnecting either wired or wireless solves the issue AFTER restarting 
OpenVPN. Annoying.
It looks like a (minor) patch is needed to deal with this special case

cheers,

JJK


--
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



--
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] Windows installer with updated pkcs11-helper (1.22) available for testing

[Jan Just Keijser]

Hi all,

On 17/07/17 12:34, Samuli Seppänen wrote:

On 15/07/2017 00:43, Jan Just Keijser wrote:

Hi Samuli,

On 14/07/17 16:07, Samuli Seppänen wrote:

Hi all,

Those of you who use pkcs11 on Windows: could you please test this new
Windows installer:

<http://build.openvpn.net/downloads/releases/openvpn-install-2.4.3-I602.exe>


The previous installer(s) had pkcs11-helper 1.11. This one has 1.22, so
some regression testing would be good to have.

I'd like to push the updated installer out early next week, preferably
on Monday.


nice to see that pkcs11 support is still included in the Windows
version; I can test the installer on monday morning(no Windows laptop in
my house ;))  I will let you know my findings.

cheers,

JJK


Hi JJK,

Excellent, thanks! I will push out the new installer if everything looks
good at your end.



good news and bad news:

+ the pkcs11 stuff works as expected, no problems there
- with openvpn 2.4.3 my existing setup using "redirect-gateway def1"  stopped 
working!

I'll downgrade OpenVPN to see if this problem was already there in 2.3.XX ; 
what happens is this:
- openvpn wants to add a direct route to the VPN server
- there happen to be TWO gateways to that server with the SAME IP address, one 
via wired ethernet, one via wireless
- openvpn gets confused and says "route gateway is ambiguous" and refuses to 
add it
- after that, all traffic is jammed, as there is no direct route to the VPN server itself, and thus all encrypted traffic is fed 
back into the tunnel, where it is encrypted again, etc etc ("biting your own tail").


Disconnecting either wired or wireless solves the issue AFTER restarting 
OpenVPN. Annoying.
It looks like a (minor) patch is needed to deal with this special case

cheers,

JJK


--
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] Windows installer with updated pkcs11-helper (1.22) available for testing

[Jan Just Keijser]

Hi Samuli,

On 14/07/17 16:07, Samuli Seppänen wrote:

Hi all,

Those of you who use pkcs11 on Windows: could you please test this new
Windows installer:



The previous installer(s) had pkcs11-helper 1.11. This one has 1.22, so
some regression testing would be good to have.

I'd like to push the updated installer out early next week, preferably
on Monday.

nice to see that pkcs11 support is still included in the Windows 
version; I can test the installer on monday morning(no Windows laptop in 
my house ;))  I will let you know my findings.


cheers,

JJK


--
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] Bug or Feature? Username in environment in auth-user-pass-verify

[Jan Just Keijser]

Hi Gert et al,

On 15/06/17 09:47, Gert Doering wrote:

Hi,

On Thu, Jun 15, 2017 at 12:50:40PM +1000, Steven Haigh wrote:

I'm just trying to figure out if its expected behaviour to have the
'username' set in the environment when using the auth-user-pass-verify
script.

The code in question (ssl_verify.c) is older than the involvement of
any of the currently-active developers... but JJK or Ecrist might know.

Anyway, what the code *says* is:

ssl_verify.c, about line 1095:

verify_user_pass_script(...)
{
...
 /* Set environmental variables prior to calling script */
 if (session->opt->auth_user_pass_verify_script_via_file)
 {
... (no setenv here)
 }
 else
 {
 setenv_str(session->opt->es, "username", up->username);
 setenv_str(session->opt->es, "password", up->password);
 }


so, yes, that is what it *does* - "username" is only ever set together
with "password", and that's only setenv'ed if you do not use "via-file".


that's how I remember it as well:  username is setenv'ed only if you use 'via-env' ; no special reason for it, just how the flow 
of the code goes.

Now, that is about calling the --verify-auth-user-pass, but I think the
"es" (environment set) being affected here is the global per-connection
es (not something local to this function), so that would affect
--client-connect as well.

[..]

The auth-user-pass-verify documentation states:
If method is set to "via-env", OpenVPN will call script with the
environmental variables username and password set to the
username/password strings provided by the client. Be aware that this
method is insecure on some platforms which make the environment of a
process publicly visible to other unprivileged processes.

This "some platforms" actually something we should eventually verify
and clearly spell-out - because Linux and all recent BSDs do *not* show
the environment to other unprivileged users.

[..]

No mention of the username env variable when using via-file - but this
gives me the impression that the username should *not* be set in the
environment - but it should be in the file.

So - bug or feature?

Username and Password are always handled in tandem when talking about
--auth-user-pass-verify, so "both in environment" or "none of them".

Now, if you use a *plugin* (or the management interface), the code will
always set both in the es, and delete the password(!) afterwards, leaving
the username intact...


Looking from a given distance, I'd say that this is a bug, and "username"
should propably be always visible in the es (if present), while password
should not.


or one could argue that the behaviour should not change when using a plugin - 
i.e. the plugin should also unset 'username' ;)

then again, there is no harm in setting the username as an env var, so I'd go 
for the (trivial) patch.

cheers,

JJK


--
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] Upgrading EasyRSA 2's defaults

[Jan Just Keijser]

Hi David,

On 03/04/17 22:43, David Sommerseth wrote:

On 03/04/17 16:12, Jan Just Keijser wrote:


On 03/04/17 15:53, Samuli Seppänen wrote:

On 02/04/2017 10:57, Steffan Karger wrote:

Hi,

On 31-03-17 22:34, David Sommerseth wrote:

On 31/03/17 10:56, Илья Шипицин wrote:

2017-03-31 13:26 GMT+05:00 Samuli Seppänen mailto:sam...@openvpn.net>>:

  Hi,

  We still bundle EasyRSA 2 with our Windows installers and it is
  prominently advertised on our widely linked to HOWTO:

  <https://openvpn.net/index.php/open-source/documentation/howto.html
  <https://openvpn.net/index.php/open-source/documentation/howto.html>>

  As such, EasyRSA 2 is used by many/most OpenVPN server admins.

  However, the default values for EasyRSA 2 such as MD5 hashing algorithm
  and 1024-bit keysize seem totally inadequate for today's standards:

  <https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/vars#L53
  
<https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/vars#L53>>
  
<https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/openssl-1.0.0.cnf#L57
  
<https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/openssl-1.0.0.cnf#L57>>

  I think we should upgrade these to something more recent. What would
  more modern reasonable defaults be?



someday we decided to use DSA (instead of default RSA)
it worked ... until we started to use OpenVPN Connect for iOS.
next, we had to change back to RSA


the conclusion would be "test all available platforms and take a
decision", probably even set up special test server and ask people on
openvpn-users mailing list

Always a good idea to test as many platforms as possible.  But we can
also leverage all the testing which have been done indirectly by others
as well.

The suggestion from Samuli is to update the default key size and hashing
algorithm.  MD5 is broken.  MD5 have been broken for years.  SHA1 have
the recent SHAttering panic, which have its own set of challenges - and
should not be used for certificates any longer (if I have understood the
crypto-gurus correctly).

Also considering that the "world in general" have been moving towards
stronger keys *and* have moved towards SHA256 hashing in certificates,
updating EasyRSA is more than reasonable.

So, I would highly recommend using SHA256.  I have used that for my
OpenVPN setups for several years already.  That works fine for me, and I
know others have done the same.  This is actually the most challenging
move, from a technical point of view - using a new algorithm.  But this
algorithm is well supported by all OpenSSL and mbed TLS implementations
OpenVPN can be built against.

Secondly, updating the key length from 1024 bits to at least 2048 should
not cause any issues at all.  Many users (myself included) often use
4096 bits keys without any issues.

Swapping RSA for DSA is an issue of a completely different league. And
DSA is by OpenSSH considered too weak; IIRC it was even removed in
OpenSSH v7.0.

Yes, upgrading would be good if we still ship it.  I can echo David's
SHA256 / RSA2048+ recommendation.  Enough security margin, and very good
interop (not only crypto libs, but also smart cards, OS key stores,
...).  To not dramatically slow down connection setup on low-cpu-power
devices (e.g. home routers), don't go beyond RSA4096 though.

DSA is _not_ a preferred choice.  The original 1024-bit DSA is too weak
nowadays, and the 'larger' DSA variants are not even close to the wide
support that RSA has.

-Steffan


Hi,

I've issue a pull request here and review would be appreciated:

<https://github.com/OpenVPN/easy-rsa-old/pull/1>

I tested these changes on Debian 8 which has OpenSSL-1.0.1. Key size was
set to 4096-bits and signature algorithm to SHA256WithRSAEncryption.

The only real issue was DH parameter generation: it took ~25 minutes on
my Intel i5 laptop. Is that acceptable default behavior?


what kind of i5 is this? on my i7-4810 it took 5 minutes. Can you give the full 
CPUID string (from /proc/cpuinfo) ?  then I can
guestimate whether the 25 minutes is realistic for slower hardware.

I've run a a couple of "quick" tests ... on a two different laptops

--- test 1 --
$ time openssl gendh -out test 4096
[...snip...]

real35m40.098s
user35m38.922s
sys 0m0.367s
$ cat /proc/cpuinfo  | grep model\ name | uniq -c
   4 model name  : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz

<http://ark.intel.com/products/88193/Intel-Core-i5-6200U-Processor-3M-Cache-up-to-2_80-GHz>

--- test 2 --
$ time openssl gendh -out test 4096
[...snip...]

real13m59.742s
user13m59.448s
sys 0m0.140s
$ cat /proc/cpuinfo  | grep model\ name | uniq -c
   4 model name : Intel(R) Core(TM) i7-5600U