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

[Tony He]

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.
* aes-128-gcm is NOT accelerated by HW engine.
* 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.


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 sha1 for 3s on 16 size blocks: 95252 sha1's in 3.00s Doing
sha1 for 3s on 64 size blocks: 95166 sha1's in 3.00s Doing sha1 for 3s on
256 size blocks: 76177 sha1's in 3.00s Doing sha1 for 3s on 1024 size
blocks: 68799 sha1's in 3.00s Doing sha1 for 3s on 8192 size blocks: 53034
sha1's in 3.00s . type 16 bytes 64 bytes 256 bytes 1024
bytes 8192 bytes sha1 508.01k 2030.21k 6500.44k 23483.39k 144818.18k

Without 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: 9235207 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size
blocks: 2498066 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size
blocks: 645288 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size
blocks: 161372 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size
blocks: 20385 aes-128-cbc's in 3.00s  type 16 bytes 64
bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 49254.44k 53292.07k
55064.58k 55081.64k 55664.64k
# 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: 3507422 aes-128-gcm's in 3.00s Doing aes-128-gcm for 3s on 64 size
blocks: 901036 aes-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 

[Openvpn-devel] Summary of the community meeting (3rd December 2020)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Thu 3rd December 2020
Time: 20:00 CET (19:00 UTC)

Planned meeting topics for this meeting were here:



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



SUMMARY

becm, cron2, dazo, mattock, ordex, plaisthos and syzzer participated in
this meeting.

---

Agreed to release OpenVPN 2.4.10 early next week, assuming OpenSSL has
made their pre-announced (=important) release before that.

---

Agreed to bundle libpkcs11-helper 1.27 with 2.4.10. We're at 1.26 now,
and the changes between the versions look safe.

---

Noted that some of the auth-token fixed from Git "master" could and
should be backported to release/2.5. The refactorings done in "master"
could be omitted. It seems like at the moment there's no real need to
push out 2.5.1.

---

Agreed to not have meeting on Dec 23rd or 31st. The last meeting this
month will be on 17th.

--

Talked about HackerOne bounties. Agreed to go through the current
HackerOne reports and set awards (bounties) and close all reports down
(if possible) in the next meeting. Then we can close our HackerOne
project for good.

---

Noted that "IPv6 to community.openvpn.net" has not moved forward. But
OpenVPN Inc. ops team manager is aware that cron2 needs to be kept happy
and that IPv6 will have to arrive eventually.

---

Talked about the buildbot upgrade. It will need a couple of days of
concentrated effort from mattock's part. Doing the upgrade around
Christmas time sounds realistic.

---

Full chatlog attached
(21:01:32) ordex: aloha!
(21:01:57) syzzer_: hi!
(21:02:10) mattock: hi
(21:02:28) becm: hi
(21:02:47) ordex: cron2: dazo: plaisthos: ?
(21:02:53) ***cron2 hides
(21:03:16) cron2 ha scelto come argomento: 
https://community.openvpn.net/openvpn/wiki/Topics-2020-12-03
(21:03:35) dazo: Hey!
(21:03:41) cron2: yo!
(21:04:43) plaisthos: I am only semi here
(21:04:52) ordex: which part is here exactly?
(21:05:00) cron2: which is half more than usual on thursday evenings
(21:05:05) ordex: :D
(21:05:53) cron2: whoa, 4 ACKs on the list
(21:06:20) ordex: amazzing
(21:06:33) ordex: are we aiming at doing another 2.4.x release?
(21:07:26) cron2: yes
(21:08:00) cron2: a number of bugfixes have accumulated in release/2.4, so we 
agreed (2-3 weeks ago) to do a 2.4.10
(21:08:04) cron2: eventually
(21:08:18) mattock: internal meeting goes on and goes on...
(21:08:36) cron2: tell them you do not care until the IPv6 crisis is solved :)
(21:08:44) mattock: :)
(21:08:57) ordex: :D
(21:09:02) ordex: cron2: ok
(21:09:12) mattock: so 2.4.10 when?
(21:09:47) cron2: I want the line number fix to be in, but have not written the 
second version yet... so maybe early next week?  What works for you?
(21:10:31) mattock: early next week would be ok
(21:11:07) cron2: good.  I'll see that I can get the patch done tomorrow-ish, 
so ordex can review it ("he ACKed the other one but wanted to see a variant")
(21:11:39) ordex: yup, can do
(21:12:28) becm: will the 2.4.10 for Windows ship with the brand new 
pkcs11-helper 1.27?
(21:12:28) cron2: 25 patches in tree since 2.4.9
(21:13:05) cron2: do we have feedback about pcks11-helper in 2.5.0?
(21:13:30) cron2: like, "works!" or "breaks :-("?  I haven't seen *any* 
feedback on 2.5.0 yet, which is sort of... "what does that mean?"
(21:13:31) mattock: becm: it looks like we have 1.26 now in generic/build.vars
(21:13:50) mattock: cron2: I think it means it is stable and boring
(21:14:17) cron2: this is how I like my software :)
(21:14:20) mattock: which is somewhat surprising given how much stuff went to it
(21:14:31) mattock: perhaps we're doing something right :D
(21:14:37) ordex: :D
(21:14:38) ordex: it happens
(21:14:44) ***cron2 pats his test rig :)
(21:15:22) mattock: so, libpkcs11-helper 1.26 -> 1.27 in 2.4.10 and 2.5.1?
(21:15:28) mattock: any reason not to?
(21:15:35) cron2: becm: what is in there?
(21:16:08) dazo: https://github.com/OpenSC/pkcs11-helper/releases
(21:16:19) becm: looks like 2 bugfixes to me?
(21:16:59) dazo: "thanks to Tunnelblick" ... smells like it has been tested ;-)
(21:17:20) mattock: at least in tunnelblick
(21:17:37) mattock: also look like your libpkcs11-helper patch should apply ok
(21:17:46) mattock: I say "why not"
(21:17:53) cron2: yea
(21:17:54) cron2: h
(21:18:28) dazo: agreed
(21:19:17) ordex: looks good to me too
(21:20:47) cron2: anything else on 2.4?
(21:21:38) dazo: Don't think so
(21:21:44) cron2: good :-)
(21:21:48) cron2: 2.5 status, then
(21:22:05) mattock: I think we need to update all the other dependencies as 
well - build-complete.vars has not been updated since 2.4.9, but that's the 
normal procedure anyways
(21:22:23) cron2: 4 patches in tree since 2.5.0, 1 "make install" patch, 2 
"client side fixup for auth-token + auth-nocache" patches
(21:22:34) dazo: oh, OpenSSL is about to 

[Openvpn-devel] Community meetings in December 2020

[Samuli Seppänen]

Hi,

Our community meetings will alternate between Wed 11:30 CET and Thu
20:00 CET.

Next meetings have been scheduled to

- Thu 3rd December 20:00 CET (ongoing)
- Wed 9th December 11:30 CET
- Thu 17th December 20:00 CET

The place is #openvpn-meeting IRC channel at Freenode. 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 1/2 v2] tls-crypt-v2: fix server memory leak

[Antonio Quartulli]

Hi,

On 03/12/2020 19:22, Steffan Karger wrote:
> tls-crypt-v2 was developed in parallel with the changes that allowed to
> use tls-auth/tls-crypt in connection blocks. The tls-crypt-v2 patch set
> was never updated to the new reality after commit 5817b49b, causing a
> memory leak of about 600 bytes for each connecting client.
> 
> It would be nicer to not reload the tls-crypt-v2 server key for each
> connecting client, but that requires more refactoring (and thus more time
> to get right). So for now just plug the leak by free'ing the memory when
> we close a client connection.
> 
> To test this easily, compile openvpn with -fsanity=address, run a server
> with tls-crypt-v2, connect a client, stop the server.
> 
> Signed-off-by: Steffan Karger 


Acked-by: Antonio Quartulli 


-- 
Antonio Quartulli


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

[Openvpn-devel] [PATCH 1/2 v2] tls-crypt-v2: fix server memory leak

[Steffan Karger]

tls-crypt-v2 was developed in parallel with the changes that allowed to
use tls-auth/tls-crypt in connection blocks. The tls-crypt-v2 patch set
was never updated to the new reality after commit 5817b49b, causing a
memory leak of about 600 bytes for each connecting client.

It would be nicer to not reload the tls-crypt-v2 server key for each
connecting client, but that requires more refactoring (and thus more time
to get right). So for now just plug the leak by free'ing the memory when
we close a client connection.

To test this easily, compile openvpn with -fsanity=address, run a server
with tls-crypt-v2, connect a client, stop the server.

Signed-off-by: Steffan Karger 
---
v2: remove now-redundant free_key_ctx() from key_schedule_free()

 src/openvpn/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 27a4170d..c3493c42 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2561,7 +2561,6 @@ key_schedule_free(struct key_schedule *ks, bool 
free_ssl_ctx)
 if (tls_ctx_initialised(>ssl_ctx) && free_ssl_ctx)
 {
 tls_ctx_free(>ssl_ctx);
-free_key_ctx(>tls_crypt_v2_server_key);
 }
 CLEAR(*ks);
 }
@@ -3619,6 +3618,7 @@ do_close_free_key_schedule(struct context *c, bool 
free_ssl_ctx)
  * always free the tls_auth/crypt key. If persist_key is true, the key will
  * be reloaded from memory (pre-cached)
  */
+free_key_ctx(>c1.ks.tls_crypt_v2_server_key);
 free_key_ctx_bi(>c1.ks.tls_wrap_key);
 CLEAR(c->c1.ks.tls_wrap_key);
 buf_clear(>c1.ks.tls_crypt_v2_wkc);
-- 
2.25.1



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

Re: [Openvpn-devel] [PATCH 1/2] tls-crypt-v2: fix server memory leak

[Antonio Quartulli]

Hi Steffan,

On 03/12/2020 16:49, Steffan Karger wrote:
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 27a4170d..5cde8a4b 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -3619,6 +3619,7 @@ do_close_free_key_schedule(struct context *c, bool 
> free_ssl_ctx)
>   * always free the tls_auth/crypt key. If persist_key is true, the key 
> will
>   * be reloaded from memory (pre-cached)
>   */
> +free_key_ctx(>c1.ks.tls_crypt_v2_server_key);
>  free_key_ctx_bi(>c1.ks.tls_wrap_key);
>  CLEAR(c->c1.ks.tls_wrap_key);
>  buf_clear(>c1.ks.tls_crypt_v2_wkc);

A few lines below we call key_schedule_free() (under certain conditions)
which also performs:

free_key_ctx(>tls_crypt_v2_server_key);


I believe it is safe to call free_key_ctx() twice on the same object,
but wouldn't it be better to have it called once only along the same
code path?

Regards,


-- 
Antonio Quartulli


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

Re: [Openvpn-devel] [PATCH 2/2] tls-crypt-v2: also preload tls-crypt-v2 keys (if --persist-key)

[Arne Schwabe]

Am 03.12.20 um 16:49 schrieb Steffan Karger:
> This allows tls-crypt-v2 servers to drop privileges after reading the
> keys. Without it, the server would try to read the key file for each
> connecting client. (And clients for each reconnect.)
> 
> As with the previous patch, the pre-loading was developed in parallel
> with tls-crypt-v2, and the tls-crypt-v2 patches were never amended to
> implement the pre-loading.
> 
> Also as with the previous patch, it would be nicer if servers would not
> reload the tls-crypt-v2 server key for each connecting client. But let's
> first fix the issue, and see if we can improve later.

Agreed. One thing at a time.

Acked-By: Arne Schwabe 



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

[Openvpn-devel] [PATCH 2/2] tls-crypt-v2: also preload tls-crypt-v2 keys (if --persist-key)

[Steffan Karger]

This allows tls-crypt-v2 servers to drop privileges after reading the
keys. Without it, the server would try to read the key file for each
connecting client. (And clients for each reconnect.)

As with the previous patch, the pre-loading was developed in parallel
with tls-crypt-v2, and the tls-crypt-v2 patches were never amended to
implement the pre-loading.

Also as with the previous patch, it would be nicer if servers would not
reload the tls-crypt-v2 server key for each connecting client. But let's
first fix the issue, and see if we can improve later.

Signed-off-by: Steffan Karger 
---
 src/openvpn/options.c | 52 +--
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 21f8d494..599f534c 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -1980,6 +1980,23 @@ connection_entry_load_re(struct connection_entry *ce, 
const struct remote_entry
 }
 }
 
+static void
+connection_entry_preload_key(const char **key_file, bool *key_inline,
+ struct gc_arena *gc)
+{
+if (key_file && *key_file && !(*key_inline))
+{
+struct buffer in = buffer_read_from_file(*key_file, gc);
+if (!buf_valid())
+{
+msg(M_FATAL, "Cannot pre-load keyfile (%s)", *key_file);
+}
+
+*key_file = (const char *) in.data;
+*key_inline = true;
+}
+}
+
 static void
 options_postprocess_verify_ce(const struct options *options,
   const struct connection_entry *ce)
@@ -2931,36 +2948,17 @@ options_postprocess_mutate_ce(struct options *o, struct 
connection_entry *ce)
 ce->tls_crypt_v2_file_inline = o->tls_crypt_v2_file_inline;
 }
 
-/* pre-cache tls-auth/crypt key file if persist-key was specified and keys
- * were not already embedded in the config file
+/* Pre-cache tls-auth/crypt(-v2) key file if persist-key was specified and
+ * keys were not already embedded in the config file.
  */
 if (o->persist_key)
 {
-if (ce->tls_auth_file && !ce->tls_auth_file_inline)
-{
-struct buffer in = buffer_read_from_file(ce->tls_auth_file, 
>gc);
-if (!buf_valid())
-{
-msg(M_FATAL, "Cannot pre-load tls-auth keyfile (%s)",
-ce->tls_auth_file);
-}
-
-ce->tls_auth_file = (char *)in.data;
-ce->tls_auth_file_inline = true;
-}
-
-if (ce->tls_crypt_file && !ce->tls_crypt_file_inline)
-{
-struct buffer in = buffer_read_from_file(ce->tls_crypt_file, 
>gc);
-if (!buf_valid())
-{
-msg(M_FATAL, "Cannot pre-load tls-crypt keyfile (%s)",
-ce->tls_crypt_file);
-}
-
-ce->tls_crypt_file = (char *)in.data;
-ce->tls_crypt_file_inline = true;
-}
+connection_entry_preload_key(>tls_auth_file,
+ >tls_auth_file_inline, >gc);
+connection_entry_preload_key(>tls_crypt_file,
+ >tls_crypt_file_inline, >gc);
+connection_entry_preload_key(>tls_crypt_v2_file,
+ >tls_crypt_v2_file_inline, >gc);
 }
 }
 
-- 
2.25.1



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

[Openvpn-devel] [PATCH 1/2] tls-crypt-v2: fix server memory leak

[Steffan Karger]

tls-crypt-v2 was developed in parallel with the changes that allowed to
use tls-auth/tls-crypt in connection blocks. The tls-crypt-v2 patch set
was never updated to the new reality after commit 5817b49b, causing a
memory leak of about 600 bytes for each connecting client.

It would be nicer to not reload the tls-crypt-v2 server key for each
connecting client, but that requires more refactoring (and thus more time
to get right). So for now just plug the leak by free'ing the memory when
we close a client connection.

To test this easily, compile openvpn with -fsanity=address, run a server
with tls-crypt-v2, connect a client, stop the server.

Signed-off-by: Steffan Karger 
---
 src/openvpn/init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 27a4170d..5cde8a4b 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -3619,6 +3619,7 @@ do_close_free_key_schedule(struct context *c, bool 
free_ssl_ctx)
  * always free the tls_auth/crypt key. If persist_key is true, the key will
  * be reloaded from memory (pre-cached)
  */
+free_key_ctx(>c1.ks.tls_crypt_v2_server_key);
 free_key_ctx_bi(>c1.ks.tls_wrap_key);
 CLEAR(c->c1.ks.tls_wrap_key);
 buf_clear(>c1.ks.tls_crypt_v2_wkc);
-- 
2.25.1



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

Re: [Openvpn-devel] [PATCH v2] Fix port-share option with TLS-Crypt v2

[Steffan Karger]

Hi,

On 30-11-2020 13:38, Arne Schwabe wrote:
> The port-share option assumed that all openvpn initial reset packets
> are between 14 and 255 bytes long. This is not true for tls-crypt-v2.
> 
> Patch V2: use correct length for TLS-Crypt v2, use length variable
>   non-tlscryptv2 test
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/ps.c | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/src/openvpn/ps.c b/src/openvpn/ps.c
> index 2089e6b9..5d760782 100644
> --- a/src/openvpn/ps.c
> +++ b/src/openvpn/ps.c
> @@ -983,14 +983,38 @@ is_openvpn_protocol(const struct buffer *buf)
>  const int len = BLEN(buf);
>  if (len >= 3)
>  {
> -return p[0] == 0
> -   && p[1] >= 14
> -   && (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V2 << P_OPCODE_SHIFT)
> -   || p[2] == (P_CONTROL_HARD_RESET_CLIENT_V3 << 
> P_OPCODE_SHIFT));
> +int plen = (p[0] << 8) | p[1];
> +
> +if (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V3 << P_OPCODE_SHIFT))
> +{
> +/* WKc is at least 290 byte (not including metadata):
> + *
> + * 16 bit len + 256 bit HMAC + 2048 bit Kc = 2320 bit
> + *
> + * This is increased by the normal length of client handshake +
> + * tls-crypt overhead (32)
> + *
> + * For metadata tls-crypt-v2.txt does not explicitly specify
> + * an upper limit but we also have TLS_CRYPT_V2_MAX_WKC_LEN
> + * as 1024 bytes. We err on the safe side with 255 extra overhead
> + *
> + * We don't do the 2 byte check for tls-crypt-v2 because it is 
> very
> + * unrealistic to have only 2 bytes available.
> + */
> +return  (plen >= 336 && plen < (1024 + 255));
> +}
> +else
> +{
> +/* For non tls-crypt2 we assume the packet length to valid 
> between
> + * 14 and 255 */
> +return plen >= 14 && plen <= 255
> +   && (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V2 << 
> P_OPCODE_SHIFT));
> +}
>  }
>  else if (len >= 2)
>  {
> -return p[0] == 0 && p[1] >= 14;
> +int plen = (p[0] << 8) | p[1];
> +return plen >= 14 && plen <= 255;
>  }
>  else
>  {
> 

Thanks. This looks good to me now.

Ran some tests to check that this correctly resolves the issue when
using --tls-crypt-v2 in combination with --port-share.

Acked-by: Steffan Karger 

-Steffan


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

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

[Arne Schwabe]

Am 03.12.20 um 14:32 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> I didn't send a new patch yet because I only wanted to provide an update
> that progress is being made. I'm attaching an updated patch if you are
> interested.
> 
> I didn't get that error when compiling wolfSSL with the compile options
> you provided. Is it possible that you didn't run `autoreconf` after
> pulling in the latest commit in the branch but before running the
> configure script?

Yes. The -Wshorten-64-to-32 might be Clang/LLVM specific or not enabled
on gcc by default.

> 
> The warning is due to wolfSSL using a generic compare function
> definition with pointers to void as parameters.

Yeah, it breaks -Werror which I normally use to compile OpenVPN.

Arne



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

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

[Juliusz Sosinowicz]

Hi Arne,

I didn't send a new patch yet because I only wanted to provide an update 
that progress is being made. I'm attaching an updated patch if you are 
interested.


I didn't get that error when compiling wolfSSL with the compile options 
you provided. Is it possible that you didn't run `autoreconf` after 
pulling in the latest commit in the branch but before running the 
configure script?


The warning is due to wolfSSL using a generic compare function 
definition with pointers to void as parameters.


Sincerely
Juliusz

On 03/12/2020 13:22, Arne Schwabe wrote:

Am 19.11.20 um 13:23 schrieb Juliusz Sosinowicz:

Hi Arne,

some time has passed and I was able to address most of your comments in
my branch
https://github.com/julek-wolfssl/wolfssl/tree/openvpn-2.5-missing-stuff

To summarize what has been done regarding your comments:

   * SHA1 was indeed being called SHA in wolfSSL. I changed this in favor
 of just using SHA1.
   * in configure.ac I used David Sommerseth's suggestion to use
 PKG_CHECK_MODULES to get the wolfSSL installation directory.

Do you that new patch posted here? I don't see an updated patch.


   * setting tls min and max is currently not working in the branch that
 I linked above but we have a big compatibility layer PR pending that
 appears to fix these issues. Once it is merged I'll revisit this
 issue and make sure it is solved.
   * show-tls is fixed but it also relies on the PR I mentioned earlier.
 After that is merged this should be solved.
   * tls-ciphersuites and tls-cipher appears to be working in general.
 Should wolfSSL reject the specified cipher if for example a TLS 1.3
 cipher is set using --tls-cipher?

Well that is a general question you have to answer yourself on OpenSSL
compatibility. I don't think this is just for OpenVPN.


   * unfortunately wolfSSL does not support ed448 certificates.

That is not a show stopper. Mbed TLS does not support them either.


   * tls-groups now checks the validity of the passed in curves
   * since OpenVPN will make use TLS EKM, exporting keying material has
 been implemented in wolfSSL.

Great!


   * I haven't tested OpenVPN with the FIPS mode patch so that issue is
 still pending. Once I get a chance to test it I will also change
 wolfSSL to target 1.1.0+ API

Thanks for your patience!


Hey I am trying to check on this. Since I haven't found the new patch. I
am trying to use it with the old one:

I am getting an error related to EKM:

./../../openvpn-git/src/openvpn/ssl_openssl.c:166:9: error: implicit
declaration of function 'wolfSSL_export_keying_material' is invalid in C99
   [-Werror,-Wimplicit-function-declaration]
 if (SSL_export_keying_material(ssl, ekm, ekm_size, label,


So I tried ./configure --enable-openvpn --enable-keying-material for
WolfSSL but that failed during compile:

src/tls13.c:806:50: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
   [-Werror,-Wshorten-64-to-32]
 protocol, protocolLen, (byte*)label, labelLen,
  ^~~~
src/tls13.c:812:38: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
   [-Werror,-Wshorten-64-to-32]
 ret = wc_Hash(hashType, context, contextLen, hashOut,
WC_MAX_DIGEST_SIZE);
   ~~~^~
src/tls13.c:816:34: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
   [-Werror,-Wshorten-64-to-32]
 ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
   ~  ^~
   CC   tests/unit_test-unit.o
src/ssl.c:11526:61: error: implicit conversion loses integer precision:
'unsigned long' to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
 word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + contextLen;
~~~ ~^~~~
src/ssl.c:11590:25: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
   [-Werror,-Wshorten-64-to-32]
 if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
 ~~  ^~
src/ssl.c:11591:27: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
   [-Werror,-Wshorten-64-to-32]
 (byte*)label, labelLen, seed, seedLen, IsAtLeastTLSv1_2(ssl),



I am also seeing another warning during the compilation:

../../../openvpn-git/src/openvpn/ssl_openssl.c:1559:55: warning:
incompatible pointer types passing 'int (const X509_NAME *const *, const
   X509_NAME *const *)' (aka 'int (const struct WOLFSSL_X509_NAME
*const *, const struct WOLFSSL_X509_NAME *const *)') to parameter of type
   'wolf_sk_compare_cb' (aka 'int (*)(const void 

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

[Arne Schwabe]

Am 19.11.20 um 13:23 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> some time has passed and I was able to address most of your comments in
> my branch
> https://github.com/julek-wolfssl/wolfssl/tree/openvpn-2.5-missing-stuff
> 
> To summarize what has been done regarding your comments:
> 
>   * SHA1 was indeed being called SHA in wolfSSL. I changed this in favor
> of just using SHA1.
>   * in configure.ac I used David Sommerseth's suggestion to use
> PKG_CHECK_MODULES to get the wolfSSL installation directory.

Do you that new patch posted here? I don't see an updated patch.

>   * setting tls min and max is currently not working in the branch that
> I linked above but we have a big compatibility layer PR pending that
> appears to fix these issues. Once it is merged I'll revisit this
> issue and make sure it is solved.
>   * show-tls is fixed but it also relies on the PR I mentioned earlier.
> After that is merged this should be solved.
>   * tls-ciphersuites and tls-cipher appears to be working in general.
> Should wolfSSL reject the specified cipher if for example a TLS 1.3
> cipher is set using --tls-cipher?

Well that is a general question you have to answer yourself on OpenSSL
compatibility. I don't think this is just for OpenVPN.

>   * unfortunately wolfSSL does not support ed448 certificates.

That is not a show stopper. Mbed TLS does not support them either.

>   * tls-groups now checks the validity of the passed in curves
>   * since OpenVPN will make use TLS EKM, exporting keying material has
> been implemented in wolfSSL.

Great!

>   * I haven't tested OpenVPN with the FIPS mode patch so that issue is
> still pending. Once I get a chance to test it I will also change
> wolfSSL to target 1.1.0+ API
> 
> Thanks for your patience!
> 

Hey I am trying to check on this. Since I haven't found the new patch. I
am trying to use it with the old one:

I am getting an error related to EKM:

./../../openvpn-git/src/openvpn/ssl_openssl.c:166:9: error: implicit
declaration of function 'wolfSSL_export_keying_material' is invalid in C99
  [-Werror,-Wimplicit-function-declaration]
if (SSL_export_keying_material(ssl, ekm, ekm_size, label,


So I tried ./configure --enable-openvpn --enable-keying-material for
WolfSSL but that failed during compile:

src/tls13.c:806:50: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
  [-Werror,-Wshorten-64-to-32]
protocol, protocolLen, (byte*)label, labelLen,
 ^~~~
src/tls13.c:812:38: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
  [-Werror,-Wshorten-64-to-32]
ret = wc_Hash(hashType, context, contextLen, hashOut,
WC_MAX_DIGEST_SIZE);
  ~~~^~
src/tls13.c:816:34: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
  [-Werror,-Wshorten-64-to-32]
ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
  ~  ^~
  CC   tests/unit_test-unit.o
src/ssl.c:11526:61: error: implicit conversion loses integer precision:
'unsigned long' to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + contextLen;
   ~~~ ~^~~~
src/ssl.c:11590:25: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
  [-Werror,-Wshorten-64-to-32]
if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
~~  ^~
src/ssl.c:11591:27: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
  [-Werror,-Wshorten-64-to-32]
(byte*)label, labelLen, seed, seedLen, IsAtLeastTLSv1_2(ssl),



I am also seeing another warning during the compilation:

../../../openvpn-git/src/openvpn/ssl_openssl.c:1559:55: warning:
incompatible pointer types passing 'int (const X509_NAME *const *, const
  X509_NAME *const *)' (aka 'int (const struct WOLFSSL_X509_NAME
*const *, const struct WOLFSSL_X509_NAME *const *)') to parameter of type
  'wolf_sk_compare_cb' (aka 'int (*)(const void *const *, const void
*const *)') [-Wincompatible-pointer-types]
cert_names = sk_X509_NAME_new(sk_x509_name_cmp);
  ^~~~


Arne


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