[Openvpn-devel] [PATCH applied] Re: Fix OpenSSL private key passphrase notices
Your patch has been applied to the master and release/2.4 branch. I haven't done any sort of qualified code review, but I have done a few test builds / t_client test runs, and all looks good. If Steffan says so, *and* it compiles, it's good enough for me anyway :-) Sorry for the delay... "interesting times". commit f67efa9412a62f477aa17c3179b7e9f31ac4b25f (master) commit 7d19b2bb7b4a4976bc720d72227ee79c440e06fc (release/2.4) Author: Santtu Lakkala Date: Mon Oct 21 14:35:06 2019 +0300 Fix OpenSSL private key passphrase notices Signed-off-by: Santtu Lakkala Acked-by: Steffan Karger Message-Id: <20191021113506.30377-1-santtu.lakk...@jolla.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18953.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
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
вт, 24 мар. 2020 г. в 22:19, Michael Kress : > Am Tue, 24 Mar 2020 11:21:56 +0100 > schrieb Arne Schwabe : > > > Am 23.03.20 um 17:11 schrieb Michael Kress: > > > Hello list, > > > > > > There seems to be some kind of alignment problem in OpenVPN 2.4 > > > versions on ARMv4 based machines (32 bit), especially when lzo > > > compression kicks in. > > > > LZO is known to miscompile with gcc 10 and requires > > -fno-strict-aliasing to compile. and also in my OpenVPN for Android > > app I have to compile lzo with -O1 instead -O2 since it otherwise > > segfaults on armv7a. Android uses LLVM/clang to compile so the broken > > behaviour is present also on other compilers. I never investigated > > which optimisation flag does break in clang/llvm/armv7a. > > The alignment errors happen in OpenVPN code, not in LZO code. > We have to use the (ancient) gcc 4.0.0. After upgrading OpenVPN from > 2.3 to 2.4 we did not even upgrade LZO from 2.0.6, but linked > statically to the old compiled lib. I doubt that the compiler itself > changes anything here. > > > But bottom line is that you probably are running in a similar and I > > would advise to compile lzo with less optimisation. > > Thanks for the suggestion! > > Anyways I recompiled LZO without any optimazations and then OpenVPN > 2.4.8. Unfortunatelly this changed nothing. > > A few questions: > > 1) Do you run automated tests of the OpenVPN code on any build server? > > 2) If that is the case, is there any test with a version, where >-DVERIFY_ALIGNMENT is enabled? > there are several test suites that you can run using "make check" (it performs several e2e tests and cmocka testing). also, there's openvpn vagrant suite intended for running several VMs on VirtualBox (and build and test openvpn on them) also, there's buildbot (not exposed to internet, but build logs available on mailing list) and there's travis-ci for express tests (actually "make check") for several build configurations: https://travis-ci.org/github/OpenVPN/openvpn I think we can add -DVERIFY_ALIGNMENT to some travis-ci builds > > 3) If that is also the case, can you see any ERRORS regarding the >alignment in the logs? > > The problem is, that we do not have any power over the clients. It > might well be, that there are even OpenVPN 2.2 clients out there. > > -- > Servus > Michael > > > ___ > 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] Possible memory alignment Problem in 2.4 ?
Am Tue, 24 Mar 2020 11:21:56 +0100 schrieb Arne Schwabe : > Am 23.03.20 um 17:11 schrieb Michael Kress: > > Hello list, > > > > There seems to be some kind of alignment problem in OpenVPN 2.4 > > versions on ARMv4 based machines (32 bit), especially when lzo > > compression kicks in. > > LZO is known to miscompile with gcc 10 and requires > -fno-strict-aliasing to compile. and also in my OpenVPN for Android > app I have to compile lzo with -O1 instead -O2 since it otherwise > segfaults on armv7a. Android uses LLVM/clang to compile so the broken > behaviour is present also on other compilers. I never investigated > which optimisation flag does break in clang/llvm/armv7a. The alignment errors happen in OpenVPN code, not in LZO code. We have to use the (ancient) gcc 4.0.0. After upgrading OpenVPN from 2.3 to 2.4 we did not even upgrade LZO from 2.0.6, but linked statically to the old compiled lib. I doubt that the compiler itself changes anything here. > But bottom line is that you probably are running in a similar and I > would advise to compile lzo with less optimisation. Thanks for the suggestion! Anyways I recompiled LZO without any optimazations and then OpenVPN 2.4.8. Unfortunatelly this changed nothing. A few questions: 1) Do you run automated tests of the OpenVPN code on any build server? 2) If that is the case, is there any test with a version, where -DVERIFY_ALIGNMENT is enabled? 3) If that is also the case, can you see any ERRORS regarding the alignment in the logs? The problem is, that we do not have any power over the clients. It might well be, that there are even OpenVPN 2.2 clients out there. -- Servus Michael ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] travis-ci: add arm64, s390x builds.
sometimes, arm64 build fails https://travis-ci.org/github/OpenVPN/openvpn/jobs/666389482?utm_medium=notification&utm_source=github_status if that will become often, we will mark it as "allowed failures" thanks to everyone, we have cmocka tests back! вт, 24 мар. 2020 г. в 14:04, Илья Шипицин : > I guess nobody yet reported that issue. > > Maybe, I'll report. > > вт, 24 мар. 2020 г. в 14:03, Lev Stipakov : > >> Yes, I agree that with name is looks much better. >> >> I wonder why displaying arch requires you to be logged in. >> > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] mbedTLS: Make sure TLS session survives move
From: Tom van Leeuwen
When an mbedTLS session is moved in move_session(), the contents of the
the tls_session is copied to the new session and the old session is
reinitialized. This tls_session contains, amongst other things, an
mbedtls_ssl_config and bio_ctx structure. However, the mbedtls context has
internal pointers to the mbedtls_ssl_config and bio_ctx. When the session
is moved, these internal pointers point to the reinitialized session.
Since there is no public method to update these internal pointers, this
patch allocates the mbedtls_ssl_config and bio_ctx on the heap and stores
the pointers in the tls_session instead.
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 0f0b035b..4f194ad7 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -1036,21 +1036,22 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
CLEAR(*ks_ssl);
/* Initialise SSL config */
-mbedtls_ssl_config_init(&ks_ssl->ssl_config);
-mbedtls_ssl_config_defaults(&ks_ssl->ssl_config, ssl_ctx->endpoint,
+ALLOC_OBJ_CLEAR(ks_ssl->ssl_config, mbedtls_ssl_config);
+mbedtls_ssl_config_init(ks_ssl->ssl_config);
+mbedtls_ssl_config_defaults(ks_ssl->ssl_config, ssl_ctx->endpoint,
MBEDTLS_SSL_TRANSPORT_STREAM,
MBEDTLS_SSL_PRESET_DEFAULT);
#ifdef MBEDTLS_DEBUG_C
mbedtls_debug_set_threshold(3);
#endif
-mbedtls_ssl_conf_dbg(&ks_ssl->ssl_config, my_debug, NULL);
-mbedtls_ssl_conf_rng(&ks_ssl->ssl_config, mbedtls_ctr_drbg_random,
+mbedtls_ssl_conf_dbg(ks_ssl->ssl_config, my_debug, NULL);
+mbedtls_ssl_conf_rng(ks_ssl->ssl_config, mbedtls_ctr_drbg_random,
rand_ctx_get());
-mbedtls_ssl_conf_cert_profile(&ks_ssl->ssl_config, &ssl_ctx->cert_profile);
+mbedtls_ssl_conf_cert_profile(ks_ssl->ssl_config, &ssl_ctx->cert_profile);
if (ssl_ctx->allowed_ciphers)
{
-mbedtls_ssl_conf_ciphersuites(&ks_ssl->ssl_config,
ssl_ctx->allowed_ciphers);
+mbedtls_ssl_conf_ciphersuites(ks_ssl->ssl_config,
ssl_ctx->allowed_ciphers);
}
/* Disable record splitting (for now). OpenVPN assumes records are sent
@@ -1058,35 +1059,35 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
* testing. Since OpenVPN is not susceptible to BEAST, we can just
* disable record splitting as a quick fix. */
#if defined(MBEDTLS_SSL_CBC_RECORD_SPLITTING)
-mbedtls_ssl_conf_cbc_record_splitting(&ks_ssl->ssl_config,
+mbedtls_ssl_conf_cbc_record_splitting(ks_ssl->ssl_config,
MBEDTLS_SSL_CBC_RECORD_SPLITTING_DISABLED);
#endif /* MBEDTLS_SSL_CBC_RECORD_SPLITTING */
/* Initialise authentication information */
if (is_server)
{
-mbed_ok(mbedtls_ssl_conf_dh_param_ctx(&ks_ssl->ssl_config,
+mbed_ok(mbedtls_ssl_conf_dh_param_ctx(ks_ssl->ssl_config,
ssl_ctx->dhm_ctx));
}
-mbed_ok(mbedtls_ssl_conf_own_cert(&ks_ssl->ssl_config, ssl_ctx->crt_chain,
+mbed_ok(mbedtls_ssl_conf_own_cert(ks_ssl->ssl_config, ssl_ctx->crt_chain,
ssl_ctx->priv_key));
/* Initialise SSL verification */
#if P2MP_SERVER
if (session->opt->ssl_flags & SSLF_CLIENT_CERT_OPTIONAL)
{
-mbedtls_ssl_conf_authmode(&ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_OPTIONAL);
+mbedtls_ssl_conf_authmode(ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_OPTIONAL);
}
else if (!(session->opt->ssl_flags & SSLF_CLIENT_CERT_NOT_REQUIRED))
#endif
{
-mbedtls_ssl_conf_authmode(&ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_REQUIRED);
+mbedtls_ssl_conf_authmode(ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_REQUIRED);
}
-mbedtls_ssl_conf_verify(&ks_ssl->ssl_config, verify_callback, session);
+mbedtls_ssl_conf_verify(ks_ssl->ssl_config, verify_callback, session);
/* TODO: mbed TLS does not currently support sending the CA chain to the
client */
-mbedtls_ssl_conf_ca_chain(&ks_ssl->ssl_config, ssl_ctx->ca_chain,
ssl_ctx->crl);
+mbedtls_ssl_conf_ca_chain(ks_ssl->ssl_config, ssl_ctx->ca_chain,
ssl_ctx->crl);
/* Initialize minimum TLS version */
{
@@ -1103,7 +1104,7 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
tls_version_to_major_minor(tls_version_min, &major, &minor);
}
-mbedtls_ssl_conf_min_version(&ks_ssl->ssl_config, major, minor);
+mbedtls_ssl_conf_min_version(ks_ssl->ssl_config, major, minor);
}
/* Initialize maximum TLS version */
@@ -1116,7 +1117,7 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
{
int major, minor;
tls_version_to_major_minor(tls_version_max, &major, &minor);
-mbedtls_ssl_conf_max_version(&ks_ssl->ssl_config, major, minor);
+mbedtls_ssl_conf_max_version(ks_ssl->ssl_config, major, minor);
}
}
@@ -1124,7 +1125,7 @@ key_state_ssl_init
Re: [Openvpn-devel] [PATCH] mbedTLS: Make sure TLS session survives move
Hi Tom, you forgot to CC the mailing list :-) I am adding it back. On 24/03/2020 16:44, Tom van Leeuwen wrote: > On 24-03-2020 14:54, Antonio Quartulli wrote: >> Hi, >> >> On 24/03/2020 14:35, Gert Doering wrote: >>> Hi, >>> >>> On Tue, Mar 24, 2020 at 11:42:02AM +0100, Tom van Leeuwen wrote: When an mbedTLS session is moved in move_session(), the contents of the the tls_session is copied to the new session and the old session is reinitialized. This tls_session contains, amongst other things, an mbedtls_ssl_config and bio_ctx structure. However, the mbedtls context has internal pointers to the mbedtls_ssl_config and bio_ctx. When the session is moved, these internal pointers point to the reinitialized session. >> Can you explain, from an higher level perspective, what real/visible >> issue is this creating? i.e. do we have a crash under specific >> circumstances? do we have a key exchange failure at some point? >> >> How did you find the issue? >> > Hi, > > Sorry for the inconvenience, I am not used to the git-email workflow. > > The issue is described in issue 880: > https://community.openvpn.net/openvpn/ticket/880 > > Summarizing, if you configure a bind-port on a client and you kill the > client, you cannot reconnect again. > My patch would fix issue 880. I think that the information you reported is good material for the commit message. That would help the casual reader understanding what this patch wants to achieve, before describing the how. Cheers, -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: travis-ci: add arm64, s390x builds.
Thanks. Your patch has been applied to the master branch. commit 072f7d352d4c9b9b58dfac97fc4bb5c95652aa25 Author: Ilya Shipitsin Date: Sun Mar 22 17:35:21 2020 +0500 travis-ci: add arm64, s390x builds. Acked-by: Lev Stipakov Message-Id: <20200322123521.17710-1-chipits...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19574.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: openvpnmsica, tapctl: Revise default hardware ID management
Your patch has been applied to the master branch. Test compiled with MinGW. Change makes sense, code looks reasonable. commit 50d68142f0926850122a78a6ca661d6778efacb3 Author: Simon Rozman Date: Mon Mar 9 14:17:26 2020 +0100 openvpnmsica, tapctl: Revise default hardware ID management Signed-off-by: Simon Rozman Acked-by: Lev Stipakov Message-Id: <20200309131728.380-10-si...@rozman.si> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19524.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: openvpnmsica: Extend to support arbitrary HWID network adapters
Your patch has been applied to the master branch. Looks reasonable. Compile tested with MSVC. (It looks a bit incomplete wrt "how to specify the component HWID now?" but this is coming in the next patches, I think) commit d263e4f300553ea77f1bf16538bcd0e81ed2e302 Author: Simon Rozman Date: Mon Mar 9 14:17:25 2020 +0100 openvpnmsica: Extend to support arbitrary HWID network adapters Signed-off-by: Simon Rozman Acked-by: Lev Stipakov Message-Id: <20200309131728.380-9-si...@rozman.si> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19521.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: openvpnmsica: TAP => TUN/TAP
Your patch has been applied to the master branch. >From a granularity point of view, this one could have been merged into the other big rename fest, 07/12... but anyway. Seems to make sense, compiles with MinGW. commit 8c487854323a23e1fd1bd5e8c2827f28272f74b9 Author: Simon Rozman Date: Mon Mar 9 14:17:24 2020 +0100 openvpnmsica: TAP => TUN/TAP Signed-off-by: Simon Rozman Acked-by: Lev Stipakov Message-Id: <20200309131728.380-8-si...@rozman.si> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19526.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: openvpnmsica, tapctl: interface => adapter
Your patch has been applied to the master branch. What a search-and-replace orgy :-) - did some staring at the diff, plus a test compile with MinGW commit 52b2414d3234d0fab5c1351f3035cda77a43fa2d Author: Simon Rozman Date: Mon Mar 9 14:17:23 2020 +0100 openvpnmsica, tapctl: interface => adapter Signed-off-by: Simon Rozman Acked-by: Lev Stipakov Message-Id: <20200309131728.380-7-si...@rozman.si> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19529.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: openvpnmsica: Simplify static function names
Your patch has been applied to the master branch. Cursory review agrees :-) - test compiled on MinGW. commit c8de3ddb2a660b96c6176901ac948d7c3b0a57e6 Author: Simon Rozman Date: Mon Mar 9 14:17:22 2020 +0100 openvpnmsica: Simplify static function names Signed-off-by: Simon Rozman Acked-by: Lev Stipakov Message-Id: <20200309131728.380-6-si...@rozman.si> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19528.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
Re: [Openvpn-devel] [PATCH] mbedTLS: Make sure TLS session survives move
Hi, On 24/03/2020 14:35, Gert Doering wrote: > Hi, > > On Tue, Mar 24, 2020 at 11:42:02AM +0100, Tom van Leeuwen wrote: >> When an mbedTLS session is moved in move_session(), the contents of the >> the tls_session is copied to the new session and the old session is >> reinitialized. This tls_session contains, amongst other things, an >> mbedtls_ssl_config and bio_ctx structure. However, the mbedtls context has >> internal pointers to the mbedtls_ssl_config and bio_ctx. When the session >> is moved, these internal pointers point to the reinitialized session. Can you explain, from an higher level perspective, what real/visible issue is this creating? i.e. do we have a crash under specific circumstances? do we have a key exchange failure at some point? How did you find the issue? -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: openvpnmsica: Revise MSI custom actions interop
Your patch has been applied to the master branch. Very cursory review only. Test compiled on MinGW. commit e24049d55644f698a8f1ddc199ba39944394edfa Author: Simon Rozman Date: Mon Mar 9 14:17:21 2020 +0100 openvpnmsica: Revise MSI custom actions interop Signed-off-by: Simon Rozman Acked-by: Lev Stipakov Message-Id: <20200309131728.380-5-si...@rozman.si> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19523.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
Re: [Openvpn-devel] [PATCH] mbedTLS: Make sure TLS session survives move
Hi, On Tue, Mar 24, 2020 at 11:42:02AM +0100, Tom van Leeuwen wrote: > When an mbedTLS session is moved in move_session(), the contents of the > the tls_session is copied to the new session and the old session is > reinitialized. This tls_session contains, amongst other things, an > mbedtls_ssl_config and bio_ctx structure. However, the mbedtls context has > internal pointers to the mbedtls_ssl_config and bio_ctx. When the session > is moved, these internal pointers point to the reinitialized session. > Since there is no public method to update these internal pointers, this > patch allocates the mbedtls_ssl_config and bio_ctx on the heap and stores > the pointers in the tls_session instead. > > diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c > index 0f0b035b..4f194ad7 100644 > --- a/src/openvpn/ssl_mbedtls.c > +++ b/src/openvpn/ssl_mbedtls.c > @@ -1036,21 +1036,22 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl, > CLEAR(*ks_ssl); > > /* Initialise SSL config */ Without speaking of the merits of the patch it self, it got destroyed on the way - all leading spaces got turned int "alt-space" (\xa0), so it won't apply. Can you re-send using "git send-email"? This usually nicely manages to avoid all classic "mail client breaks patch" problems. 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 10/12] openvpnmsica, tapctl: Revise default hardware ID management
Hi, > Since we are getting rid of default hwid, shouldn't we do it also for tapctl > and > make "tapctl list" return all adapters? This is fixed in 12/12. Acked-by: Lev Stipakov ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v2 12/12] tapctl: Support multiple hardware IDs
Hi, Compiled with msvc and smoke-tested, "tapctl list" returns all relevant adapters. This also resolves my concert from 10/12, so I'll ack that, too. Acked-by: Lev Stipakov ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 11/12] openvpnmsica: Merge FindTUNTAPAdapters into FindSystemInfo
Hi,
Compiled with msvc, smoke-tested with rundll32.
One thing:
> +set_openvpnserv_state(hInstall);
> +find_adapters(
> +hInstall,
> +TEXT("root\\") TEXT(TAP_WIN_COMPONENT_ID),
> +TEXT("TAPWINDOWS6ADAPTERS"),
> +TEXT("ACTIVETAPWINDOWS6ADAPTERS"));
Both methods return error codes which we ignore.
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] mbedTLS: Make sure TLS session survives move
When an mbedTLS session is moved in move_session(), the contents of the
the tls_session is copied to the new session and the old session is
reinitialized. This tls_session contains, amongst other things, an
mbedtls_ssl_config and bio_ctx structure. However, the mbedtls context has
internal pointers to the mbedtls_ssl_config and bio_ctx. When the session
is moved, these internal pointers point to the reinitialized session.
Since there is no public method to update these internal pointers, this
patch allocates the mbedtls_ssl_config and bio_ctx on the heap and stores
the pointers in the tls_session instead.
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 0f0b035b..4f194ad7 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -1036,21 +1036,22 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
CLEAR(*ks_ssl);
/* Initialise SSL config */
- mbedtls_ssl_config_init(&ks_ssl->ssl_config);
- mbedtls_ssl_config_defaults(&ks_ssl->ssl_config, ssl_ctx->endpoint,
+ ALLOC_OBJ_CLEAR(ks_ssl->ssl_config, mbedtls_ssl_config);
+ mbedtls_ssl_config_init(ks_ssl->ssl_config);
+ mbedtls_ssl_config_defaults(ks_ssl->ssl_config, ssl_ctx->endpoint,
MBEDTLS_SSL_TRANSPORT_STREAM,
MBEDTLS_SSL_PRESET_DEFAULT);
#ifdef MBEDTLS_DEBUG_C
mbedtls_debug_set_threshold(3);
#endif
- mbedtls_ssl_conf_dbg(&ks_ssl->ssl_config, my_debug, NULL);
- mbedtls_ssl_conf_rng(&ks_ssl->ssl_config, mbedtls_ctr_drbg_random,
+ mbedtls_ssl_conf_dbg(ks_ssl->ssl_config, my_debug, NULL);
+ mbedtls_ssl_conf_rng(ks_ssl->ssl_config, mbedtls_ctr_drbg_random,
rand_ctx_get());
- mbedtls_ssl_conf_cert_profile(&ks_ssl->ssl_config,
&ssl_ctx->cert_profile);
+ mbedtls_ssl_conf_cert_profile(ks_ssl->ssl_config,
&ssl_ctx->cert_profile);
if (ssl_ctx->allowed_ciphers)
{
- mbedtls_ssl_conf_ciphersuites(&ks_ssl->ssl_config,
ssl_ctx->allowed_ciphers);
+ mbedtls_ssl_conf_ciphersuites(ks_ssl->ssl_config,
ssl_ctx->allowed_ciphers);
}
/* Disable record splitting (for now). OpenVPN assumes records are
sent
@@ -1058,35 +1059,35 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
* testing. Since OpenVPN is not susceptible to BEAST, we can just
* disable record splitting as a quick fix. */
#if defined(MBEDTLS_SSL_CBC_RECORD_SPLITTING)
- mbedtls_ssl_conf_cbc_record_splitting(&ks_ssl->ssl_config,
+ mbedtls_ssl_conf_cbc_record_splitting(ks_ssl->ssl_config,
MBEDTLS_SSL_CBC_RECORD_SPLITTING_DISABLED);
#endif /* MBEDTLS_SSL_CBC_RECORD_SPLITTING */
/* Initialise authentication information */
if (is_server)
{
- mbed_ok(mbedtls_ssl_conf_dh_param_ctx(&ks_ssl->ssl_config,
+ mbed_ok(mbedtls_ssl_conf_dh_param_ctx(ks_ssl->ssl_config,
ssl_ctx->dhm_ctx));
}
- mbed_ok(mbedtls_ssl_conf_own_cert(&ks_ssl->ssl_config,
ssl_ctx->crt_chain,
+ mbed_ok(mbedtls_ssl_conf_own_cert(ks_ssl->ssl_config,
ssl_ctx->crt_chain,
ssl_ctx->priv_key));
/* Initialise SSL verification */
#if P2MP_SERVER
if (session->opt->ssl_flags & SSLF_CLIENT_CERT_OPTIONAL)
{
- mbedtls_ssl_conf_authmode(&ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_OPTIONAL);
+ mbedtls_ssl_conf_authmode(ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_OPTIONAL);
}
else if (!(session->opt->ssl_flags & SSLF_CLIENT_CERT_NOT_REQUIRED))
#endif
{
- mbedtls_ssl_conf_authmode(&ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_REQUIRED);
+ mbedtls_ssl_conf_authmode(ks_ssl->ssl_config,
MBEDTLS_SSL_VERIFY_REQUIRED);
}
- mbedtls_ssl_conf_verify(&ks_ssl->ssl_config, verify_callback, session);
+ mbedtls_ssl_conf_verify(ks_ssl->ssl_config, verify_callback, session);
/* TODO: mbed TLS does not currently support sending the CA chain
to the client */
- mbedtls_ssl_conf_ca_chain(&ks_ssl->ssl_config, ssl_ctx->ca_chain,
ssl_ctx->crl);
+ mbedtls_ssl_conf_ca_chain(ks_ssl->ssl_config, ssl_ctx->ca_chain,
ssl_ctx->crl);
/* Initialize minimum TLS version */
{
@@ -1103,7 +1104,7 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
tls_version_to_major_minor(tls_version_min, &major, &minor);
}
- mbedtls_ssl_conf_min_version(&ks_ssl->ssl_config, major, minor);
+ mbedtls_ssl_conf_min_version(ks_ssl->ssl_config, major, minor);
}
/* Initialize maximum TLS version */
@@ -1116,7 +1117,7 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
{
int major, minor;
tls_version_to_major_minor(tls_version_max, &major, &minor);
- mbedtls_ssl_conf_max_version(&ks_ssl->ssl_config, major,
minor);
+ mbedtls_ssl_conf_max_version(ks_ssl->ssl_config, major, minor);
}
}
@@ -1124,7 +1125,7 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Am 23.03.20 um 18:19 schrieb Michael Kress: > Hi, > > Unfortunatelly it seems, we are stuck to LZO for now, because it has > been configured in the clients, which run 2.3. Most of these clients are > offline most of the time, so reconfiguring or upgrading all of them > before updating the server will become difficult. > > You are completely right: One reason for upgrading to OpenVPN 2.4 is > indeed this feature. Another reason is, that Client and Server can > negotiate to use AES instead of Blowfish :-) > You can use client-connect to disable compression for newer clients. Example here: http://plai.de/android/peerid.py I would suggest stub-v2 instead lz4 however since that effectively disables compression completely (voracle). AS also takes this approach. Maybe we should make that default in newer versions. Arne P.S.: Sorry double copy, forgot to add CC to list in first email. signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Am 23.03.20 um 17:11 schrieb Michael Kress: > Hello list, > > There seems to be some kind of alignment problem in OpenVPN 2.4 > versions on ARMv4 based machines (32 bit), especially when lzo > compression kicks in. LZO is known to miscompile with gcc 10 and requires -fno-strict-aliasing to compile. and also in my OpenVPN for Android app I have to compile lzo with -O1 instead -O2 since it otherwise segfaults on armv7a. Android uses LLVM/clang to compile so the broken behaviour is present also on other compilers. I never investigated which optimisation flag does break in clang/llvm/armv7a. But bottom line is that you probably are running in a similar and I would advise to compile lzo with less optimisation. Arne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 10/12] openvpnmsica, tapctl: Revise default hardware ID management
Hi,
Since we are getting rid of default hwid, shouldn't we do it also for tapctl and
make "tapctl list" return all adapters?
Since it defaults to root\tap0901, "tapctl list" doesn't show anything for me,
which is a bit confusing:
> c:\Users\lev\Projects\openvpn\x64-Output\Debug>tapctl.exe list
>
If I want to see tap adapters, I need to explicitly specify tap0901:
> c:\Users\lev\Projects\openvpn\x64-Output\Debug>tapctl.exe list --hwid tap0901
> {82A7A5F5-4D32-4274-84CF-DF36171159BD} Local Area Connection
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] travis-ci: add arm64, s390x builds.
I guess nobody yet reported that issue. Maybe, I'll report. вт, 24 мар. 2020 г. в 14:03, Lev Stipakov : > Yes, I agree that with name is looks much better. > > I wonder why displaying arch requires you to be logged in. > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] travis-ci: add arm64, s390x builds.
Yes, I agree that with name is looks much better. I wonder why displaying arch requires you to be logged in. ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] travis-ci: add arm64, s390x builds.
Hi, Tested with my openvpn github fork - all jobs passed and overall travis dashboard looks nice thanks to added "name" field. It would be even nicer to have "arch" as part of name, because now it looks like gcc | openssl-1.1.1d gcc | openssl-1.1.1d But this is already step forward and improvements could be done in a separate patch. Acked-by: Lev Stipakov ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
