Replace "servers" with "peers" in the description
of the --redirection-gateway option flag local.
---
doc/openvpn.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 084c5415..e94ab760 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -1184,7
As Antonio pointed out, "8-bit block cipher" is a bit funny. So teach
print_cipher() to print such cipher as "stream cipher".
Because I didn't want to write the same code twice, I decided to merge the
two print_cipher() implementations into one shared function. That should
make it easier to keep
For TLS 1.0 to 1.2 OpenSSL calls us and requires a PKCS1 padded
response, for TLS 1.3 it requires to an unpadded response. Since we
can PCKS1 pad an unpadded response, we prefer to always query for
an unpadded response from the management interface and add the PCKS1
padding ourselves when needed.
OpenSSL 1.1.1 introduces a separate list for TLS 1.3 ciphers. As these
interfaces are meant to be user facing or not exposed at all and we
expose the tls-cipher interface, we should also expose tls-cipherlist.
Combining both settings into tls-cipher would add a lot of glue logic
that needs to be
Hi,
On 07-10-18 22:18, Antonio Quartulli wrote:
> am I missing something?
> 2.12.0 is the first release where my grep command prints something.
No, you're absolutely right. I was misinterpreting my gitk. I'll tackle
this in v2.
-Steffan
___
Hi,
Looks mostly good now. One final nit:
On 07-10-18 22:59, Arne Schwabe wrote:
> OpenSSL 1.1.1 introduces a separate list for TLS 1.3 ciphers. As these
> interfaces are meant to be user facing or not exposed at all and we
> expose the tls-cipher interface, we should also expose tls-cipherlist.
OpenSSL 1.1.1 introduces a separate list for TLS 1.3 ciphers. As these
interfaces are meant to be user facing or not exposed at all and we
expose the tls-cipher interface, we should also expose tls-cipherlist.
Combining both settings into tls-cipher would add a lot of glue logic
that needs to be
Hi,
On 08/10/18 02:13, Steffan Karger wrote:
> On 07-10-18 15:36, Antonio Quartulli wrote:
>> On 07/10/18 21:28, Antonio Quartulli wrote:
+#if defined(MBEDTLS_CHACHAPOLY_C) && (MBEDTLS_VERSION_NUMBER >=
0x020C)
>>>
>>> Why do we need the dual condition? Isn't MBEDTLS_CHACHAPOLY_C
Acked-by: Gert Doering
I have not actually bothered to find a constellation that *would* trigger
an OCC warning (how?) but it compiles and passes tests, and the code looks
reasonable. With added msg() calls I verified that it actually ignores
the options this time.
I have taken the liberty to
On 10/7/18 9:10 AM, Gert Doering wrote:
> Hi,
Hi Gert,
> - most voices argued for "do not require an external library"
>(for *creation*). Not sure if we managed to convince David in
>the end, though :-)
In the meantime I had some "great" experience with manually generating
JSON in
From: Steffan Karger
Like 'proto', a mismatch in key-method, keydir or tls-auth would fail
before we ever get to the point where we can print this warning.
This prepares for removing these from the occ string later on, but also
prepares for tls-crypt-v2, which allows a server to support
Carrying around the INLINE_TAG is not really efficient,
because it requires a strcmp() to be performed every
time we want to understand if the data is stored inline
or not.
Convert all the *_inline attributes to bool to make the
logic easier and checks more efficient.
Signed-off-by: Antonio
Hi,
On 07/10/18 21:28, Antonio Quartulli wrote:
> Hi,
>
> On 07/10/18 15:34, Steffan Karger wrote:
>> We explicitly only supported GCM as a valid AEAD mode, change that to also
>> allow ChaCha20-Poly1305 as an AEAD cipher. That works nicely with our new
>> (GCM) data channel format, because is
Hi,
On 07/10/18 21:28, Antonio Quartulli wrote:
>> +#if defined(MBEDTLS_CHACHAPOLY_C) && (MBEDTLS_VERSION_NUMBER >= 0x020C)
>
> Why do we need the dual condition? Isn't MBEDTLS_CHACHAPOLY_C enough to
> know mbedTLS has what we need? Or you feel like we have to demand a
> specific mbedTLS
Hi,
On 07/10/18 15:34, Steffan Karger wrote:
> We explicitly only supported GCM as a valid AEAD mode, change that to also
> allow ChaCha20-Poly1305 as an AEAD cipher. That works nicely with our new
> (GCM) data channel format, because is has the same 96-bit IV.
Hi,
On Wed, Aug 08, 2018 at 11:58:47AM +0200, Steffan Karger wrote:
> Like 'proto', a mismatch in key-method, keydir or tls-auth would fail
> before we ever get to the point where we can print this warning.
>
> This prepares for removing these from the occ string later on, but also
> prepares
Looks reasonable :-) - I've not tested it, just stared at code and
ran a test-compile.
Your patch has been applied to the master branch.
commit d818bfedfc7a433a3a5dbd6ce8e9b957802a21b2
Author: Steffan Karger
Date: Fri Oct 5 17:00:32 2018 +0200
Simplify --genkey option syntax
Hi,
On 05/10/18 23:00, Steffan Karger wrote:
> Instead of requiring users to do "--genkey --secret new.key", allow
> them to just do "--genkey new.key". This has hit me often enough that I
> decided to write a patch for it. Also, the upcoming tls-crypt-v2-genkey
> uses a similar syntax and
Your patch has been applied to the master branch.
(Test built on ubuntu1604, and a quick stare-at-code, but if Selva
says it's good, that is good enough :-) )
commit ab9193c32b19e42a1847bd4f6cf967ea0e3293c8
Author: Lev Stipakov
Date: Wed Oct 3 20:21:21 2018 +0300
openvpnserv: clarify
Your patch has been applied to the master branch.
commit 68e0b9db253ff0437047d6a5377eeec6002873f8
Author: Steffan Karger
Date: Sun Oct 7 12:00:32 2018 +0200
Fix use-after-free in tls_ctx_use_management_external_key
Signed-off-by: Steffan Karger
Acked-by: Arne Schwabe
Am 07.10.18 um 13:00 schrieb Steffan Karger:
> Commit 98bfeeb4 changed our openssl backend implementation of
> tls_ctx_use_management_external_key() to no longer use
> tls_ctx_load_cert_file_and_copy(), but still free'd 'cert'. Which it no
> longer should do. Credits go to Arne for spotting the
Commit 98bfeeb4 changed our openssl backend implementation of
tls_ctx_use_management_external_key() to no longer use
tls_ctx_load_cert_file_and_copy(), but still free'd 'cert'. Which it no
longer should do. Credits go to Arne for spotting the issue (even though
it was missed during the review).
Hi,
our windows build seems to have grown a few new warnings with some
of the recent refactoring...?
tun.c: In function 'ipconfig_register_dns':
tun.c:4870:10: warning: variable 'status' set but not used
[-Wunused-but-set-variable]
bool status;
^
tun.c: In function
Acked-by: Gert Doering
I went back and read the discussion we had on v1 of this patch, so we
already agreed on this changes (or we let Simon convince us :)) - we just
asked for a v2 because parts of v1 ("return -err") got fixed in parallel
already.
Test compiled on ubuntu1604/mingw.
Your
Hi,
On Sun, Mar 04, 2018 at 12:44:02PM -0500, selva.n...@gmail.com wrote:
> From: Selva Nair
>
> Openssl docs do not explicitly state these to be macros although they
> are currently defined as such. Use AC_CHECK_DECLS to test for these so that
> both function and macro forms could be detected.
We explicitly only supported GCM as a valid AEAD mode, change that to also
allow ChaCha20-Poly1305 as an AEAD cipher. That works nicely with our new
(GCM) data channel format, because is has the same 96-bit IV.
Note that we need some tricks to not treat the cipher as insecure, because
we used to
Hi,
On Sat, Dec 02, 2017 at 11:21:44PM +0800, Antonio Quartulli wrote:
> Carrying around the INLINE_TAG is not really efficient,
> because it requires a strcmp() to be performed every
> time we want to understand if the data is stored inline
> or not.
>
> Convert all the *_inline attributes to
Hi,
I'm going through open patches in patchwork, and noticed the argv stuff
- I remembered that David had reviewed it, but going through the mails
now I can see that we have no ACK yet, because there are changes needed.
On Mon, Nov 13, 2017 at 12:49:27PM +0100, David Sommerseth wrote:
> Thanks a
Hi,
On Fri, Nov 10, 2017 at 05:39:46PM +0100, François Kooman wrote:
> Parsing CSV can be cumbersome in depending software, so instead
> offer JSON as well using "status 4".
>
> The "status 4" command uses the same keys/values as "status 2"
> and "status 3", just formatted as JSON.
So... we had
29 matches
Mail list logo
