How to prevent users from sharing certificates in OpenVPN?

I have an OpenVPN server which uses certificates and LDAP authentication.

The problem is that, one user could share his certificate and other valid LDAP users could use this certificate.

Question

How do I make sure that Bob's certificate can only be used with the LDAP user "bob"?

Solution 1:

According to this post, common_name can not be faked by the user.

Add this to openvpn server.conf

script-security 2

# untrusted state
auth-user-pass-verify /etc/openvpn/scripts/check_cn_on_connect.sh via-env

/etc/openvpn/scripts/check_cn_on_connect.sh contains

#!/bin/bash

# username and common_name must be the same to allow access.
# users are not allowed to share their cert
if [ $username != $common_name ]; then
   echo "$(date +%Y%m%d-%H%M%S) DENIED  username=$username cert=$common_name" >> /var/log/openvpn-access.log
   exit 1
fi

echo "$(date +%Y%m%d-%H%M%S) GRANTED username=$username cert=$common_name" >> /var/log/openvpn-access.log

exit 0

Update

This is for OpenVPN 2.1.4. In 2.2.0 have they added many new variables that you can see by env >> /tmp/env, where one of these new variables is the certificates fingerprint/serial number.

Solution 2:

There are many options, since OpenVPN is an open source project, and it has a ability to write your own-authentication hook there are many people who have done many different things to provide different levels of authentication.

I haven't tried most of these just seen them mentioned in the docs/blogs/maillists. Some of these may require patches or the non-free version.

One main method will be to make your the private portion of your key-pair prohibitively difficult to extract/copy.

• Use a hardware token. The private key can be stored on a physical token and cannot be copied or retrieved. (ref: OpenVPN offers support of smart cards via PKCS#11 based cryptographic tokens.)
• I have seen mentions of using the TPM, this is similar to a hardware token, but built-in to the motherboard. (ref: http://www.cs.tau.ac.il/~orkaplan/TPMWorkshop/downloads/ServerSetup.txt)
• I saw something on a mailist mentioning that it was possible to use the Windows certificate store for the key. Keys here can be marked so the are not exportable. (Ref: http://openvpn.net/archive/openvpn-devel/2004-10/msg00019.html)

If protecting they key is cost-prohibitive, not supported on your client platforms or not possible for some other reason then you are left with a few options.

• Require frequent renewals of the cert, so a copied certificate cannot be used for long.

• Set a lot of logging on your server, to watch for anomalies. If Bob normally only logs in from his house, and then one day, he starts logging in from Acme Inc. then you may need to investigate.

• Setup multi-factor authentication. Your certificate counts as the 'something you have'. So you should be looking at alternatives in the 'something you are', or 'something you know'. This includes bio metrics, or passwords/pass-phrases.

• As I mentioned OpenVPN provides for very flexible authentication. This uses the auth-user-pass-verify option. This option passes the provided username and password to an external script/program which will make the authentication decision based on whatever you want.

Solution 3:

I'm not a security pro I am strict about security. Your question precisely reaches the core of IT security: trust. As i see it one should never assume that Bob can be trusted. Sure, Bob might be a really nice and trustworthy guy. He's worked at your company for 20+ years. However, the person "Bob" is entirely irrelevant in your IT infrastructure.

Bob uses arbitrary 'relays' that permit access. Relays can be anything: a password, certificate, hardware token, iris scan, DNA. They're keys that permit access to your system. If your question is about verifying the identity of the person who is using a key, the only honest answer probably is that you'll have to be in the same room. In all other cases I think you mustn't assure yourself that that Bob really is Bob and currently not being held at gun point while gaining his access. So in your IT infrastructure design plan the logical thing is not to refer to "Bob": an entity gained access to your site.

Because you can only really know that 'an entity' gained access with a key that you passed out in the past the proper perspective probably is to limit the number of doors the key can open. The more keys you pass out the less doors they open.

OpenVPN also has an option to permit only one concurrent connection per key. Then if Alice does log in with Bob's key while Bob is already inside, Alice is denied access. Unfortunately this also means that Bob can't login when Alice is logged in with Bob's key. So you should configure your system to inform you of concurrent login attempts from multiple source IPs. And kick off both when some violation occurs so Bob will have to dial for help.

The point is: don't assure yourself of things you can't be sure of and keep this in mind when designing your security plan. Assume there's always a smarter person out there, way ahead of you, who can't wait to prove you wrong... just 'for the lulz.' :-)