On 06/05/20 21:39, Gert Doering wrote:
On Mon, May 04, 2020 at 02:49:56PM +0200, Dajka Tamás wrote:
is it possible to disable "auth-nocache" in the client by a PUSH message? I
mean, if the "auth-nocache" is SET in the client.conf to "reenable"
credentials caching. What's the logic behind? When we deployed the clients
we did set 'auth-nocache' as a security measurement. However, we want to use
auth-token now beside OTP, but changing all the clients will take some
(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])
and what 448 * Disable password caching
449 */
450 void
451 ssl_set_auth_nocache(void)
452 {
453 passbuf.nocache = true;
454 auth_user_pass.nocache = true;
455 /* wait for push-reply, because auth-token may still need the
username */
456 auth_user_pass.wait_for_push = true;
457 }
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.
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.
There are some bugs lurking here which I've not had time to pinpoint
enough so Arne can fix them - so, "more testing" would certainly be
welcome.
What I've found:
- if you restart the server, and "explicit-exit-notify" is enabled,
this will twist a flag in the client, and it will keep on sending
the *old* token, even if the server sends a renewed one. So after
the second reneg-sec interval, the token expires and you get AUTH_FAILED
- if you use lifetime-limited tokens ("8h"), and that lifetime expires,
the client needs to reauthenticated. Which is the idea, so "good". But
in some cases, we've had AUTH_FAIL on the *next* renegotiation, which
hints at the same problem above ("auth-token not sticking").
Secondly, is it allowed/possible to set "reneg-sec" by a PUSH message?
(reneg-sec is not set currently in the client.conf, has the default value of
3600)
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.
JM2CW,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
