Re: [Openvpn-devel] [PATCH] Bugfix: Convert ECDSA signature form pkcs11-helper to DER encoded form

2023-03-14 Thread David Sommerseth
On 11/03/2023 06:24, selva.n...@gmail.com wrote: From: Selva Nair - With OpenSSL 3.0 and xkey-provider, we use pkcs11h_certificate_signAny_ex() which returns EC signature as raw r|s concatenated. But OpenSSL expects a DER encoded ASN.1 structure. Do this conversion as done in cryptoap

Re: [Openvpn-devel] [PATCH] Bugfix: Convert ECDSA signature form pkcs11-helper to DER encoded form

2023-03-14 Thread David Sommerseth
On 14/03/2023 09:45, David Sommerseth wrote: On 11/03/2023 06:24, selva.n...@gmail.com wrote: From: Selva Nair - With OpenSSL 3.0 and xkey-provider, we use pkcs11h_certificate_signAny_ex()    which returns EC signature as raw r|s concatenated. But OpenSSL expects    a DER encoded ASN.1 stru

Re: [Openvpn-devel] [PATCH] Bugfix: Convert ECDSA signature form pkcs11-helper to DER encoded form

2023-03-14 Thread David Sommerseth
On 14/03/2023 10:02, David Sommerseth wrote: On 14/03/2023 09:45, David Sommerseth wrote: On 11/03/2023 06:24, selva.n...@gmail.com wrote: From: Selva Nair - With OpenSSL 3.0 and xkey-provider, we use pkcs11h_certificate_signAny_ex()    which returns EC signature as raw r|s concatenated. But

[Openvpn-devel] [PATCH v2] Bugfix: Convert ECDSA signature form pkcs11-helper to DER encoded form

2023-03-14 Thread selva . nair
From: Selva Nair - With OpenSSL 3.0 and xkey-provider, we use pkcs11h_certificate_signAny_ex() which returns EC signature as raw r|s concatenated. But OpenSSL expects a DER encoded ASN.1 structure. Do this conversion as done in cryptoapi.c. For code re-use, ecdsa_bin2sig() is consolidate

Re: [Openvpn-devel] [PATCH] Bugfix: Convert ECDSA signature form pkcs11-helper to DER encoded form

2023-03-14 Thread Selva Nair
Hi, On Tue, Mar 14, 2023 at 5:54 AM David Sommerseth wrote: > > > Just got feedback from the reporter in the Fedora bugzilla; this patch > works well on Fedora 38. > > I suggest adding this tag to the commit log. Feel free to add the URL > tag to the bugzilla ticket too. > > Tested-by: flor...@

[Openvpn-devel] [PATCH v3] Fix memory leaks in HMAC initial packet id and dco open tun

2023-03-14 Thread Arne Schwabe
The open_tun_dco_generic already allocates the actual_name string, this shadows the allocation in the FreeBSD/Linux specific methods. The HMAC leaks are just forgotten frees/deinitialisations. tls_wrap_control will sometimes return the original buffer (non tls-crypt) and sometimes tls_wrap.work, h

Re: [Openvpn-devel] [PATCH v3] Fix memory leaks in HMAC initial packet id and dco open tun

2023-03-14 Thread Gert Doering
Hi, On Tue, Mar 14, 2023 at 02:09:31PM +0100, Arne Schwabe wrote: > The open_tun_dco_generic already allocates the actual_name string, this > shadows the allocation in the FreeBSD/Linux specific methods. > > The HMAC leaks are just forgotten frees/deinitialisations. tls_wrap_control > will someti

[Openvpn-devel] [PATCH 1/2] Fix memory leaks in HMAC initial packet id

2023-03-14 Thread Arne Schwabe
The HMAC leaks are just forgotten frees/deinitialisations. tls_wrap_control will sometimes return the original buffer (non tls-crypt) and sometimes tls_wrap.work, handling this buffer lifetime is a bit more complicated. Instead of further complicating that code just give our work buffer the same li

[Openvpn-devel] [PATCH 2/2] Fix memory leaks in dco open tun

2023-03-14 Thread Arne Schwabe
The open_tun_dco_generic already allocates the actual_name string, this shadows the allocation in the FreeBSD/Linux specific methods. Found-By: clang with asan Change-Id: I51f5fcfff4e5f8203fdb9aec0245cfccd17043cc Signed-off-by: Arne Schwabe --- src/openvpn/dco_freebsd.c | 1 - src/openvpn/dco_li

[Openvpn-devel] [PATCH applied] Re: Fix memory leaks in dco open tun

2023-03-14 Thread Gert Doering
Acked-by: Gert Doering This one is fairly straightforward (and the leak is small) - I've re-read all the code involved for v2 of the patch (set) and the change is correct. The device name involved stays unchanged in the current iterations of open_tun_dco(), so there is no need to save it there (

[Openvpn-devel] [PATCH 0/4] Add some tests for cryptoapi.c functions

2023-03-14 Thread selva . nair
From: Selva Nair Import some sample certificates into Windows store for testing - 4 test certificates&keys imported to user store and removed at the end. Add tests for finding certificates in Windows certficate store - test using SUBJ:, THUMB: and ISSUER: select-strings Refa

[Openvpn-devel] [PATCH 3/4] Refactor SSL_CTX_use_CryptoAPI_certificate()

2023-03-14 Thread selva . nair
From: Selva Nair - Loading the certificate and key into the provider is split out of setting up the SSL context. This allows testing of signing by cryptoapi-provider interface without dependence on SSL context or link-time wrapping. Change-Id: I269b94589636425e1ba9bf953047d238fa830376 Sign

[Openvpn-devel] [PATCH 2/4] Add tests for finding certificates in Windows cert store

2023-03-14 Thread selva . nair
From: Selva Nair - find_certificate_in_store tested using 'SUBJ:', 'THUMB:' and 'ISSUER:' select strings. Uses test certificates imported into the store during the import test. Change-Id: Ib5138465e6228538af592ca98b3d877277355f59 Signed-off-by: Selva Nair --- tests/unit_tests/openvpn/test_

[Openvpn-devel] [PATCH 4/4] Add a test for signing with certificates in Windows store

2023-03-14 Thread selva . nair
From: Selva Nair - For each sample certificate/key pair imported into the store, load the key into xkey-provider and sign a test message. As the key is "provided", signing will use appropriate backend (Windows CNG in this case). The signature is then verified using OpenSSL. Change-Id: I

[Openvpn-devel] [PATCH 1/4] Import some sample certificates into Windows store for testing

2023-03-14 Thread selva . nair
From: Selva Nair - A few sample certificates are defined and imported into Windows certificate store (user store). This only tests the import process. Use of these certs to test the core functionality of 'cryptoapicert' are in following commits. Change-Id: Ida5fc12c5bad5fde202da0bf0e8cdc71