For TLS 1.0 to 1.2 and OpenSSL 1.1.0 calls us and requires a PKCS1
padded response. As TLS 1.3 mandates RSA-PSS padding support and also
requires an TLS 1.3 implementation to support RSA-PSS for older TLS
version, OpenSSL will query us to sign an already RSA-PSS padded
string.
This patch adds an '
Your patch has been applied to the master branch.
commit ddd925bf23bc1b43fda93d2757619a1613cec1ba
Author: Antonio Quartulli
Date: Thu Nov 1 00:01:24 2018 +0800
tls-crypt: properly cast time_t to uint64_t
Signed-off-by: Antonio Quartulli
Acked-by: Arne Schwabe
Message-Id:
For TLS 1.0 to 1.2 and OpenSSL 1.1.0 calls us and requires a PKCS1
padded response. As TLS 1.3 mandates RSA-PSS padding support and also
requires an TLS 1.3 implementation to support RSA-PSS for older TLS
version, OpenSSL will query us to sign an already RSA-PSS padded
string.
This patch adds an '
Before OpenSSL 1.1.1 there could be no mismatch between
compiled and actual OpenSSL version. With OpenSSL 1.1.1 we need
runtime detection to detect the actual best TLS version supported.
Allowing this runtime detection also allows removing some of the
TLS 1.3/OpenSSL 1.1.1 #ifdefs
Without this pa
Am 31.10.18 um 17:01 schrieb Antonio Quartulli:
> The exact type of time_t is platform dependent and therefore
> can't be assumed to be uint64_t all the time.
>
> For example, on 32bit platforms, where time_t is defined as long
> (32bit), the compiler will generate the following warning, due
> to
The exact type of time_t is platform dependent and therefore
can't be assumed to be uint64_t all the time.
For example, on 32bit platforms, where time_t is defined as long
(32bit), the compiler will generate the following warning, due
to the arithmetic used in the macro:
tls_crypt.c:745:29: warni
Tested this with Ubuntu client, patched applied &
Arch server, current master and it worked correctly.
Client did not crash when trying to "reconnect" to a server
when the server had been changed from TLS Crypt V2 to V1.
When the server was changed back to V2 the client connected
successfully.
As reported by tincantech on the openvpn-devel IRC channel, a tls-crypt-v2
client could be caused to trigger an assert in tls_crypt_wrap() because the
client key might not be correctly initialized after a reconnect attempt.
This was caused by code that was written before the connection-block
tls-a
As kitsune1 mentioned in IRC, this section should explain that
"--tls-crypt-v2-genkey client" requires the user to supply the server
key using "--tls-crypt-v2".
Signed-off-by: Steffan Karger
---
doc/openvpn.8 | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/openvpn.8 b/doc/openvpn.8
Your patch has been applied to the master branch.
Thanks for your first patch contribution :-) - a few words for the next
one: please do use "git send-email" to send your patches out, and do not
let exchange anywhere near your patches. What you sent was so garbled by
the mailer (lines wrapped, s
Hi,
On 31-10-18 00:20, tincanteksup wrote:
> Correct error message for --tls-crypt-v2-genkey client
>
> Signed-off-by: Richard Bonhomme
> ---
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 882337b2..39e8ca5f 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -1087,
11 matches
Mail list logo
