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.
[..]
> > 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.
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
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
