Long common name of client certificate causes authentication process to fail about openvpn-auth-oauth2 HOT 11 CLOSED

What did you think about an option like --openvpn.hash-common-name?

Put the common-name as sha1 into the state URL and on verification step, preferred_username is hashed first, then compare against hashed common name.

Is this a option for you?

from openvpn-auth-oauth2.

In my case the common name currently does not match the preferred_username, so I don't need the CN at all. But in case this check can be optionally enabled that would of course be fine. I'm not entirely sure that a SHA1 hash wouldn't be too long though. I used a CN of 42 characters for testing and that was too long, I believe SHA1 would be 40 characters.

In the end my goal is to have a single client certificate for all clients and rely on the OIDC authentication to distinguish between users.

from openvpn-auth-oauth2.

245 chars are allowed as maximum.

from openvpn-auth-oauth2.

I decided to drop hashing. MD5/SHA1 are considered as insecure. Using them trigger some security scans... SHA2 has to long hashes.

However, #74 add the option to omit the CN.

from openvpn-auth-oauth2.

Thanks again for the quick response. Your fix is quite nice, though I would like to request one change. Currently you are replacing the common name with the string "omit", which is encoded after being put in the token and results in \u003comit\u003e. This is still quite a lot of characters and I'm still running into an issue with the length of the URL, depending on the size of the state param after encryption. Would it be possible to simply omit the whole cn property in the token instead? This would leave the most characters for the rest of the URL (mostly origin).

It seems my current issue is caused by the client I'm using, since I seem to be limited to 236 total length of the URL. After that Viscosity seems to be removing characters at the end before loading the URL in their webview. I have asked their support about this and see what can be done on that side. However, I think that it would be beneficial if more space is available for the origin in the URL and also potential proxy options in the WEB_AUTH at some point.

from openvpn-auth-oauth2.

Is -as alternative ok?

from openvpn-auth-oauth2.

Assuming it will be one character in the cn field I think it should work for my case, as I seem to run into issues as soon as the common name goes over around 12 characters (assuming maximum size of the ip field).

I do think the ideal solution would be to just omit the whole cn property altogether, because this gives the most flexibility in URL length. I understand this is probably a lot more effort to do though, so I understand if you prefer to just stick to the current workaround.

FYI: I got a reply from SparkLabs regarding the limitation in the Viscosity client. They are saying this is a limitation with OpenVPN:

I’m afraid that’s expected behaviour: OpenVPN limits the Web Authentication command to management interface to 256 bytes/characters. Once you factor in the “WEB_AUTH” text and flags, that limits the URL itself to under 256 (so around your 236 value, depending on the flags used).

I've had a look at the OpenVPN code and it does indeed seem to be a limitation there: https://github.com/OpenVPN/openvpn/blob/v2.6.8/src/openvpn/push.c#L245

The available buffer size is 256 bytes, and they are concatenating >INFOMSG: to the server WEB_AUTH message, leaving even less space.

from openvpn-auth-oauth2.

I see that this is very limited, I will looked into the to reduce the size of the state. (Currently its encrypted json). It's the only way to trans infos from the VPN client to the web stack. I would like to avoid to setup an state in openvpn-auth-oauth2.

from openvpn-auth-oauth2.

I see that this is very limited, I will looked into the to reduce the size of the state. (Currently its encrypted json). It's the only way to trans infos from the VPN client to the web stack. I would like to avoid to setup an state in openvpn-auth-oauth2.

Yes, I also think that keeping it stateless (and therefore less complex and error prone) is preferable. If you could release your proposed change (using - instead of <omit>) that would already help me a lot, because it will reduce the full length of my URL below the limit. I think any other changes to reduce the state size will require a lot more effort.

Thanks for all the effort, I really appreciate it.

from openvpn-auth-oauth2.

Fyi: Go supports binary encoding as alternative to json encoding. I will play with such this in the next time and I hope reduice the length even more.

from openvpn-auth-oauth2.

@ncroese

With #78 I could optimize the state length to an minimum by avoid using json and store the values only. On top, the issued timestamp was stores with NanoSecond which costs some chars, too. Using second is good enough. Feel free to test.

from openvpn-auth-oauth2.