[Openvpn-devel] [PATCH] using OpenSSL3 API for EVP PKEY type name reporting
Signed-off-by: Michael Baentsch
---
src/openvpn/ssl_openssl.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index 2b932af9..65b36d1c 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -1501,7 +1501,11 @@ tls_ctx_use_management_external_key(struct tls_root_ctx
*ctx)
}
EVP_PKEY_free(privkey);
#else /* ifdef HAVE_XKEY_PROVIDER */
+#if OPENSSL_VERSION_NUMBER < 0x3000L
if (EVP_PKEY_id(pkey) == EVP_PKEY_RSA)
+#else /* OPENSSL_VERSION_NUMBER < 0x3000L */
+if (EVP_PKEY_is_a(pkey, "RSA"))
+#endif /* OPENSSL_VERSION_NUMBER < 0x3000L */
{
if (!tls_ctx_use_external_rsa_key(ctx, pkey))
{
@@ -1509,7 +1513,11 @@ tls_ctx_use_management_external_key(struct tls_root_ctx
*ctx)
}
}
#if (OPENSSL_VERSION_NUMBER > 0x1010L) && !defined(OPENSSL_NO_EC)
+#if OPENSSL_VERSION_NUMBER < 0x3000L
else if (EVP_PKEY_id(pkey) == EVP_PKEY_EC)
+#else /* OPENSSL_VERSION_NUMBER < 0x3000L */
+else if (EVP_PKEY_is_a(pkey, "EC"))
+#endif /* OPENSSL_VERSION_NUMBER < 0x3000L */
{
if (!tls_ctx_use_external_ec_key(ctx, pkey))
{
@@ -2064,10 +2072,15 @@ print_cert_details(X509 *cert, char *buf, size_t buflen)
}
int typeid = EVP_PKEY_id(pkey);
+#if OPENSSL_VERSION_NUMBER < 0x3000L
+bool is_ec = typeid == EVP_PKEY_EC;
+#else
+bool is_ec = EVP_PKEY_is_a(pkey, "EC");
+#endif
#ifndef OPENSSL_NO_EC
char groupname[256];
-if (typeid == EVP_PKEY_EC)
+if (is_ec)
{
size_t len;
if (EVP_PKEY_get_group_name(pkey, groupname, sizeof(groupname), &len))
@@ -2080,9 +2093,9 @@ print_cert_details(X509 *cert, char *buf, size_t buflen)
}
}
#endif
-if (EVP_PKEY_id(pkey) != 0)
+if (typeid != 0)
{
-int typeid = EVP_PKEY_id(pkey);
+#if OPENSSL_VERSION_NUMBER < 0x3000L
type = OBJ_nid2sn(typeid);
/* OpenSSL reports rsaEncryption, dsaEncryption and
@@ -2104,6 +2117,13 @@ print_cert_details(X509 *cert, char *buf, size_t buflen)
{
type = "unknown type";
}
+#else /* OpenSSL >= 3 */
+type = EVP_PKEY_get0_type_name(pkey);
+if (type == NULL)
+{
+type = "(error getting public key type)";
+}
+#endif /* if OPENSSL_VERSION_NUMBER < 0x3000L */
}
char sig[128] = { 0 };
--
2.17.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] Re: using OpenSSL3 API for EVP PKEY type name reporting
Hi Gert, thanks very much! > Have not investigated how to actually trigger these code lines. If you're curious (TL;DR), below's a test FWIW: The fix can be seen "in action" when using OpenVPN with a quantum-safe signature algorithm via oqs-provider: Everything built into docker images: 1) New code in openquantumsafe/openvpn:23903fd579353c98: # openvpn --version OpenVPN 2.7_git [git:master/23903fd579353c98] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD] [DCO] built on Mar 21 2023 library versions: OpenSSL 3.2.0-dev , LZO 2.10 2023-03-21 09:08:43 us=455158 10.0.5.3:37633 TLS: tls_multi_process: initial untrusted session promoted to trusted WWRR2023-03-21 09:08:43 us=455383 10.0.5.3:37633 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 192 bit dilithium3, signature: dilithium3 2023-03-21 09:08:43 us=455406 10.0.5.3:37633 [oqsopenvpnclient] Peer Connection Initiated with [AF_INET]10.0.5.3:37633 --> Connection establishment OK 2) Old code in openquantumsafe/openvpn:838474145933199a # openvpn --version OpenVPN 2.7_git [git:master/838474145933199a] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD] [DCO] built on Mar 14 2023 library versions: OpenSSL 3.2.0-dev , LZO 2.10 2023-03-21 09:10:59 us=432368 10.0.5.3:40978 TLS: tls_multi_process: initial untrusted session promoted to trusted WWRR2023-03-21 09:10:59 us=432601 10.0.5.3:40978 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 192 bit unknown type, signature: dilithium3 2023-03-21 09:10:59 us=432619 10.0.5.3:40978 [oqsopenvpnclient] Peer Connection Initiated with [AF_INET]10.0.5.3:40978 2023-03-21 09:10:59 us=432634 10.0.5.3:40978 OpenSSL: error:0465:object identifier routines::unknown nid 2023-03-21 09:10:59 us=432640 10.0.5.3:40978 TLS_ERROR: BIO read tls_read_plaintext error 2023-03-21 09:10:59 us=432648 10.0.5.3:40978 TLS Error: TLS object -> incoming plaintext read error 2023-03-21 09:10:59 us=432653 10.0.5.3:40978 TLS Error: TLS handshake failed --> Connection setup failure Regards, --Michael Am 20.03.23 um 14:01 schrieb Gert Doering: I have not tested this extensively, just subjected to GH to compile and run basic checks with OpenSSL 1.1.x and 3.0.x, and ran a few local tests (Linux + OpenSSL 1.1.1). This all passed. Have not investigated how to actually trigger these code lines. Your patch has been applied to the master and release/2.6 branch. commit 6c111be9b109a6dbcd39cac7821ea3dd78ff6adf (master) commit a05ec70edd5178aac7b7432c57878c32aa838013 (release/2.6) Author: Michael Baentsch Date: Sun Mar 19 08:54:41 2023 +0100 using OpenSSL3 API for EVP PKEY type name reporting Signed-off-by: Michael Baentsch Acked-by: Arne Schwabe Message-Id:<20230319075441.13021-1-i...@baentsch.ch> URL:https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26439.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] Enablement of quantum-safe key establishment
Hello,
as per https://community.openvpn.net/openvpn/ticket/1460 the current
openvpn master fails when activating a TLS1.3 group implemented in an
external provider.
The patch attached fixes this and enables successful OpenSSL key
establishment using any of the quantum-safe and hybrid (classic/QSC)
algorithms supported by https://github.com/open-quantum-safe/oqs-provider
Regards,
--Michael
index b8595174..73ab4b6a 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -572,7 +572,9 @@ void
tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const char *groups)
{
ASSERT(ctx);
-struct gc_arena gc = gc_new();
+char *f = strstr(groups, "secp256r1");
+int rc;
+
/* This method could be as easy as
* SSL_CTX_set1_groups_list(ctx->ctx, groups)
* but OpenSSL does not like the name secp256r1 for prime256v1
@@ -580,43 +582,26 @@ tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const char *groups)
* To support the same name for OpenSSL and mbedTLS, we do
* this dance.
*/
-
-int groups_count = get_num_elements(groups, ':');
-
-int *glist;
-/* Allocate an array for them */
-ALLOC_ARRAY_CLEAR_GC(glist, int, groups_count, &gc);
-
-/* Parse allowed ciphers, getting IDs */
-int glistlen = 0;
-char *tmp_groups = string_alloc(groups, &gc);
-
-const char *token;
-while ((token = strsep(&tmp_groups, ":")))
-{
-if (streq(token, "secp256r1"))
-{
-token = "prime256v1";
-}
-int nid = OBJ_sn2nid(token);
-
-if (nid == 0)
-{
-msg(M_WARN, "Warning unknown curve/group specified: %s", token);
-}
-else
-{
-glist[glistlen] = nid;
-glistlen++;
-}
+if (f) {
+ char *new_groups_list = malloc(strlen(groups)+2);
+ char * idx = new_groups_list;
+ memcpy(idx, groups, (f-groups));
+ idx += (f-groups);
+ memcpy(idx, "prime256v1", strlen("prime256v1"));
+ idx += strlen("prime256v1");
+ memcpy(idx, f+strlen("secp256r1"), strlen(groups)-(f-groups)-strlen("secp256r1"));
+ new_groups_list[strlen(groups)+1] = '\0';
+
+ rc = SSL_CTX_set1_groups_list(ctx->ctx, new_groups_list);
+ free(new_groups_list);
}
+else
+ rc = SSL_CTX_set1_groups_list(ctx->ctx, groups);
-if (!SSL_CTX_set1_groups(ctx->ctx, glist, glistlen))
-{
+if (!rc) {
crypto_msg(M_FATAL, "Failed to set allowed TLS group list: %s",
groups);
}
-gc_free(&gc);
}
void
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Enablement of quantum-safe key establishment
Thanks very much for the quick and thorough feedback. Indeed your last
question is pivotal making the patch _much_ simpler (attached): The
problem manifests itself only in the presence of providers introduced in
OpenSSL3.0. At the same time, the curve name causing the "dance code" is
permitted as of OpenSSL3.0...
So all other observations below are moot/should be resolved with the
much simpler new patch attached. Feel free to delete/amend the comment
changes as you see fit.
--Michael
Am 24.03.22 um 18:48 schrieb Arne Schwabe:
Am 24.03.22 um 14:40 schrieb Michael Baentsch:
Hello,
as per https://community.openvpn.net/openvpn/ticket/1460 the
current openvpn master fails when activating a TLS1.3 group
implemented in an external provider.
The patch attached fixes this and enables successful OpenSSL key
establishment using any of the quantum-safe and hybrid (classic/QSC)
algorithms supported by
https://github.com/open-quantum-safe/oqs-provider
Thanks for the patch. Usually we would like to have patches in a git
format that contains a commit message (see git format-patch) and
https://github.com/OpenVPN/openvpn/blob/master/CONTRIBUTING.rst
The current patch has a few problems:
- Breaks OpenSSL 1.0.2 compatibity. Currently we still support RHEL7,
which only has OpenSSL 1.0.2
- uses C90 variable declaration (int rc)
- indentation problems
We normally use our own gc_alloc etc usage for strings as the previous
code did. That usage was replaced with malloc/free.
And the code does not have any comments but removes the existing ones
and with a line like this:
memcpy(idx, f+strlen("secp256r1"),
strlen(groups)-(f-groups)-strlen("secp256r1"));
some comments what the code is doing would improve readibility.
The fix itself is right of using the newer SSL_CTX_set1_groups_list
function that uses strings instead of nids.
But if we use a function that only newer OpenSSL version, have you
double checked that the prime256v1 vs secp256r1 is still necessary
Build failure with OpenSSL 1.0.2:
https://github.com/schwabe/openvpn/runs/5680551849?check_suite_focus=true
Arne
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index b8595174..af97dabc 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -572,13 +572,15 @@ void
tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const char *groups)
{
ASSERT(ctx);
+#if OPENSSL_VERSION_NUMBER < 0x3000L
struct gc_arena gc = gc_new();
/* This method could be as easy as
* SSL_CTX_set1_groups_list(ctx->ctx, groups)
- * but OpenSSL does not like the name secp256r1 for prime256v1
+ * but OpenSSL (< 3.0) does not like the name secp256r1 for prime256v1
* This is one of the important curves.
* To support the same name for OpenSSL and mbedTLS, we do
* this dance.
+ * Also note that the code is wrong in the presence of OpenSSL3 providers.
*/
int groups_count = get_num_elements(groups, ':');
@@ -617,6 +619,13 @@ tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const char *groups)
groups);
}
gc_free(&gc);
+#else
+if (!SSL_CTX_set1_groups_list(ctx->ctx, groups))
+{
+crypto_msg(M_FATAL, "Failed to set allowed TLS group list: %s",
+ groups);
+}
+#endif
}
void
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Enablement of quantum-safe key establishment
I'm not quite sure I understand what you're asking me to do. Why not simply use standard github cooperation mechanisms? Whatever, I put the stuff into https://github.com/OpenVPN/openvpn/pull/170 but couldn't run the command suggested there: $ git send-email --to=openvpn-devel@lists.sourceforge.net HEAD~1 git: 'send-email' ist kein Git-Befehl. Siehe 'git --help'. Pardon the German of my computer: It says "send-email" is no known git command. Please let me know what to do now. Regards, --Michael FWIW, I now have Am 25.03.22 um 16:09 schrieb Antonio Quartulli: On 25/03/2022 16:04, Arne Schwabe wrote: Am 25.03.22 um 08:21 schrieb Michael Baentsch: Thanks very much for the quick and thorough feedback. Indeed your last question is pivotal making the patch _much_ simpler (attached): The problem manifests itself only in the presence of providers introduced in OpenSSL3.0. At the same time, the curve name causing the "dance code" is permitted as of OpenSSL3.0... So all other observations below are moot/should be resolved with the much simpler new patch attached. Feel free to delete/amend the comment changes as you see fit. Thanks v2 looks much better code wise and gets ack from me. To commit the patch could you either send the patch in git format-message format or provide a commit subject and text so we can make full commit of your patch? We also need the patch to bear the sign-off-by line, so better create an actual git commit and export it via git-format-patch. Cheers, ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] correct tls-groups for OpenSSL3
From: Michael <57787676+baent...@users.noreply.github.com>
---
src/openvpn/ssl_openssl.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index b8595174..af97dabc 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -572,13 +572,15 @@ void
tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const char *groups)
{
ASSERT(ctx);
+#if OPENSSL_VERSION_NUMBER < 0x3000L
struct gc_arena gc = gc_new();
/* This method could be as easy as
* SSL_CTX_set1_groups_list(ctx->ctx, groups)
- * but OpenSSL does not like the name secp256r1 for prime256v1
+ * but OpenSSL (< 3.0) does not like the name secp256r1 for prime256v1
* This is one of the important curves.
* To support the same name for OpenSSL and mbedTLS, we do
* this dance.
+ * Also note that the code is wrong in the presence of OpenSSL3 providers.
*/
int groups_count = get_num_elements(groups, ':');
@@ -617,6 +619,13 @@ tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const
char *groups)
groups);
}
gc_free(&gc);
+#else
+if (!SSL_CTX_set1_groups_list(ctx->ctx, groups))
+{
+crypto_msg(M_FATAL, "Failed to set allowed TLS group list: %s",
+ groups);
+}
+#endif
}
void
--
2.17.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Enablement of quantum-safe key establishment
Am 28.03.22 um 13:52 schrieb Arne Schwabe: Am 27.03.22 um 17:52 schrieb Michael Baentsch: Thanks again for your explanations: I finally figured out to correct my git send-email configuration `smtpencryption` to be set to "ssl" (instead of "tls": The latter caused a hang that I debugged for way too long :-(. Maybe worth while adding to some FAQ for newbies? The guidance at https://github.com/git/git/blob/master/Documentation/git-send-email.txt was clearly wrong. Please let me know if that submission now arrived and meets your requirements. The commit message is still not great. Something I would have used instead: Well Allow non-standard EC groups with OpenSSL3 This statement just is not correct: This has not a lot to do with EC. What about "Enable setting any TLS1.3 group [provided by the underlying crypto libraries]. "? OpenSSL3 no longer uses the NID to identify TLS groups, instead it uses names. This allows also to use groups from external provider. It also recognises secp256r1 as the same group as prime256v1. This statement also is not quite right: OpenSSL3 still uses NIDs to identify some groups, notably those not implemented by a provider, i.e., legacy/"classic" crypto. I would agree with the statement that "OpenSSL3 prefers the use of names over NIDs for the identification of TLS1.3 groups, including EC groups." Lastly, the "it" in your statement above is unclear (at least to me as a non-native speaker): What about explicitly stating "OpenSSL3 also recognises secp256r1 as the same group as prime256v1"? This fact of course has nothing to do with this patch. One further question: Is there interest on your side to add more/better support for quantum-safe crypto to OpenVPN? Depends on what changes you are proposing. There is certainly some interest but depends on what exactly we are talking about. I'll flesh that out. It mostly has to do with modifications to "easyrsa" - see below. easyrsa isn't geared for that right now (let alone suitably named :-), but openssl3 (with our oqsprovider) can generate quantum-safe PKI (CA and client certs) without problems. Easyrsa has become also separate project. Development and maintainance of easyrsa have become quite slow in the last years. That statement is very helpful, thanks. It might then be sensible (for me) to start a script from scratch that does not have such strong dependency on legacy crypto. Will report back when I have something of interest. Quantum-safe key exchange works in OpenVPN just fine when the PR lands. Thanks in advance for any guidance how to proceed with the PR now. ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Enable usage of TLS groups not identified by a NID in OpenSSL 3
From: Michael <57787676+baent...@users.noreply.github.com>
OpenSSL3 prefers to specify groups (including EC groups) with names
instead of NID to allow also groups provided by providers.
This commit also removes the mapping of secp256r1 to prime256v1 for
the OpenSSL3 code path as OpenSSL 3.0 recognises secp256r1.1
---
src/openvpn/ssl_openssl.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index b8595174..af97dabc 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -572,13 +572,15 @@ void
tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const char *groups)
{
ASSERT(ctx);
+#if OPENSSL_VERSION_NUMBER < 0x3000L
struct gc_arena gc = gc_new();
/* This method could be as easy as
* SSL_CTX_set1_groups_list(ctx->ctx, groups)
- * but OpenSSL does not like the name secp256r1 for prime256v1
+ * but OpenSSL (< 3.0) does not like the name secp256r1 for prime256v1
* This is one of the important curves.
* To support the same name for OpenSSL and mbedTLS, we do
* this dance.
+ * Also note that the code is wrong in the presence of OpenSSL3 providers.
*/
int groups_count = get_num_elements(groups, ':');
@@ -617,6 +619,13 @@ tls_ctx_set_tls_groups(struct tls_root_ctx *ctx, const
char *groups)
groups);
}
gc_free(&gc);
+#else
+if (!SSL_CTX_set1_groups_list(ctx->ctx, groups))
+{
+crypto_msg(M_FATAL, "Failed to set allowed TLS group list: %s",
+ groups);
+}
+#endif
}
void
--
2.17.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Enable usage of TLS groups not identified by a NID in OpenSSL 3
Am 29.03.22 um 12:28 schrieb Gert Doering: Hi, On Tue, Mar 29, 2022 at 07:37:09AM +0200, Michael Baentsch wrote: From: Michael <57787676+baent...@users.noreply.github.com> OpenSSL3 prefers to specify groups (including EC groups) with names instead of NID to allow also groups provided by providers. This commit also removes the mapping of secp256r1 to prime256v1 for the OpenSSL3 code path as OpenSSL 3.0 recognises secp256r1.1 --- If Arne is fine with the actual change, I think the commit message is good to go. The "From:" line (which is what git recorded as author) is a bit weird - if you're fine with that, I'll use your e-mail From: instead, also for the "signed-off-by:" header. What do you consider weird in there? My name is Michael and I prefer to not use a real email address in git commit messages: <57787676+baent...@users.noreply.github.com> is the ID github assigned to my "baentsch" github ID . But then again, OpenVPN is not using github, so linking to that ID won't work anyway... So, OK, go ahead and use "Michael Baentsch (i...@baentsch.ch)" as From: (The exact meaning of the signed-off-by: is a bit fuzzy to me - our developer docs say "patch is ready to be applied", but they also say "if it is missing, the value of From: is used". Some other voices interpret it as "yes, I've read the project guidelines and license, and agree to them"...) gert Thanks in advance, --Michael ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
