The previous version has been acked, the only difference is that
this adds temporary gc to avoid storing temp data for the
duration of tunnel.
Again, built and tested with MSVC.
Acked-by: Lev Stipakov
___
Openvpn-devel mailing list
Previous version has been acked, I checked that there are no changes, so
Acked-by: Lev Stipakov
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Builds with MSVC.
Acked-by: Lev Stipakov
ma 17. helmik. 2020 klo 16.44 Arne Schwabe (a...@rfc2549.org) kirjoitti:
>
> Some operating system do not have the strsep function. Since this API
> is more "modern" (4.4BSD) than strtok, add it as compat function.
>
> Signed-off-by: Arne Schwabe
> ---
Stared at the code, built and tested on MSVC and Ubuntu 18.
Acked-by: Lev Stipakov
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Stared at the code, built and tested on MSVC and Ubuntu 18.
Cipher "chacha20-POLY1305" correctly translated into "CHACHA20-POLY1305".
Also (updated) unit tests passed.
Acked-by: Lev Stipakov
___
Openvpn-devel mailing list
Your patch has been applied to the master branch.
(Have stared at the patch a bit and gave it a t_client test run, did
not explicitly test the case without the required ciphers)
commit 868b200c3aef6ee5acfdf679770832018ebc7b70
Author: Arne Schwabe
Date: Mon Feb 17 15:43:35 2020 +0100
Only
Your patch has been applied to the master branch.
I have fixed a few misspellings in the commit message and reformatted
it slightly (git am wraps too long lines, resulting in funny output).
Code lightly tested (t_client) and stared-at-it a bit.
The algorithm is not very smart on the client side
Your patch has been applied to the master branch.
Not much to test here, yet, as we're not calling strsep() anywhere yet
(and I do not have a system without strsep() at hand, all my Unix boxes
have it, even AIX).
commit 0a88ef8c2a6b573f9f21b122bd4818265d39d710
Author: Arne Schwabe
Date: Mon
To clarify - I am not arguing against config_ncp_ciphers in struct tls_options.
The only use of ncp_ciphers in context_1 is this:
to.config_ncp_ciphers = c->c1.ncp_ciphers;
which can be changed to
to.config_ncp_ciphers = options->ncp_ciphers;
which allows us to get rid of added
This allows unit test the NCP functions. The ssl.c file has too
many dependencies to make unit testing of it viable.
Patch V2: Removing the include "ssl_ncp.h" from options.c for V2 of
implement dynamic NCP forces a new version of this patch to
add the #include in this patch.
Our current NCP version is flawed in the way that it can only indicate support
for
AES-256-GCM and AES-128-GCM. While configuring client and server with different
ncp-cipher configuration directive works, the server will blindly push the first
cipher of that list to the client if the client sends
We currently always announce IV_NCP=2 when we support these ciphers even
when we do not accept them. This lead to a server pushing a AES-GCM-128
cipher to clients and the client then rejecting it.
Patch V2: Remove unecessary restoring of ncp_ciphers
Patch V3: Do not add ncp_ciphers in context
In scenarios of mbed TLS vs OpenSSL we already normalise the ciphers
that are send via the wire protocol via OCC to not have a mismatch
warning between server and client. This is done by
translate_cipher_name_from_openvpn. The same applies also to the
ncp-ciphers list. Specifying non normalised
This commit introduces the allow-compression option that allow
changing the new default to the previous default or to a stricter
version.
Warning for comp-lzo/compress are not generated in the post option check
(options_postprocess_mutate) since these warnings should also be shown
on pushed
Tested with MSVC, checked that if --ncp-ciphers options doesn't
include AES-256-GCM,
IV_NCP=2 is indeed not pushed.
Acked-by: Lev Stipakov
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
Am 10.11.19 um 10:55 schrieb David Sommerseth:
> On 09/11/2019 16:46, Steffan Karger wrote:
>>> static void
>>> add_option(struct options *options,
>>> @@ -7322,29 +7339,78 @@ add_option(struct options *options,
>>> }
>>> #endif
>>> #if defined(USE_COMP)
>>> +else if (streq(p[0],
Am 17.02.20 um 10:58 schrieb Lev Stipakov:
> Hi,
>
> Since --ncp-ciphers are non-negotiable, why do we need
> to store it in context_1 at all? Cannot we use the value
> from struct options?
The push context do not have access to the options struct. Using options
directly would be massive
Hi,
Since --ncp-ciphers are non-negotiable, why do we need
to store it in context_1 at all? Cannot we use the value
from struct options?
This can be removed
> +c->c1.ncp_ciphers = c->options.ncp_ciphers;
This
> +to.config_ncp_ciphers = c->c1.ncp_ciphers;
can be changed to
> +
Hi,
On 17/02/2020 09:29, Lev Stipakov wrote:
> From: Lev Stipakov
>
> - remove unneeded _orig variable which stores pointer
> to tokenized string. Unlike strsep(), strtok() doesn't modify
> pointer itself, only string, so it is safe to call free() on that pointer.
>
this makes sense. We can
Hi,
> In the future I suggest splitting unrelated changes like these in
> different patches.
>
Ok, will send v2 with first change only.
> This expression simply checks that token contains a value different from
> NULL. It's like a simple "a != 0" - it doesn't matter where that address
> points
Am 17.02.20 um 10:20 schrieb Lev Stipakov:
> From: Lev Stipakov
>
> Remove unneeded _orig variable, which stores
> pointer to tokenized string. Unlike strsep(), strtok()
> doesn't modify pointer itself, only string, so it is safe
> to call free() on that pointer.
>
Can we just wait with style
From: Lev Stipakov
- remove unneeded _orig variable which stores pointer
to tokenized string. Unlike strsep(), strtok() doesn't modify
pointer itself, only string, so it is safe to call free() on that pointer.
- "token" points to content inside tokenized string. It becomes
dangling pointer
Hi,
On 17/02/2020 10:17, Lev Stipakov wrote:
> Hi,
>
>> In the future I suggest splitting unrelated changes like these in
>> different patches.
>>
>
> Ok, will send v2 with first change only.
>
>> This expression simply checks that token contains a value different from
>> NULL. It's like a
From: Lev Stipakov
Remove unneeded _orig variable, which stores
pointer to tokenized string. Unlike strsep(), strtok()
doesn't modify pointer itself, only string, so it is safe
to call free() on that pointer.
Signed-off-by: Lev Stipakov
---
src/openvpn/ssl.c | 3 +--
1 file changed, 1
Am 17.02.20 um 14:42 schrieb Lev Stipakov:
> Hi,
>
> Tested with Windows server and Linux client, negotiation works.
>
> A few nit-picks, which could be fixed with follow-up patch:
>
>> + * @param gc gc arena that is ONLY used to allocate the returned string
>
> This is not true, since it is
This avoids using the session specific gc arena to hold the temporary
string returned by tls_peer_ncp_list for the whole session.
---
src/openvpn/ssl_ncp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
index
Hi,
Tested with Windows server and Linux client, negotiation works.
A few nit-picks, which could be fixed with follow-up patch:
> + * @param gc gc arena that is ONLY used to allocate the returned string
This is not true, since it is also used inside tls_peer_ncp_list()
to generate temp
Our current NCP version is flawed in the way that it can only indicate support
for
AES-256-GCM and AES-128-GCM. While configuring client and server with different
ncp-cipher configuration directive works, the server will blindly push the first
cipher of that list to the client if the client sends
Resend all patches to make applying them easier and sort them into the order
they should be applied to keep Windows happy
Arne Schwabe (5):
Only announce IV_NCP=2 when we are willing to support these ciphers
Add strsep compat function
Implement dynamic NCP negotiation
Move NCP related
Some operating system do not have the strsep function. Since this API
is more "modern" (4.4BSD) than strtok, add it as compat function.
Signed-off-by: Arne Schwabe
---
configure.ac | 2 +-
src/compat/Makefile.am | 1 +
src/compat/compat-strsep.c | 61
This allows unit test the NCP functions. The ssl.c file has too
many dependencies to make unit testing of it viable.
Patch V2: Removing the include "ssl_ncp.h" from options.c for V2 of
implement dynamic NCP forces a new version of this patch to
add the #include in this patch.
We currently always announce IV_NCP=2 when we support these ciphers even
when we do not accept them. This lead to a server pushing a AES-GCM-128
cipher to clients and the client then rejecting it.
Patch V2: Remove unecessary restoring of ncp_ciphers
Patch V3: Do not add ncp_ciphers in context
In scenarios of mbed TLS vs OpenSSL we already normalise the ciphers
that are send via the wire protocol via OCC to not have a mismatch
warning between server and client. This is done by
translate_cipher_name_from_openvpn. The same applies also to the
ncp-ciphers list. Specifying non normalised
33 matches
Mail list logo
