[PATCH] make client-side authentication methods optional

[jkroepke]

Ref #501

I would like to start an discussion about this patch. If the discussion has a positive outcome, I will sent this patch to the via mail.

[schwabe]

I am not sure this is a good way forward. I don't think truly having no client side authentication is not something that I can see has any value for a client connection. I think it would be better to instead introduce something like expect-pending-auth that would tell the client that needs to fail the connection if no pending auth request is received from the server (unless the client has an auth-token/auth-token-user).

Users are often doing incredibly stupid things and allowing to configure a VPN connection without authentication is something that will backfire and then blaming us for their mistakes. And it is a very dangerous feature without safeguards like I describe in the paragraph before.

[selvanair]

Does enforcing that some form of authentication is required in client config really provide any safeguard?

Its the server that authenticates and if there is verify-client-cert none and none of auth-user-pass-verify variants or other authentication mechanisms in the server config, none of this at client side is going to help. Its the server that must fail clients that do not have the required authentication settings.

I'm not convinced that the current client-side restriction serve any purpose at all.

[jkroepke]

Users are often doing incredibly stupid things and allowing to configure a VPN connection without authentication is something that will backfire and then blaming us for their mistakes.

By default, OpenVPN requires server-side authentication. Users have to opt-out with verify-client-cert none on the server to run auth-less. A warning is also raised on the logs, if verify-client-cert none is defined.

A clients-side restriction still doesn't protect against an server-sided insecure configuration.

Incredibly stupid users can still do incredibly stupid things. For example by just define

<auth-user-pass>
username
password
</auth-user-pass>

on the configuration, which is the current workaround for this issue.

[schwabe]

Yes, you can always find a way too shot them into the foot. And I think being able to disable client side without any warning or extra option is dangerous cause it could lead to accidentially insecure configuration. I think this needs to be explicitly requested to avoid these situations.

[jkroepke]

Would an additional config directive "no-auth" sufficient?

The config directive would only skip the if condition, which is remove here. No additional logic.

[selvanair]

Would an additional config directive "no-auth" sufficient?

If we have to go this route, --external-auth may be a better choice for the option name. Just add a value based on it to the variable sum and the if clause will get bypassed. The option parsing could be kept simple by allowing it to be specified irrespective of any other option as the only place it will get interpreted is for this check.
That said, we are just piling on to a check that is in the wrong place to start with (client instead of server) -- but it seems only I think that way.

[cron2]

That said, we are just piling on to a check that is in the wrong place to start with (client instead of server) -- but it seems only I think that way.

I actually agree with Selva here - whether or not there is authentication is a server side decision.

That said, I think I do understand where Arne is coming from - users put incredibly stupid stuff into their configs, then things fail, and we get bad press out of it. So I'd go with making it explicit, as Selva proposed, adding an --external-auth or --expect-external-auth switch, with a warning label attached.

(And then Arne gets the prize for making us introduce yet another option)

[jkroepke]

Since, it's my first contribution and I would like to reduce the review cycle and make you more happy.

Where I have to add the new option?

• config parser
• config validator (changing the sum calculation)
• --help ?
• man page

somewhere else?

[selvanair]

Where I have to add the new option?

config parser
config validator (changing the sum calculation)
--help ?
man page

That seems to cover it all. Also, Gert wants a warning, which could be possibly added like this:

Leave the definition of "sum" as is. If it's zero, and no indication of external auth, enter the if clause and exit. Else, if sum is zero, log a warning that this configuration assumes that the server will authenticate the user via external means such as webauth. Something like that.

[cron2]

I do not need a warning in the actual code. Having a warning in the manpage is perfectly fine for me.

But Selva's suggestion would also work, and I think would make Arne more happy ;-)

[jkroepke]

Tested locally on a linux system. It works fine. Tested with external-auth and without. If external-auth is omit, the current behavior applies. With external-auth, I'm able to authenticate via WEBAUTH, which configure additional credentials.

[jkroepke]

Thanks for the review, I have adjust the text. I also really recommend the suggest feature to request changes more precisely.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request

[selvanair]

LGTM.

[schwabe]

I would rather have a different name than external-auth as you still have auth-pending methods that can be internal to OpenVPN like 2FA or similar. I would rather spend the extra effort of implementing a flag like expect-pending-auth and check that this has happend at the connected state. Or at least have a better name than external-auth

[jkroepke]

What about an flag named no-client-credential instead spending the extra effort?

Instead expecting something from server, declare that I don't have client credentials?

[jkroepke]

I pushed a new state based on my last proposal

[jkroepke]

I this fine and ready to review through mailing list?