On Mon, Jan 09, 2023 at 05:38:10PM +0100, Arne Schwabe wrote:
> Currently we have only one slot for renegotiation of the session/keys.
> If a replayed/faked packet is inserted by a malicous attacker, the
> legimate peer cannot renegotiate anymore.
> This commit introduces dynamic tls-crypt. When both peer support this


> feature, both peer create a dynamic tls-crypt key using TLS EKM (export key
> material) and will enforce using that key and tls-crypt for all
> renegotiations. This also add an additional protection layer for
> renegotiations to be taken over by an illegimate client, binding the
> renegotiations tightly to the original session. Especially when 2FA, webauth
> or similar authentication is used, many third party setup ignore the need
> to secure renegotiation with an auth-token.

Acked-By: Frank Lichtenheld <fr...@lichtenheld.com>

Stared at code, read documentation, stared more at code. Looks like it
does what it should. Ran master+patch t_client tests against a master+patch 
Log messages look sensible. Also tried running a connection with --reneg-sec 15
just to prove that renegotiations still work.

I can't prove/judge whether it actually uses a different key and whether the 
claims from the commit message are actually true.

  Frank Lichtenheld

Openvpn-devel mailing list

Reply via email to