Certificates and Openvpn

[peterzy]

Imagine the following scenario:

You have setup with OpenVPN with SSL certificates.
Deleting certificate does nothing, user is still able to login. So you have to put it in revocation list to block the user.

You have two admins - George and Bob. Bob creates certificate, downloads it and saves it to usb. Then he deletes the certificate so there is no trace of it.
After 2 years he quits the company, but with certificate on USB he can use VPN any time and that will be hard to catch by George as certificate is deleted and hard to revoke.

We already use user/pass and shared keys so I am aware of these setups, but we need to move to certificates for some sites.

How do we prevent Bob vs George scenario ?

Thank you :-)

[johnpoz]

@peterzy You would need to change out the CA or the intermediary CA that issues the certs.. Problem with that solution is it would cause all your other users to have to change their certs to the new ones.

You could change just the TLS key, but again this would require change for every other still valid user.

Best bet to prevent such a thing might be to use ssl auth + user auth.. Where you use a method of user auth like radius or the local database where users passwords could be changed. Now Bob might know other users usernames and passwords as well so you might want to have users all change their passwords, etc.

But change of user passwords would be less obtrusive then having to have all users with new certs or new tls key, etc.

[peterzy]

@johnpoz We already use OpenVPN in two scenarios: shared key and user/pass. The problem is that we need to support Miktrotik OpenVPN clients. They support ONLY certificates. Not possible to add username or anything... Nothing beside certificates....I wonder if Pfsense can REVOKE and then delete certificate...i.e to be impossible do delete without revoke..

[johnpoz]

@peterzy I do believe you could delete without revoke, so I think you have come up with an actual valid scenario that could be of concern.

Part of the reason its not really a good idea to use public issued CA and certs, because any cert issued by the CA would be valid.

The change out of the TLS key prob be the least obtrusive method then, but would require all still valid connections update their config with the new TLS key.

Other option would be to use ssl+user auth for your normal remote users, so you could just change passwords for them. And only be concerned with changing out certs or tls key with the mikrotik clients.. You can run more than one instance, one for normal remote users, and another for your router clients..

This instance could be locked down to only their IPs as well, so be hard for exadmin to be able to use any of those certs because they would be coming from different IP that is not allowed.

[peterzy]

@johnpoz I have tried two things

1. User/pass + certificate

Changing password does not help - as long as certificate is supplied user can login. Common name comes correctly from the certificate.

2. User/Pass only - then common name comes as

UNDEF username e.g "UNDEF test"

That with Mikrotik.
With normal VPN client(e.g OpenVPN under windows) common name comes correctly as username e.g "test"

Any ideas ?

[johnpoz]

@peterzy said in Certificates and Openvpn:

as long as certificate is supplied user can login. Common name comes correctly from the certificate.

Not sure what your doing there - but that makes no sense, and would mean the whole point of the setting is pointless. If that is not working should prob put in a redmine, since clearly if the username/password is not known or password was changed they shouldn't be able to log in, even if the cert is valid.

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-server-mode.html#mode-configuration

Not saying to use this for your routers that need to connect, just create multiple instances of openvpn server on pfsense. One used for your users, other used for these routers that do not support the mode, etc.

[peterzy]

@johnpoz

Yes it seems kind of bug.

My setup:

1. VPN Server1 - certificate only
2. VPN Server2 - certificate(same certificate as with server1) + user
   
3. VPN Server3 - user

Servers are on different ports. I have three servers just for the sake of test purposes.

Client: RouterOS 6

Server1 - works like charm
Server2 - connects even with wrong password. I even put username "any" and was till accepted . However client overrides do not kick in.
Server3 - wrong common if client is Mikrotik.

So definitely some bugs somewhere :-)

Peter
P.S TLS verify is not an option as it is not supported by MTK

[johnpoz]

@peterzy yeah that is too bad about the TLK key.. stupid they do not support that.. Found a thread from 2015 asking for ;) and still not available.

But reading this

https://help.mikrotik.com/docs/display/ROS/OpenVPN

limitations:
authentication without username/password

The way I read that you have to use a username/password even if your using cert..

If I get a chance later today I will try and duplicate you saying that wrong username/password when using tls + user auth not working, and look in redmine if already known, etc.

[peterzy]

@johnpoz Thank you :)
For without user/pass: You just put any username in the field username e.g word "any" and it works like charm with certificate only if Pfsense is in certificate only mode. However when Pfsense is certificate + user mode it still works, but then client specific override does not work, so I guess common name is changed or something.
My exact versions are: RouterOS 6.49.7 (stable), Pfsense is 2.6.0

[stephenw10]

If you have a CSO for every user you could have invalid settings in the main config so anyone connecting would be unable to actually access anything. They would still be connected though.

[peterzy]

@stephenw10 yep, this is what I was thinking also. However I am not sure how secure it it is if i put dummy local and remote networks by default.

[stephenw10]

Not very. A connected client can always add their own routes to access remote resources. They can't have a subnet behind them. But if you add fixed IPs for each client and block everything else then they would not be able to connect. The client can't specify the IP address they use in a SSL/TLS tunnel. Or shouldn't be able to at least. Still nowhere near as good as revoking the cert.

[jimp]

If you really don't want to rely on user auth + strict user+CN matching, then you could make a CSO for the special DEFAULT user with the Connection Blocking option checked, then define a CSO for each other valid certificate CN.

Don't rely on IP address assignment/routing/firewall rules alone because if they can still connect, the client can influence some traffic on their own, so it's not as secure. Even if the server pushes some invalid settings the client can be set to ignore those.

All that said, if you really don't trust the old admin, changing out the whole CA structure after they leave would be warranted.

[peterzy]

@jimp Thanks :-) Ideas looks great :) BTW I do want to user + certificate but in that case when I changed password I was still able to login with just certificate(case 2 above).