Bug #10539
closed
OpenVPN incorrect validation of common name with external case-insensitive directory
0%
Description
Now Common Name is case-sensetive validation field.
With Local Authorization it works fine as Unix local users are case-sensitive as well.
- common names are case-insensitive
- user can provide full username@domain or only username
It produce situation when user can bypass server restrictions or user client specific overrides.
This can be security issue in situation when system administrator: - see that Duplicate Connection is disabled and think that his users can't connect twice which gives false positive security
- configure static IP for user inside VPN with restriction rules on firewall tab for this specific IP. User provide another username and get random IP from Pool without restrictions which system admistrator was set.
User can use endless variants of username, as: user, USER, User, uSer, uSEr, user@Domain.com, useR@domain.coM and so on.
It impossible to restrict now all variant of user input.
Possible fix this issue:
1. Strip domain part from common names checks at Server Duplicate Connection
2. Strip domain part from common names checks on Client Specific Overrides in case User common name override not has explicitly set @domain part
3. Add option (and maybe enable it by default for existing overrides) to check common-names in case-insensitive manner
4. As additional future add option to allow user Common-Names validation by Regex on Client Specific Overrides
Note: 1 and 2 can be optional check-boxes or be mandatory, need to think about usecases.
Updated by DRago_Angel [InV@DER] almost 4 years ago
Possible fix addition:
In 1 and 2 common names must be all converted for example to lowercase before check - this will give case-insensitive result.
Updated by Jim Pingle almost 4 years ago
- Status changed from New to Not a Bug
- Priority changed from High to Low
That's an issue in OpenVPN internally. You could disable username-as-common-name (checkbox in 2.5.0 or 2.4.5-p1) which might make a difference or enforce strict user/CN matching which may also help this.
AFAIK we can't do anything to influence the name chosen by OpenVPN to select the overrides other than enabling/disabling username-as-common-name.
Updated by DRago_Angel [InV@DER] almost 4 years ago
You mean there is no way to change way how username validated to (regex|case-insensitive) or change (strip|convert to lowercase) username on fly? Maybe this can be done at Authentication Servers configuration then?
If there really no way to exclude such use-cases then in OpenVPN must be a note about it if user choose external user directory as source of authorization. This "not-a-bug" can really result in not secure configuration. Administrators at least need to know about such stuff.
Updated by Jim Pingle almost 4 years ago
We can maybe add a warning about it, but that is 100% a problem with the authentication server and OpenVPN itself. The authentication server is approving the login with mixed case, OpenVPN just takes what it was given and looks for a matching file. There are posts about it on the OpenVPN forum going back at least 8 years. I don't think they care, but you could raise an issue with them if there isn't one in their issue tracker yet.
We also can't predict what everyone's auth servers will do. Not all LDAP is case insensitive.
Someone could make an override called DEFAULT which denies access and then make an override for every valid user with the specific case they want, but that doesn't scale well.
Updated by DRago_Angel [InV@DER] almost 4 years ago
Yep I know that not all LDAP providers are case insensitive, but most - is. And still even with case sensitive login there still one way to use login with @domain part and without it. Not hard to write 2 override rules, but still administrator must know that he must to check at least how it works in his LDAP and pfSense. I can say for sure that without additional info mostly nobody will think about this...