Hi,
> -----Original Message-----
> From: Gert Doering [mailto:g...@greenie.muc.de]
> Sent: Thursday, May 7, 2020 11:30 AM
> To: Jan Just Keijser <janj...@nikhef.nl>
> Cc: Gert Doering <g...@greenie.muc.de>; Dajka Tamás <vi...@vipernet.hu>;
> openvpn-users@lists.sourceforge.net
> Subject: Re: [Openvpn-users] disable "auth-nocache" by push?
>
> Hi,
>
> On Thu, May 07, 2020 at 09:53:26AM +0200, Jan Just Keijser wrote:
> > On 06/05/20 21:39, Gert Doering wrote:
> > > On Mon, May 04, 2020 at 02:49:56PM +0200, Dajka Tamás wrote:
> > >> (unneeded) time.
> > > To disagree with JJK once more, the current versions (2.4 and
> > > master) will actually cache the auth-token even if auth-nocache is
used.
> > this time I'll disagree with you : when looking at the v2.4.8 source
> > code, I see in options.c
> >
> > 7797 else if (streq(p[0], "auth-nocache") && !p[1])
> > 7798 {
> > 7799 VERIFY_PERMISSION(OPT_P_GENERAL);
> > 7800 ssl_set_auth_nocache();
> > 7801 }
> > 7802 else if (streq(p[0], "auth-token") && p[1] && !p[2])
> > 7803 {
> > 7804 VERIFY_PERMISSION(OPT_P_ECHO);
> > 7805 ssl_set_auth_token(p[1])
>
> Well, it will not technically "disable" auth-nocache, but "override"
> it. The auth-token is stored in a way that the next request for
credentials will
> not ask (as if "auth-nocache" were in effect) but send the token instead.
>
> > I wrote originally is that there is no way to "undo" the call to
> > ssl_set_auth_nocache(), so pushing/overriding auth-nocache does not do
> > much until a client restarts.
>
> True that.
>
> > As for the link between auth-nocache and auth-token , that is another
> > matter: all that auth-nocache seems to do, is to disable *PASSWORD*
> > caching . If auth-nocache is supposed to affect token caching as well,
> > then the code needs updating.
>
> It isn't, but as the token is an "auth credential", whether or not this is
affected by
> auth-nocache is not obvious, and there have been "interesting"
interactions in
> the past.
"In the past"? :) I've faced several interesting things when I was testing
with auth-gen-token/auth-token (pushed from the server's management
interface). With the latest Win10 GUI (with 2.4.9) it seems ok (I've
auth-nocache in the config but token auth works), but the previous one was
not so "stable".
>
> [..]
> > > For questions like that, "just trying it" is harmless - a client
> > > will ignore pushed options it doesn't like, and log it.
> > >
> > > Checking the code, I can't say for sure. It's a somewhat obscure
> > > class of config options group (OPT_P_TLS_PARMS) which I can't find
> > > clear indication on whether those are pushable or not.
> > >
> > that was also why I wrote that I did not see any logic to prevent a
> > user from pushing reneg-sec; I am still trying to find the code (and
> > possible
> > reason) where this is made impossible.
>
> OPT_P_TLS_PARAMS is not enabled for "this class of options is allowed on
push
> reply".
>
> Actually there is a reasoning behind not permitting pushed reneg-* options
> - because all you can do with this is "lower client security" by pushing a
*higher*
> value than the client wants. If the server wants a *lower* value, it can
initiate
> the renegiotiation at any time on its own (so no need to push anything),
but if
> the client wants a lower value, maybe it's good that the server is not
allowed to
> override this.
I really don't see this as a security issue. If the server is compromised -
in a way that I can easly push message to a client - then I probably have
(full) access to all the certificates/can lower the server value to crack
the channel etc. OTOH, from an operational perspective it's sometime
necessary to change the clients config - especially if there are default
values -, but I cannot access the clients, or don't want to access them
one-by-one due to the large number of it.
>
> Or maybe I am just reading something into code that wasn't *really*
thought
> through :-)
>
> #define OPT_P_TLS_PARMS (1<<13) /* TODO */
> #define OPT_P_MTU (1<<14) /* TODO */
>
> "why is there a TODO in options.h?" :-)
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
feed
> honest figures into a computer, honest figures come out. Never doubted it
> myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh
Mistress
>
> Gert Doering - Munich, Germany
g...@greenie.muc.de
Cheers,
Tom
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
