Commit facb6fffb changed a call in the style of if(a() | b())
to if(a() || b()). While this looks identical, it is not. The first
statement always executes b() while the second only executes b() if
a() returns false. This lead to to the platform_state_user never to
set as side effect and thus
On Wed, Oct 19, 2022 at 1:05 AM Arne Schwabe wrote:
>
>
> If we can conjure up usernames (like with empty --> token-user) why not
> allow other username
> changes too?
>
> In general the current authentication system in OpenVPN is ill equipped to
> handle them. On renegotiation we only do auth
Acked-by: Gert Doering
Glad that this obscure AS option caught this breakage... *sigh* - that's
what you get for "just fix this compiler warning" (which I am usually
quite reluctant to do, but "it looked straightforward enough").
The new code is less magic, and much easier to understand - good.
Patch v2: fix comparing key_id to state value, improve message
Patch v3: also take key_id into account
Code looks good to me now. Is there any way of testing this?
You need to get both peer in some kind of inconsistent state. Like short
reneg-sec on one side and dealyed auth on the other
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
Am 24.06.22 um 14:26 schrieb Frank Lichtenheld:
Doesn't make sense to test with fragment, if the code
ignores it.
Acked-By: Arne Schwabe
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
Hi,
Using --auth-user-pass, --auth-nocache and --reneg-sec , no
auth-tokens in use, I see that username/password is prompted on the first
connection attempt and at first renegotiation. After that reneg completes
without prompting for user/pass.
Looking at the server it shows the previously
Change makes sense :-) - have not tested any actual builds without
ENABLE_FRAGMENT to verify that it exploded *before*, but it looks
like this will fix it.
Your patch has been applied to the master branch.
commit 252e5d6888261d7b2aae1034c834fba8a393cef4
Author: Frank Lichtenheld
Date: Fri Jun
>
> After reneg, the client progresses beyond AUTH state (as reported on Trac
> #1471 ( https://community.openvpn.net/openvpn/ticket/1471) which may be
> related. Unless it has been like this all along.
>
Please Ignore that comment -- Trac# 1471 is a special case and may not be
related at all.
From: Selva Nair
Starting from commit e61b401a auth-token is saved in a separate struct
from auth-user-pass and is not cleared when ssl_purge_auth() is called.
This makes "forget-passwords" sent to the management
interface or "--management-forget-disconnect" option not to work
as expected.
Hi,
On Wed, Oct 19, 2022 at 02:33:27PM -0400, Selva Nair wrote:
> Using --auth-user-pass, --auth-nocache and --reneg-sec , no
> auth-tokens in use, I see that username/password is prompted on the first
> connection attempt and at first renegotiation. After that reneg completes
> without prompting
Thanks for the review, Kristof.
Just to be sure, I've run this through extensive client/server tests
on FreeBSD 14 + 12.3 again. Still works :-)
(Except that this patch, as documented, breaks "topology subnet with DCO"
- to be fixed in the next commit)
Patch has been applied to the master
Thanks, Kristof for the review, and for merging the kernel side.
I have added the kernel commit ID to the commit message for this
patch ("if the kernel is too old, SET_IFMODE will fail and
topology subnet will not work") - and verified that this is indeed
the result, p2p mode with net30 works,
On Wed, Sep 21, 2022 at 12:49:29PM +0200, Arne Schwabe wrote:
> Currently control packet size is controlled by tun-mtu in a very
> non-obvious way since the control overhead is not taken into account
> and control channel packet will end up with a different size than
> data channel packet.
>
>
On Tue, Oct 18, 2022 at 06:16:54PM +0200, Frank Lichtenheld wrote:
> Acked-By: Frank Lichtenheld
>
> Already acked in 1957647252.642516.1652264253...@office.mailbox.org
>
Note: this patch does not depend on 2/3, only on 1/3.
Regards,
--
Frank Lichtenheld
15 matches
Mail list logo
