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

[Antonio Quartulli]

Hi Tony,

On 26/11/2020 01:46, Tony He wrote:
>>OpenSSL directly talks to the crypto engine via a proprietary interface
>>that the FW/driver exposes to userspace. The *data* flow does not cross
>>the linux kernel crypto API
> 
> No, OpenSSL doesn't directly talk to the  crypto engine via a
> proprietary interface that the FW/driver exposes to userspace.
> "cryptodev engine" is NOT the "HW engine" chip vendor provides. It's a
> common interface and its source is not from
> chip vendor. Please refer to:
> https://github.com/cryptodev-linux/cryptodev-linux
> 
> https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators
> 

Thanks for clarifying!
I thought you were talking about the crypto engine offload provided by
OpenSSL via vendor library.

So, if I understand this correctly, what you are saying is that the
vendor provides kernel patches in order to add HW support to the kernel
crypto API for an architecture that is normally not supported by the
upstream kernel. Then cryptodev is used to allow userspace to use the
kernel API.

This said, I am sorry, but I am not sure we should continue this
discussion any further, because as of now we have no plan to introduce
yet another crypto family in ovpn-dco.

One of the goal with ovpn-dco is to leave behind the legacy from
openvpn2 in userspace and focus on those features we believe to be
"state of the art". This is why we decided to only support AEAD with
only AES-GCM and CHACHA20POLY1305, DATA_V2 only, etc.

Focus is on keeping the code simple and ensure it can be accepted
upstream in the Linux kernel quickly.

It was an hard decision to make, but the whole group decided to take
this direction. People that want to use different
configurations/settings will still be able to do so by using openvpn2 in
userspace, as it happened until now.


Cheers,


> 
> Tony 
>  
> 
> Antonio Quartulli  于2020年11月26日周四 上午12:19写道：
> 
> Hi Tony,
> 
> > OpenVPN-> openssl->crypodev engine->cryptodev-linux->Linux kernel
> crypto API->HW engine crypto API-> HW engine driver-> HW engine
> 
> Now I understand better what you have in mind.
> 
> To the best of my knowledge, this is not how it works.
> 
> OpenSSL directly talks to the crypto engine via a proprietary interface
> that the FW/driver exposes to userspace. The *data* flow does not cross
> the linux kernel crypto API.
> 
> Moist of the time this special interfaces are made "to work with openssl
> only", so I am not even sure how the kernel API could use it.
> 
> Do you have any pointer saying otherwise?
> 
> 
> -- 
> Antonio Quartulli
> 

-- 
Antonio Quartulli


___
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?

[Tony He]

>OpenSSL directly talks to the crypto engine via a proprietary interface
>that the FW/driver exposes to userspace. The *data* flow does not cross
>the linux kernel crypto API

No, OpenSSL doesn't directly talk to the  crypto engine via a proprietary
interface that the FW/driver exposes to userspace.
"cryptodev engine" is NOT the "HW engine" chip vendor provides. It's a
common interface and its source is not from
chip vendor. Please refer to:
https://github.com/cryptodev-linux/cryptodev-linux
https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators

Tony


Antonio Quartulli  于2020年11月26日周四 上午12:19写道：

> Hi Tony,
>
> > OpenVPN-> openssl->crypodev engine->cryptodev-linux->Linux kernel crypto
> API->HW engine crypto API-> HW engine driver-> HW engine
>
> Now I understand better what you have in mind.
>
> To the best of my knowledge, this is not how it works.
>
> OpenSSL directly talks to the crypto engine via a proprietary interface
> that the FW/driver exposes to userspace. The *data* flow does not cross
> the linux kernel crypto API.
>
> Moist of the time this special interfaces are made "to work with openssl
> only", so I am not even sure how the kernel API could use it.
>
> Do you have any pointer saying otherwise?
>
>
> --
> Antonio Quartulli
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Improve keys out of sync message

[Gert Doering]

Acked-by: Gert Doering 

I have no test bed that will trigger this, but the change is
not hard to understand (extend print_key_id() with a 
"auth=make_string(ks->authenticated)", append the result to
the "TLS Error:" message.

All other users of print_key_id() are all "just debug output",
so the new format will not confuse anything.

Compile tested on the client.

As with 2/8, uncrustify does not like the indenting of the
new switch/case block.  Adjusted.

Your patch has been applied to the master branch.

commit f1f0f074bf6e7b91673bfa8cb08b3be44ebda76b
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:55 2020 +0200

 Improve keys out of sync message

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-3-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21226.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



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

[Openvpn-devel] [PATCH applied] Re: Add more documentation about our internal TLS functions

[Gert Doering]

Acked-by: Gert Doering 

"This was an easy one" - documentation is good.

Your patch has been applied to the master branch.

commit 8292102b102ff62d6b7ed1254076b822cb113162
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:54 2020 +0200

 Add more documentation about our internal TLS functions

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-2-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21220.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



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

[Openvpn-devel] [PATCH applied] Re: Replace key_scan array of static points with inline function

[Gert Doering]

Acked-by: Gert Doering 

Not sure if I ever understood these shortcuts (there are 3*2 keys
in session[].keys[], but the shortcuts only reference [0][0],
[0][1] and [2][1]) but from a "mechanically comparing before/after"
point of view, the change looks sane.  

Plus, it passes client side tests, with short reneg timeouts (20s).

This change, of course, makes it more interesting to do backports
of ssl.c-related changes from master/2.6 to 2.5...  so let's get
out 2.6 quickly :-)

Uncrustify complains about indent of the new switch/case block,
and that there is a trailing semicolon.  Fixed.

*Also*, this patch needed to be (manually) rebased due to context 
conflicts after 0d4ca79d4f.  Done.

"points" -> "pointers", as requested.

Your patch has been applied to the master branch.

commit cc5a71637139557a7eaa024251ff75a0acb22bc8
Author: Arne Schwabe
Date:   Fri Oct 23 14:02:53 2020 +0200

 Replace key_scan array of static pointers with inline function

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20201023120259.29783-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21225.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



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

[Openvpn-devel] Summary of the community meeting (25th November 2020)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 25th November 2020
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:



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



SUMMARY

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

---

Talked about the 80 character limit in the OpenVPN codebase and agreed 
to set the soft limit to 80 chars and the hard limit to 120 characters. 
This was because sometimes trying to stay below 80 characters for the 
sake of it makes the code uglier, not prettier. For example, when you 
have to use temporary variables with short names just to accomplish it. 
Plus on modern terminals 80 characters is quite little.


---

Talked about the data channel offload (DCO) kernel module work in 
OpenVPN 2 by plaisthos and ordex. The current code/status is hacky and 
works with only one peer and renogotiation does not work yet. A cleaner 
integration is probably coming when ovpn-dco gets p2mp support: this 
avoids having to refactor twice.


Lev is checking if DCO could be reasonably be done within the 
tap-windows6 driver as well. There is also the possibility that Linux 
version of OpenVPN 2 + DCO could be used as-is on WSL2 (Windows 
Subsystem for Linux) which basically runs a Linux kernel on top of Hyper-V.


The DCO changes will require us to improve our automated testing to 
ensure things do not break too badly.


--

Noted that OpenVPN 2.4.10 release is on schedule. That is, it will be 
released "next week".


--

Noted that mattock is now able to resume the Buildmaster upgrade work. 
This will require upgrading all buildslaves to Python 3, including our 
zombie from the dinosaur age, OpenSolaris. Our codebase still supports 
that platform so we should not stop testing it, either.


---

Full chatlog attached
(12:29:45) cron2: meeting calling...
(12:30:44) mattock: hello
(12:31:18) cron2: hi!
(12:32:58) mattock: anyone else?
(12:33:10) cron2: so, while we wait for dazo, plaisthos, ordex to find their 
way... any news on IPv6?
(12:34:08) ordex: here here
(12:34:26) ordex: dazo most likely won't join
(12:34:34) ordex: he's out at least until the end of the month I believe
(12:34:45) cron2: :(
(12:35:29) mattock: nothing on ipv6, it all depends on the migration to 
openvpn.com domain which I can keep asking about (no meeting this week though, 
Thanksgiving and all)
(12:35:54) cron2: yeah... *sigh*
(12:37:38) mattock: such an empty topic list: 
https://community.openvpn.net/openvpn/wiki/Topics-2020-11-25
(12:37:42) cron2: so, where is plaisthos hiding :-)
(12:38:02) mattock: ordex?
(12:38:59) ordex: I don't really have much on my side
(12:39:00) plaisthos: since even Linux kernel allows now 100 chars wide code, 
can we also allow a bit longer lines? *makes dog's eyes*
(12:39:07) ***ordex agrees
(12:40:27) cron2: I think a general 80 character "soft limit" is still 
reasonable, with flexibility if the alternatives are just plain ugly... so 100 
or 120 "flex margin" would work for me
(12:41:02) cron2: I am tempted often enough to just make something 83 
characters, because wrapping looks more ugly...
(12:41:36) ordex: yeah
(12:41:39) ordex: that makes sense
(12:43:30) cron2: since you two are the ones who wrote most of the code in the 
last years, I think we can just decide this here and now...
(12:43:44) cron2: (and not wait for dazo or syzzer or james to show up and 
agree :-) )
(12:45:05) Pippin_ [Pippin_@gateway/vpn/protonvpn/pippin/x-75792076] è entrato 
nella stanza.
(12:45:23) plaisthos: a lot of times I am wrapping functiosn to two lines 
instead of one because of the 80 char limit or introduce temporary variables to 
shorten the names
(12:45:29) plaisthos: I would like to reduce that
(12:45:41) plaisthos: because I don't think that improves overall readability
(12:45:45) mattock: I'll add this decision to the meeting summary and anyone 
who wants to complain can complain :)
(12:45:51) cron2: understood.  Would you be fine with a "general 80 character 
limit, as a goal, with flexibility to go to 100/120"?
(12:46:01) cron2: (the last sentence was intended for plaisthos)
(12:46:24) plaisthos: unless you are really on a machine or terminal that 
cannot be made 100 or 120
(12:46:54) plaisthos: lets keep a 120 hard limit
(12:47:10) cron2: I personally find code that has "all very long lines" (or 
extremely deeply nested) harder to read, that's why "soft/hard"
(12:47:17) plaisthos: yeah
(12:47:19) cron2: okay, so "soft 80, hard 120"?  Everyone ok with that?
(12:47:24) plaisthos: okay
(12:47:52) cron2: ordex went for lunch, it seems :)
(12:47:55) ordex: nono
(12:47:58) ordex: still thinking :D
(12:48:08) ordex: soft 80, hard 120 sounds good though
(12:48:27) ordex: I was just thinking that also moving the soft to 80 would be 
ok imho. 80 is just very