Re: [Openvpn-devel] OpenVPN encryption architecture

[Arne Schwabe]

Am 05.04.22 um 05:10 schrieb Leroy Tennison:
Thanks for your reply, I'm actually looking for something pretty 
high-level like "the server (or client) sends their (whatever key) and 
the client (or server) (creates a session key from it or whatever 
happens) and that is used for encryption."  I am also wondering what the 
client and server keys are used for if not in this process.




High level is that we use a TLS 1.0/TLS 1.1 inspired key exchange in 
older versions and nowadays if both server and client are capable of TLS 
EKM, we use TLS EKM to generate key material for encryption of data 
channel.


The server and client keys are used in the TLS session like with any TLS 
session.


Arne


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

[Openvpn-devel] Community meetings in April 2022

[Samuli Seppänen]

Hi,

Next community meetings have been scheduled to

- Wed 6th March 2022 at 10:30 CEST
- Wed 13th March 2022 at 10:30 CEST
- Wed 20th March 2022 at 10:30 CEST
- Wed 27th March 2022 at 10:30 CEST

The place is #openvpn-meeting IRC channel at libera.chat Meeting agendas
and summaries are in here:



Samuli




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

Re: [Openvpn-devel] [PATCH 5/7] tun: extract close_tun_handle into its own fucntion and print correct type

[Frank Lichtenheld]

Acked-by: Frank Lichtenheld 

Seems trivial.

> Antonio Quartulli  hat am 02.04.2022 09:09 geschrieben:
[...]
> +if (tt->hand != NULL)
> +{
> +dmsg(D_WIN32_IO_LOW, "Attempting CloseHandle on %s adapter", 
> adaptertype);
> +if (!CloseHandle(tt->hand))
> +{
> +msg(M_WARN | M_ERRNO, "Warning: CloseHandle failed on %s 
> adapter", adaptertype);
> +}
> +tt->hand = NULL;

Setting hand to NULL is a slight behavior change, it wasn't there before.
It might be nice to acknowledge it in the commit message just to confirm that
it was a deliberate change.

Regards,
--
Frank Lichtenheld


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

Re: [Openvpn-devel] [PATCH 6/7] ovpn-dco-win: introduce windows data-channel offload support

[Frank Lichtenheld]

> Antonio Quartulli  hat am 02.04.2022 09:09 geschrieben:
[...]
> diff --git a/README.dco.md b/README.dco.md
> index 27c166b9..d3599727 100644
> --- a/README.dco.md
> +++ b/README.dco.md
> @@ -109,6 +116,8 @@ Limitations by design
>  - topology subnet is the only supported `--topology` for servers
>  - iroute directives install routes on the host operating system, see also
>routing with ovpn-dco
> +- (ovpn-dco-win) client and p2p mode only
> +- (ovpn-dco-win) only AES-GCM-128/192/256 cipher support

This seems to be out-of-sync with the code. The code seems to add 
CHACHA20-POLY1305 support
on Windows 11.

As seen here:
> +
> +const char *
> +dco_get_supported_ciphers()
> +{
> +/*
> + * this API can be called either from user mode or kernel mode,
> + * which enables us to probe driver's chachapoly support
> + * (available starting from Windows 11)
> + */
> +
> +BCRYPT_ALG_HANDLE h;
> +NTSTATUS status = BCryptOpenAlgorithmProvider(&h, L"CHACHA20_POLY1305", 
> NULL, 0);
> +if (BCRYPT_SUCCESS(status))
> +{
> +BCryptCloseAlgorithmProvider(h, 0);
> +return "AES-128-GCM:AES-256-GCM:AES-192-GCM:CHACHA20-POLY1305";
> +}
> +else
> +{
> +return "AES-128-GCM:AES-256-GCM:AES-192-GCM";
> +}
> +}
> +

Regards,
--
Frank Lichtenheld


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

Re: [Openvpn-devel] [PATCH 5/7] tun: extract close_tun_handle into its own fucntion and print correct type

[Antonio Quartulli]

Hi,

On 05/04/2022 12:00, Frank Lichtenheld wrote:

Acked-by: Frank Lichtenheld 

Seems trivial.


Antonio Quartulli  hat am 02.04.2022 09:09 geschrieben:

[...]

+if (tt->hand != NULL)
+{
+dmsg(D_WIN32_IO_LOW, "Attempting CloseHandle on %s adapter", 
adaptertype);
+if (!CloseHandle(tt->hand))
+{
+msg(M_WARN | M_ERRNO, "Warning: CloseHandle failed on %s adapter", 
adaptertype);
+}
+tt->hand = NULL;


Setting hand to NULL is a slight behavior change, it wasn't there before.
It might be nice to acknowledge it in the commit message just to confirm that
it was a deliberate change.


Yes, it was a deliberate change.
This helper function will be invoked by (possibly) multiple places, so 
it's better to set a precondition and prevent a double close.


I agree we should add a sentence to the commit message about this.

Regards,


--
Antonio Quartulli


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

Re: [Openvpn-devel] [PATCH 6/7] ovpn-dco-win: introduce windows data-channel offload support

[Antonio Quartulli]

Hi,

On 05/04/2022 12:14, Frank Lichtenheld wrote:




Antonio Quartulli  hat am 02.04.2022 09:09 geschrieben:

[...]

diff --git a/README.dco.md b/README.dco.md
index 27c166b9..d3599727 100644
--- a/README.dco.md
+++ b/README.dco.md
@@ -109,6 +116,8 @@ Limitations by design
  - topology subnet is the only supported `--topology` for servers
  - iroute directives install routes on the host operating system, see also
routing with ovpn-dco
+- (ovpn-dco-win) client and p2p mode only
+- (ovpn-dco-win) only AES-GCM-128/192/256 cipher support


This seems to be out-of-sync with the code. The code seems to add 
CHACHA20-POLY1305 support
on Windows 11.


You are correct - this should be changed.

Regards,

--
Antonio Quartulli


___
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 4/7] ovpn-dco: introduce linux data-channel offload support

[Antonio Quartulli]

Hi,

On 04/04/2022 18:04, Frank Lichtenheld wrote:

Documentation review:


Thanks for the feedback, will integrate it appropriately.

Regards,


--
Antonio Quartulli


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

Re: [Openvpn-devel] Community meetings in April 2022

[Samuli Seppänen]

In April, not in March as stated before. So

- Wed 6th April 2022 at 10:30 CEST
- Wed 13th April 2022 at 10:30 CEST
- Wed 20th April 2022 at 10:30 CEST
- Wed 27th April 2022 at 10:30 CEST

Samuli

Il 5.4.2022 12.19, Samuli Seppänen ha scritto:

Hi,

Next community meetings have been scheduled to

- Wed 6th March 2022 at 10:30 CEST
- Wed 13th March 2022 at 10:30 CEST
- Wed 20th March 2022 at 10:30 CEST
- Wed 27th March 2022 at 10:30 CEST

The place is #openvpn-meeting IRC channel at libera.chat Meeting agendas
and summaries are in here:



Samuli




___
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] [ovpn-dco] How to benchmark kernel crypto performance?

[Tony He]

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)

Tony

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] [PATCH 3/7] networking: implement net_iface_new and net_iface_del APIs

[Gert Doering]

Hi,

On Sat, Apr 02, 2022 at 09:08:58AM +0200, Antonio Quartulli wrote:
> +++ b/src/openvpn/networking_iproute2.c
> @@ -38,6 +38,12 @@
>  #include 
>  #include 
>  
> +static const char *iface_type_str[] = {
> +[IFACE_DUMMY] = "dummy",
> +[IFACE_TUN] = "tun",
> +[IFACE_OVPN_DCO] = "ovpn-dco",
> +};

I find this notation surprising - I guess it's "ensure that array
indexes match enum values", but it's a construct we do not use anywhere
else in OpenVPN (I think).


> +net_iface_new(openvpn_net_ctx_t *ctx, const char *iface, enum iface_type 
> type,
> +  void *arg)
> +{
> +struct argv argv = argv_new();
> +
> +argv_printf(&argv, "%s link add %s type %s", iproute_path, iface,
> +iface_type_str[type]);

Also, there is no array bounds check here...

>  #ifdef ENABLE_SITNL
> +
> +static const char *iface_type_str[] = {
> +[IFACE_DUMMY] = "dummy",
> +[IFACE_TUN] = "tun",
> +[IFACE_OVPN_DCO] = "ovpn-dco",
> +};

Plus, it is repeated here...  (and no bounds check either).

Can we come up with something more in line with the rest of OpenVPN,
like a static function that will return the name of that thing, for
consumers that want a name, and "dummy" or "unknown" for out-of-bounds
access?

(Right now, all consumers want a string, and the caller passes in
a single-use enum, which is not used for anything but "convert back
to string", so the value of having an enum here is not really obvious)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


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

Re: [Openvpn-devel] [PATCH 3/7] networking: implement net_iface_new and net_iface_del APIs

[Gert Doering]

Hi,

On Sat, Apr 02, 2022 at 09:08:58AM +0200, Antonio Quartulli wrote:
> +int
> +net_iface_del(openvpn_net_ctx_t *ctx, const char *iface)
> +{
> +struct argv argv = argv_new();
> +
> +argv_printf(&argv, "%s link del %s", iproute_path, iface);
> +openvpn_execve_check(&argv, ctx->es, S_FATAL, "Linux ip link del 
> failed");
> +
> +argv_free(&argv);

On "failure to remove something" we generally do not hard-abort right
away but just report the error, and continue with cleaning up things.

So maybe net_iface_del() should do the same thing?

(See "undo_ifconfig_ipv4()", for example, or most other close_tun() related
openvpn_execve_check() calls)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


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

Re: [Openvpn-devel] [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