Am 09.10.20 um 22:33 schrieb Gert Doering:
> commit f0734e49956217 simplified key_state_export_keying_material(),
> changing the function prototype. For older mbedTLS versions, there
> is "always fail" dummy function which was overlooked in that change.
>
> Fix prototype.
>
> Signed-off-by: Gert
commit f0734e49956217 simplified key_state_export_keying_material(),
changing the function prototype. For older mbedTLS versions, there
is "always fail" dummy function which was overlooked in that change.
Fix prototype.
Signed-off-by: Gert Doering
---
src/openvpn/ssl_mbedtls.c | 5 ++---
1 fil
I have stared at the code a bit ("amazingly straightforward, no crypto
convolutions at all :-)") and tortured the result a bit on the server
and client test bed. No complaints.
(I have excercised the "key-derivation tls-ekm" path, but not the
generic EKM path - no test case for that one yet...
In addition to the thorough review from Steffan, I have tortured
this patch on the client and server side (read: patched client
talking to an old server, old clients talking to a patched server,
patched client talking to patched server, with/without NCP) and
everything succeeded/failed as expected
Am 09.10.20 um 16:47 schrieb Steffan Karger:
> Just pass pointer and length, instead of a gc and return (possibly)
> allocated memory. Saves us some gc instantiations and memcpy()s. Exact
> same functionality, 19 lines less code.
>
> (Didn't want to delay the TLS EKM reviews for this, so submitted
Yeah, very obvious when you look at it :-) (wasn't *me* who
ACKed that commit... but I had to check to be sure ;-) )
Your patch has been applied to the master and release/2.5 branch.
commit 1e6e083e042d58f9541bf74d343d52fc5681 (master)
commit a9c8225439f0acaa679ee59244b5b8660b561592 (release
Just pass pointer and length, instead of a gc and return (possibly)
allocated memory. Saves us some gc instantiations and memcpy()s. Exact
same functionality, 19 lines less code.
(Didn't want to delay the TLS EKM reviews for this, so submitted as a
patch afterwards.)
Signed-off-by: Steffan Karger
Hi,
On 09/10/2020 15:46, Steffan Karger wrote:
> ASAN yelled at me that someone forgot to call argv_free(). Fix that.
>
> Signed-off-by: Steffan Karger
I bet I know that someone!
Thanks a lot for fixing this.
Acked-by: Antonio Quartulli
(this is for 2.5)
--
Antonio Quartulli
___
ASAN yelled at me that someone forgot to call argv_free(). Fix that.
Signed-off-by: Steffan Karger
---
src/openvpn/networking_iproute2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/openvpn/networking_iproute2.c
b/src/openvpn/networking_iproute2.c
index f3b9c614..3b460527 100644
--
Hi,
On 09-10-2020 13:54, Arne Schwabe wrote:
> OpenVPN currently uses its own (based on TLS 1.0) key derivation
> mechanism to generate the 256 bytes key data in key2 struct that
> are then used used to generate encryption/hmac/iv vectors. While
> this mechanism is still secure, it is not state of
OpenVPN currently uses its own (based on TLS 1.0) key derivation
mechanism to generate the 256 bytes key data in key2 struct that
are then used used to generate encryption/hmac/iv vectors. While
this mechanism is still secure, it is not state of the art.
Instead of modernising our own approach, th
Am 09.10.20 um 11:23 schrieb Steffan Karger:
> Hi,
>
> On 25-08-2020 09:36, Arne Schwabe wrote:
>> OpenVPN currently uses its own (based on TLS 1.0) key derivation
>> mechanism to generate the 256 bytes key data in key2 struct that
>> are then used used to generate encryption/hmac/iv vectors. Whil
Hi,
On 25-08-2020 09:36, Arne Schwabe wrote:
> OpenVPN currently uses its own (based on TLS 1.0) key derivation
> mechanism to generate the 256 bytes key data in key2 struct that
> are then used used to generate encryption/hmac/iv vectors. While
> this mechanism is still secure, it is not state of
13 matches
Mail list logo
