ept any form other than
what Arne proposed. Unless we define pubkeys[] using the three string
literals directly and eliminate those intermediate vars (pubkey1, 2, 3).
.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
In case this request was lost, here goes again. Can we have this
cherry-picked into 2.5 before the next release?
Selva
On Thu, Aug 11, 2022 at 4:03 PM Selva Nair wrote:
> Hi,
>
> On Tue, Aug 2, 2022 at 8:02 AM Gert Doering wrote:
>
>> Acked-by: Gert Doering
>>
>&
. Isn't a warning
that persist-tun is not supported enough?
(ii) windows-driver ovpn-dco (without the trailing -win) would be better?
"windows" is already there in the option name.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourc
In some sense this is a "bug fix" though the fix itself is a band-aid as
opposed to implementing a command queue to save these write actions instead
of dropping them.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
se changes to installer, we don't need this code
> in openvpnmsica.
>
> Signed-off-by: Lev Stipakov
> ---
> src/openvpnmsica/openvpnmsica.c | 115
> 1 file changed, 115 deletions(-)
>
With PR261 in openvpn-build merged, this is now ready.
A
From: Selva Nair
Without this, replies to commands from the management client
are sometimes lost if the server is writing when a command
comes in and leads to a recursive call to this function.
For some reason I've not been able to trigger this on Linux,
but it does sometimes happen on Windows
From: Selva Nair
Generally we expect a response of SUCCESS: or ERROR: to every
command sent to the management interface. But, while in
the management-hold state, sending "signal foo" returns only
the following reply (with foo = SIGHUP, SIGUSR1 etc.):
>HOLD:Waiting for hold r
From: Selva Nair
v2: also fix building test_provider
- ifdefs in test_provider.c
- include integer.h for min_int as manage.h
may not always pull it in
Too many ifdefs, unfortunately..
Signed-off-by: Selva Nair
---
src/openvpn/xkey_helper.c| 4
tests/unit_tests
From: Selva Nair
Signed-off-by: Selva Nair
---
src/openvpn/xkey_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/openvpn/xkey_helper.c b/src/openvpn/xkey_helper.c
index 81dd71dc..27e87d79 100644
--- a/src/openvpn/xkey_helper.c
+++ b/src/openvpn/xkey_helper.c
@@ -85,6 +85,7
ncluding pkcs11 and cryptoapicert, so we
need it even when management is disabled.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
not
allowed).
As one cannot control when a user may hit reconnect, this needs to be
fixed.
Would it be okay to allow a few levels of recursion in
virtual_output_callback? One seldom sends more than a couple of commands in
a succession especially when not prompted by the daemon. Allowing
recursi
From: Selva Nair
The correct errno can get overwritten by the call to
format_extended_socket_error() which may set errno to EAGAIN
losing the original error and cause to bypass the error reporting
below. Fix by reading the errno of interest at the top of the
function.
Reported by: Gert Doering
ich calls recvmsg() which can
easily return EAGAIN in errno. To top it, EAGAIN is completely ignored by
ignore_sys_error(), so we get nothing printed. I think moving those line
back up to the start of the function should fix this
Selva
>
> I can see that the patch at least touches code cl
Hi,
Any thoughts on this? Apart from the broken msvc builds that led to this,
looks like the right thing to do, isn't it?
Selva
On Wed, Jul 6, 2022 at 11:52 PM wrote:
> From: Selva Nair
>
> The function signature for xkey_load_generic_key had
> function pointers defined as fu
From: Selva Nair
The function signature for xkey_load_generic_key had
function pointers defined as function types that seems
to work in gcc but not in msvc.
Fix it by changing the function signatures to what was
intended.
Also revert part of commit 627d1a3d28638... as that work-
around should
sometimes test mingw builds against some client-server setups, but msvc
builds may not be getting exercised enough --- especially with OpenSSL 3.0.
Thanks,
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net
Hi
On Mon, Jul 4, 2022 at 5:50 AM Arne Schwabe wrote:
> Am 04.07.22 um 04:58 schrieb selva.n...@gmail.com:
> > From: Selva Nair
> >
> > When auth-token verify succeeds during a reauth, other auth
> > methods (plugin, script, management) are skipped unless
>
From: Selva Nair
When auth-token verify succeeds during a reauth, other auth
methods (plugin, script, management) are skipped unless
external-auth is in effect (skip_auth gets set to true).
However, in this case, the status of management-def-auth
(ks->mda_satus) stays at its default va
From: Selva Nair
Use of this has never been documented and the code was
dead for a long while now.
Signed-off-by: Selva Nair
---
Alternative for [PATCH 2/3] Reactivate record_peer_info in manage.c
src/openvpn/init.c| 1 -
src/openvpn/manage.c | 49
From: Selva Nair
Currently when we are listening on the management
interface, the local address/port is logged as that of
the connecting client.
Fix it.
Signed-off-by: Selva Nair
---
src/openvpn/manage.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff
From: Selva Nair
--management-client has an obscure and undocumented feature
to take a file argument where the peer's address and port are
recorded. This has become dead code over time.
- reactivate the dead code
- make it work with v6 addresses as well
- do not exit on error in writing
From: Selva Nair
When the port is specified as zero, log the actual port
bound to, instead of 0.
Signed-off-by: Selva Nair
---
src/openvpn/manage.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index
== ERROR_IO_INCOMPLETE))
> +{
> +Sleep(delay_millisec);
While this may be ok assuming it's not inside any performance critical
loops, no need to force this on newer versions of mingw-w64.
Alternatively, we could use AC_CHECK_FUNC to make this conditional or find
the symbol Get
Hi,
On Thu, Jun 23, 2022 at 8:43 AM David Sommerseth <
open...@sf.lists.topphemmelig.net> wrote:
> On 19/6/2022 19:28, Selva Nair wrote:
> > Hi,0
> >
> > On Thu, Sep 30, 2021 at 7:34 AM Petr Mikhalicin via Openvpn-devel
> > > <mailto:openvpn-devel@lists.s
hould know what flags to pass
--- not the user --- isn't it? If CKF_OS_LOCKING_OK is required, can't we
just set it unconditionally?
That said, OpenVPN2 is single threaded, so why is there a "bug in openvpn"
related to the use of pkcs11 library from
Hi,
Thanks for the new version. Looks good (only compile tested).
Acked-by: Selva Nair
Selva
On Mon, May 16, 2022 at 6:49 AM Arne Schwabe wrote:
>
> OpenSSL's implementation of ED448 and ED25519 has a few idiosyncrasies.
> Instead of belonging to the elliptic curve type or to
Hi,
Thanks for the v2. I'm ready to ack this but for one issue (NULL
passed to OSSL_PARAM_construct_utf8_string).
On Fri, May 13, 2022 at 9:05 AM Arne Schwabe wrote:
>
> OpenSSL's implementation of ED448 and ED25519 has a few idiosyncrasies.
> Instead of belonging to the eliptic curve type or
Acked-by: Selva Nair
Same as the patch 2429 <https://patchwork.openvpn.net/patch/2429/> for
master except for the minor change in x_check_status() to match 2.5.
On Wed, May 4, 2022 at 5:13 AM Lev Stipakov wrote:
> From: Lev Stipakov
>
> We use M_ERRNO flag in logging to dis
,hashalg=SHA256,saltlen=digest"));
> }
> @@ -328,13 +337,13 @@ xkey_sign(void *handle, unsigned char *sig, size_t
> *siglen,
> assert_memory_equal(tbs, test_digest, sizeof(test_digest));
> }
>
> -/* For the test use sha256 and PSS padding for RSA */
&g
{
> struct gc_arena gc = gc_new();
> msg(D_MANAGEMENT, "MANAGEMENT: TCP %s error: %s", prefix,
> diff --git a/src/openvpn/platform.c b/src/openvpn/platform.c
> index 61afee83..ae1678db 100644
> --- a/src/open
O, "socks_handshake: TCP port read
> failed on recv()");
> +msg(D_LINK_ERRORS | M_SKERR, "socks_handshake: TCP port read
> failed on recv()");
> return false;
> }
>
> @@ -342,14 +342,14 @@ recv_socks_reply(socket_descriptor_t sd,
>
Hi Jacob,
On Fri, Mar 11, 2022 at 3:52 AM Jakob Curdes wrote:
> Hello Selva, hello all,
>
> I have tested the executable in the circumstances described earlier. I
> confirm the problem described (username/password auth succeeds, but second
> auth with 2FA data fails a
Hi,
On Thu, Mar 10, 2022 at 4:23 PM Gert Doering wrote:
> Hi,
>
> On Thu, Mar 10, 2022 at 12:51:51PM -0500, Selva Nair wrote:
> > I missed this follow up on the devel list. Please see my reply to
> > openvpn-users. If @ doesnt work there is no easy fix short of patching
>
nd in the firebox.
> When using the WatchGuard SSL VPN app this all works (and it has OpenVPN
> inside) but I would like to stick to the OpenVPN clients as all the
> users already have it and know how to handle it.
>
I missed this follow up on the devel list. Please see my reply to
openvpn-users. If @ doesnt work there is no easy fix short of patching the
GUI.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
strerror() in check_status() (error.c)
missed by the original patch.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
From: Selva Nair
Reported-by: Arne Schwabe
Signed-off-by: Selva Nair
---
src/openvpn/pkcs11_openssl.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/openvpn/pkcs11_openssl.c b/src/openvpn/pkcs11_openssl.c
index a82b4b32..c4f88816 100644
--- a/src/openvpn
On Wed, Jan 26, 2022 at 6:50 AM Arne Schwabe wrote:
> Am 25.01.22 um 03:51 schrieb selva.n...@gmail.com:
> > From: Selva Nair
> >
> > - Call pkcs11h_certificate_signAny_ex() when available
> >so that the signature mechanism parameters can be pased.
> >
On Sun, Aug 15, 2021 at 6:26 PM wrote:
> From: Selva Nair
>
> v2 changes
> - do not allow so-path embedded in cert and key uri
> - add --pkcs11-engine option to optionally specify the
> engine and provider module to use
> v3: rebase to master
>
>
t; wiping streq() for good?
>
"live with" ? When did strcmp() become a pariah?
Though strcmp()'s naming and return value are arguably not intuitive, we
are all used to it. That said, we have 472 uses of streq(), so let it be.
Just do not require that one should be preferred over the other.
Consistency is a good goal, but let's not be pedantic about it.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
From: Selva Nair
D_XKEY = loglev(6, 69, M_DEBUG) is defined and used for
all low level debug messages from xkey_provider.c and
xkey_helper.c
As suggested by Arne Schwabe
Signed-off-by: Selva Nair
---
src/openvpn/errlevel.h | 1 +
src/openvpn/xkey_helper.c | 8 +--
src/openvpn
From: Selva Nair
(nbits - 1)/8 should have been rounded up. Fix and move it to
an inlined function for reuse in pkcs11_openssl.c (used in the
next commit).
Note: The error is not triggered in normal use as OpenSSL
always seems to use saltlen="digest" for signing.
Signed-off-by:
From: Selva Nair
- Call pkcs11h_certificate_signAny_ex() when available
so that the signature mechanism parameters can be pased.
(Required for RSA-PSS signature).
Signed-off-by: Selva Nair
---
src/openvpn/pkcs11_openssl.c | 123 +--
1 file changed, 118
= {
> };
>
> const OSSL_ALGORITHM signatures[] = {
> -{"RSA:rsaEncryption", props, signature_functions, "OpenVPN xkey RSA
> Signature"},
> -{"ECDSA", props, signature_functions, "OpenVPN xkey ECDSA Signature"},
> +{"RSA:rsaEncryption", XKEY_PROV_PROPS, signature_functions, "OpenVPN
> xkey RSA Signature"},
> +{"ECDSA", XKEY_PROV_PROPS, signature_functions, "OpenVPN xkey ECDSA
> Signature"},
> {NULL, NULL, NULL, NULL}
> };
Acked-by: Selva Nair
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
could do that, but then commit without those changes will break the
> build.
>
Your fix to the xkey patch set is actually a generic one, not just a
work-around for msvc. It could be applied first before fixing the msvc
build.
Selva
___
Openvpn
ot;${CURRENT_PORT_DIR}/usage"
> DESTINATION "${CURRENT_PACKAGES_DIR}/share/${PORT}"
> -)
> \ No newline at end of file
> +)
>
A whole patch in the commit message is not very helpful and makes it hard
to read. Why not include this patch + the original, and apply the
misplaced in crypto.c. That file should be ssl-lib agnostic and openssl
related bits should go to crypto_openssl.c...
I think we need to remove that OPENSSL_FIPS clause and think of providing
that extra info somewhere else if possible.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
From: Selva Nair
An easy way to trigger this error is to run an otherwise working setup
(at say verb = 4) with increased verbosity of verb >= 7 and using a GCM
cipher (e.g., AES-256-GCM). It will cause a fatal exit while printing the
cipher and hmac in key2_print().
Signed-off-by: Selva N
rc/openvpn/tun.h b/src/openvpn/tun.h
> index d4657537..a6661be0 100644
> --- a/src/openvpn/tun.h
> +++ b/src/openvpn/tun.h
> @@ -437,8 +437,6 @@ int tun_read_queue(struct tuntap *tt, int maxsize);
>
> int tun_write_queue(struct tuntap *tt, struct buffer *buf);
>
> -int tun_finalize(HANDLE h, struct overlapped_io *io, struct buffer *buf);
> -
> static inline bool
> tuntap_stop(int status)
> {
> @@ -466,36 +464,8 @@ tuntap_abort(int status)
> return false;
> }
>
> -static inline int
> -tun_write_win32(struct tuntap *tt, struct buffer *buf)
> -{
> -int err = 0;
> -int status = 0;
> -if (overlapped_io_active(>writes))
> -{
> -status = tun_finalize(tt->hand, >writes, NULL);
> -if (status < 0)
> -{
> -err = GetLastError();
> -}
> -}
> -tun_write_queue(tt, buf);
> -if (status < 0)
> -{
> -SetLastError(err);
> -return status;
> -}
> -else
> -{
> -return BLEN(buf);
> -}
> -}
> -
> -static inline int
> -read_tun_buffered(struct tuntap *tt, struct buffer *buf)
> -{
> -return tun_finalize(tt->hand, >reads, buf);
> -}
> +int
> +tun_write_win32(struct tuntap *tt, struct buffer *buf);
>
Antonio wanted this to be in one line though we are not terribly consistent
about this.
> static inline ULONG
> wintun_ring_packet_align(ULONG size)
>
In spite of those nits meant to annoy the author, I think this looks good.
Acked-by: Selva Nair
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
latforms (only Android for
now?). Although it's a nifty option that could potentially be leveraged to
remove pkcs11-helper, CNG etc out of OpenVPN core.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
From: Selva Nair
As pointed out by Gert Doering
Signed-off-by: Selva Nair
---
To be applied after 06/18 of xkey patchset
src/openvpn/ssl_openssl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index b48845eb..3f8c3091 100644
From: Selva Nair
Tests:
- Check SIGNATURE and KEYMGMT methods can be fetched
from the provider
- Load sample RSA and EC keys as management-external-key
and check that their sign callbacks are correctly exercised:
with and without digest support mocked in the client
capability flag
Hi
On Thu, Jan 20, 2022 at 9:51 AM Gert Doering wrote:
> Hi,
>
> On Tue, Dec 14, 2021 at 11:59:27AM -0500, selva.n...@gmail.com wrote:
> > From: Selva Nair
> >
> > Signed-off-by: Selva Nair
>
> Is it OK if I squash 16+17 together? I dislike the "hist
need to check that cipher is not NULL. Fetch can return NULL while
EVP_CIPHER_flags() requires a non-null argument. Something like: if (cipher
&& FIPS_mode && etc...) will do.
EVP_CIPHER_free() below can handle NULL, so no problem there.
{
> printf(", disabled
Hi,
On Sat, Jan 15, 2022 at 3:25 AM Antonio Quartulli wrote:
>
> Hi Selva,
>
> we were hoping to hear your opinion on this :-)
>
> We spent quite some time figuring out if we have to use both the non-WSA
> and the WSA variant of the API in our code, and it seems we have
Acked-By: Selva Nair
On Mon, Dec 27, 2021 at 3:17 PM Gert Doering wrote:
>
> - 2.5.3 had a typo in the CVE ID (CVE-2121-3606 should be -2021-)
> - 2.5.5 had windows paths with backslashes, which need to be doubled
>
> (CVE ID typo also reported by "@attritionorg" in G
the folder as "ssl" it is arguably "more
correct" to use the lowercase name in documentation as that's how it
will show up in the file system. I haven't checked what case the
installer uses. Just nit-picking.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
From: Selva Nair
Signed-off-by: Selva Nair
---
src/openvpn/openvpn.vcxproj | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
index 65ee6839..2f0cee60 100644
--- a/src/openvpn/openvpn.vcxproj
+++ b/src/openvpn/openvpn.vcxproj
From: Selva Nair
- Load the 'private key' handle through the provider and set it in
SSL_CTX
- Add a sign op function to interface provider with pkcs11-helper.
Previously we used its "OpenSSL Session" which internally sets up
callbacks in RSA and EC key methods. Not useful for th
From: Selva Nair
- Add xkey_cng_sign() as sign_op for the provider
and load the key using xkey_generic_load.
- Enable/Disable old code when provider is available or not.
- xkey_digest is made non-static for use in cryptoapi.c
One function cng_padding_type() is moved down to reduce number
From: Selva Nair
Sending largish messages to the management interface errors due to
the limited size used for the "error" buffer in x_msg_va(). Although
all intermediate steps allocate required space for the data to
send, it gets truncated at the last step.
This really requires a s
From: Selva Nair
Our key object retains info about the external
key as an opaque handle to the backend. We also
need the public key as an EVP_PKEY *.
For native keys we use OpenSSL API to import
data into the key. The 'handle' representing the
private key in that case is the OpenSSL
From: Selva Nair
A minimal set of functions for keymgmt are implemented.
No support for external key import as yet, only native
keys. Support for native keys is required as keys may
get imported into us for some operations as well as
for comparison with unexportable external keys that we hold
From: Selva Nair
- Leverage keymgmt_import through EVP_PKEY_new_fromdata() to
import "management-external-key"
- When required, use this to set SSL_CTX_use_PrivateKey
The sign_op is not implemented yet. This will error out while
signing with --management-external-key. The next co
From: Selva Nair
- Load keys by specifying the opaque privtae key handle,
public key, sign-op and free-op required for loading keys
from Windows store and pkcs11.
- xkey_load_management_key is refactored to use the new function
- Also make xkey_digest non-static
Used in following commits
From: Selva Nair
- Basic frame work for announcing support for signature
operations
- DigestSign and Sign functions for native keys are also
implemented. Though strictly not needed, these functions
for native keys sets up the framework for signature operations.
They also help loading
From: Selva Nair
Support for padding algorithms in management-client is indicated
in the optional argument to --management-external-key as "pkcs1",
"pss" etc. We currently use it only for an early exit based on heuristics
that a required algorithm may not be handled by the cl
From: Selva Nair
Hooking into callbacks in RSA_METHOD and EVP_PKEY_METHOD
structures is deprecated in OpenSSL 3.0. For signing with
external keys that are not exportable (tokens, stores, etc.)
requires a custom provider interface so that key operations
are done under its context.
A single
From: Selva Nair
To receive undigested message for signing, indicate support
for handling message digesting in the client using an argument
"digest" to --management-external-key.
For example, to announce pkcs1 padding and digesting support use:
--management-external-key pkcs1
From: Selva Nair
Tests:
- Check SIGNATURE and KEYMGMT methods can be fetched
from the provider
- Load sample RSA and EC keys as management-external-key
and check that their sign callbacks are correctly exercised:
with and without digest support mocked in the client
capability flag
From: Selva Nair
The --management-external-key option can currently indicate support
for 'nopadding' or 'pkcs1' signatures in the client. Add 'pss' as an
option to announce that PSS signing requests are accepted.
To match, extend the algorithm string in PK_SIGN request to
include the following
From: Selva Nair
The following series of patches implement a built-in
provider for interfacing OpenSSL 3.0 when external
keys are in use.
Essentially, to intercept the sign operation, the SSL_CTX
object has to be created with properties string set to
prioritize our provider. In the provider
From: Selva Nair
- Add function to check when external key is in use
- Load xkey provider into a custom library context when required
- Use the custom libctx in SSL CTX when external key is in use
As no keys are yet loaded through the provider,
no functionality gets delegated to it as yet
From: Selva Nair
The EVP_PKEY interface as well as provider passes the raw
digest to the sign() function. In case of RSA_PKCS1,
our management interface expects an encoded hash, which
has the DigestInfo header added as per PKCSv1.5 specs,
unless the hash algorithm is legacy MD5_SHA1.
Fix
From: Selva Nair
- Add a function to set as sign_op during key import. The
function passes the signature request to management interface,
and returns the result to the provider.
v2 changes: Method to do digest added to match the changes in
the provider signature callback.
TODO
From: Selva Nair
Signed-off-by: Selva Nair
---
configure.ac | 2 -
tests/unit_tests/openvpn/Makefile.am | 4 -
tests/unit_tests/openvpn/test_provider.c | 112 +--
3 files changed, 105 insertions(+), 13 deletions(-)
diff --git
cipher_defined() called with NULL ciphername from init.c). That said I
had missed the missing ! in cipher_defined() in tls_crypt.c (now
fixed) and test failures that Gert identified...
Selva
> ---
> src/openvpn/auth_token.c | 2 +-
> src/openvpn/crypto.c
quot;;
}
+/* Do not warn if the cipher is used only in OCC */
+bool warn = options->enable_ncp_fallback;
+init_key_type(>c1.ks.key_type, ciphername, options->authname,
+ true, warn);
+
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
st char* optstr = optional ? "optional ": "";
> msg(M_WARN, "Unsupported %scipher in --data-ciphers: %s",
> optstr, token);
> @@ -138,8 +138,8 @@ mutate_ncp_cipher_list(const char *list, struct gc_arena
> *gc)
> }
> else
> {
> -const char *ovpn_cipher_name = cipher_kt_name(ktc);
> -if (ktc == NULL)
> +const char *ovpn_cipher_name = cipher_kt_name(token);
> +if (nonecipher)
> {
> /* NULL resolves to [null-cipher] but we need none for
> * data-ciphers */
> @@ -466,17 +466,17 @@ p2p_mode_ncp(struct tls_multi *multi, struct
> tls_session *session)
> if (!common_cipher)
> {
> struct buffer out = alloc_buf_gc(128, );
> -const cipher_kt_t *cipher = session->opt->key_type.cipher;
> -
> /* at this point we do not really know if our fallback is
> * not enabled or if we use 'none' cipher as fallback, so
> * keep this ambiguity here and print fallback-cipher: none
> */
>
> const char *fallback_name = "none";
> -if (cipher)
> +const char *ciphername = session->opt->key_type.cipher;
> +
> +if (cipher_defined(ciphername))
> {
> -fallback_name = cipher_kt_name(cipher);
> +fallback_name = cipher_kt_name(ciphername);
> }
>
> buf_printf(, "(not negotiated, fallback-cipher: %s)",
> fallback_name);
> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
> index 80ed9684e..887943d74 100644
> --- a/src/openvpn/tls_crypt.c
> +++ b/src/openvpn/tls_crypt.c
> @@ -51,10 +51,10 @@ static struct key_type
> tls_crypt_kt(void)
> {
> struct key_type kt;
> -kt.cipher = cipher_kt_get("AES-256-CTR");
> +kt.cipher = "AES-256-CTR";
> kt.digest = md_kt_get("SHA256");
>
> -if (!kt.cipher)
> +if (cipher_valid(kt.cipher))
> {
> msg(M_WARN, "ERROR: --tls-crypt requires AES-256-CTR support.");
> return (struct key_type) { 0 };
> diff --git a/tests/unit_tests/openvpn/test_crypto.c
> b/tests/unit_tests/openvpn/test_crypto.c
> index 42632c72b..344817eef 100644
> --- a/tests/unit_tests/openvpn/test_crypto.c
> +++ b/tests/unit_tests/openvpn/test_crypto.c
> @@ -72,7 +72,7 @@ crypto_pem_encode_decode_loopback(void **state)
> static void
> test_translate_cipher(const char *ciphername, const char *openvpn_name)
> {
> -const cipher_kt_t *cipher = cipher_kt_get(ciphername);
> +bool cipher = cipher_valid(ciphername);
>
> /* Empty cipher is fine */
> if (!cipher)
> @@ -80,7 +80,7 @@ test_translate_cipher(const char *ciphername, const char
> *openvpn_name)
> return;
> }
>
> -const char *kt_name = cipher_kt_name(cipher);
> +const char *kt_name = cipher_kt_name(ciphername);
>
> assert_string_equal(kt_name, openvpn_name);
> }
> diff --git a/tests/unit_tests/openvpn/test_ncp.c
> b/tests/unit_tests/openvpn/test_ncp.c
> index 6702133ad..92e7ce936 100644
> --- a/tests/unit_tests/openvpn/test_ncp.c
> +++ b/tests/unit_tests/openvpn/test_ncp.c
> @@ -59,8 +59,8 @@ static void
> test_check_ncp_ciphers_list(void **state)
> {
> struct gc_arena gc = gc_new();
> -bool have_chacha = cipher_kt_get("CHACHA20-POLY1305");
> -bool have_blowfish = cipher_kt_get("BF-CBC");
> +bool have_chacha = cipher_valid("CHACHA20-POLY1305");
> +bool have_blowfish = cipher_valid("BF-CBC");
>
> assert_string_equal(mutate_ncp_cipher_list("none", ), "none");
> assert_string_equal(mutate_ncp_cipher_list("AES-256-GCM:none", ),
> @@ -100,7 +100,7 @@ test_check_ncp_ciphers_list(void **state)
>
> /* For testing that with OpenSSL 1.1.0+ that also accepts ciphers in
> * a different spelling the normalised cipher output is the same */
> -bool have_chacha_mixed_case = cipher_kt_get("ChaCha20-Poly1305");
> +bool have_chacha_mixed_case = cipher_valid("ChaCha20-Poly1305");
> if (have_chacha_mixed_case)
> {
>
> assert_string_equal(mutate_ncp_cipher_list("AES-128-CBC:ChaCha20-Poly1305",
> ),
Mixed use of TYPE* x and TYPE *x in a number of places. We prefer TYPE
*x, though I wont insist.
The rest looks good though I did not test.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
could set these env vars if not already
set by the user.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
in the man page where we can document this.
These are not env vars we natively support so putting it under a section
named "ENVIRONMENT VARIABLES" does not seem right. Also we already have a
section with that name which refer to env vars we export to scripts.
Selva
___
+{
> +WCHAR val[MAX_PATH] = {0};
> +openvpn_swprintf(val, _countof(val), L"%ls\\ssl\\%ls",
> install_path, ossl_env[i].value);
> +_wputenv_s(ossl_env[i].name, val);
> +}
> +}
> +}
> +
> #endif /* ifdef _WIN32
Hi,
On Tue, Nov 23, 2021 at 1:37 PM Lev Stipakov wrote:
> I don't have a setup to properly test it, like actually loading the
> config - I only checked that the openvpn.exe attempted to access
> openssl.cnf at the correct location.
>
> If someone wants to test - binary artifacts could be found
mory passed to _wputenv(),
> I checked MS documentation, and it does not say anything.
>
MS docs say _putenv is their implementation of POSIX putenv but the latter
does imply the pointer supplied by the user should be used as is. Anyway,
if it works with automatics, good for us.
>
overriding these locations which is the original purpose of env
vars.
> +}
> +
> #endif /* ifdef _WIN32 */
> diff --git a/src/openvpn/win32.h b/src/openvpn/win32.h
> index 5d3371a0..4a992d91 100644
> --- a/src/openvpn/win32.h
> +++ b/src/openvpn/win32.h
> @@ -327,7 +327,1
On Mon, Nov 22, 2021 at 4:37 PM Gert Doering wrote:
> Hi,
>
> On Mon, Nov 22, 2021 at 04:33:36PM -0500, Selva Nair wrote:
> > I think setting env vars would give us extra protection as we can detect
> > the actual location of Program Files or executable's path at run time.
g mingw which is
much easier to handle.
I think setting env vars would give us extra protection as we can detect
the actual location of Program Files or executable's path at run time.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
nstalling to a private path for development
would be to do a "prefix relocation" using DESTDIR:
make DESTDIR=/home/selva/openssl-pkg/ install
which will preserve the search paths compiled into the library. This will
work for cross-compile on linux even with drive letters in prefix, though
usable.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
sing our
new "--providers" option will get loaded from there. Also we have to
distribute the dll for the legacy provider which will go into the
MODULESDIR.
Users can override these using env vars but the built-in values should
point to read-only locations.
Selva
_
ot;?
output for OPENSSLDIR, ENGINESDIR and MODULESDIR? The last one is for
OpenSSL 3+ only and indicates the default location of provider modules like
"legacy".
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
nd, based on your tests 0 does work
on all platforms we support. Same was my conclusion the last time I
checked.
So I would also vote for the current patch as is.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.source
warning if the option is used.
I think we should add this option to --help only for OpenSSL. And,
while parsing, add provider names to the list only for OpenSSL, show a
warning for mbedTLS. That way the list will remain empty for mbedTLS.
I'm supposing that we do not want --provider t
3.0
though.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
quot;;
> }
> }
> +else if (streq(p[0], "providers") && p[1])
> +{
> +for (size_t j = 1; j < MAX_PARMS && p[j] != NULL;j++)
> +{
> +options->providers.names[j] = p[j];
> +}
> +}
>
.names[j] = p[j];
> +}
> +}
> #endif /* ENABLE_CRYPTO_MBEDTLS */
> #ifdef ENABLE_PREDICTION_RESISTANCE
> else if (streq(p[0], "use-prediction-resistance") && !p[1])
> diff --git a/src/openvpn/options.h b/src/openvpn/options.h
> index 20b34ed4e..d4f41cd71 100644
> --- a/src/openvpn/options.h
> +++ b/src/openvpn/options.h
> @@ -179,6 +179,14 @@ struct remote_list
> struct remote_entry *array[CONNECTION_LIST_SIZE];
> };
>
> +struct provider_list
> +{
> +/* Names of the providers */
> +const char *names[MAX_PARMS];
> +/* Pointers to the loaded providers to unload them */
> +provider_t *providers[MAX_PARMS];
> +};
> +
> enum vlan_acceptable_frames
> {
> VLAN_ONLY_TAGGED,
> @@ -519,6 +527,7 @@ struct options
> const char *ncp_ciphers;
> const char *authname;
> const char *engine;
> +struct provider_list providers;
> bool replay;
> bool mute_replay_warnings;
> int replay_window;
>
The new option is not added to usage_message for --help and usage().
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Hi
On Thu, Nov 11, 2021 at 4:41 AM Lev Stipakov wrote:
> From: Lev Stipakov
>
> This is the rebase of original Selva Nair's patch
> which hasn't been merged:
>
> https://sourceforge.net/p/openvpn/mailman/message/34674818/
Yes, something I wanted 5 years ago
>
>
#msg34674818
Also:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13413.html
and other messages in that thread.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
th OpenSSL
"Configure". Not sure what we do now for MSVC builds. The default
locations are pretty decent as per NOTES.WIN in OpenSSL 1.1.1 tree.
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Hi
On Fri, Nov 5, 2021 at 12:14 PM Arne Schwabe wrote:
> This put the early initialisation and uninitialisation that needs to
> happen between option parsing and post processing into small methods.
>
> Signed-off-by: Arne Schwabe
> ---
> src/openvpn/openvpn.c | 23 ++-
> 1
is version is
tagged v3.
Will post the patches to the list when OpenSSL 3.0.1 is released.
On top of v1 patches this also includes handling pkcs11-id and
cryptoapicert options through the provider. Requires OpenSSL from either
the master branch (3.1.0-dev) or 3.0 branch (3.0.1-dev) post Oct. 27.
Chee
201 - 300 of 1409 matches
Mail list logo
