Two factor authentication
-
Factors:
-
TLS Key
-
User Certificate
-
Username/Password
-
Thumbprint/TouchID to get at credentials
-
RADIUS or LDAP could be put through something like Duo
-
User Certificate/Key could probably be protected by another password
There are probably more.
OpenVPN, by default, is "two factor" as long as you use TLS Key, SSL/TLS mode (something possessed), and User Auth (something known).
-
-
^ took the words right out of my mouth ;)
Out of the box openvpn is 2FA - you have to on purpose remove that…
-
The easiest out of the box two factor authentication with OpenVPN in pfsense is to use a cert and the user database. Create usernames and passwords for your connecting users. One of the companies I managed it for I use OpenVPN with an leap query memberof string and have a security group for users allowed to connect. They can login with their domain creds.
-
fantastic!!
course by default its the ssl/tls and username password
can it do mobiles or email
-
"or email"
not sure what your asking there? But yes there is a openvpn client for ios and android. Tablets, phones, etc. I vpn in with my phone all the time to my home network.
-
sorry John,
i mean i know atm its 2FA ie ssl/tls cert installed on client computer and aswell they need to enter a username and password
but what about if i want another multi factor authentication like send an email or send a text message to them so they have to enter in a code or something?
-
not sure why you need it but if you still insist here's a guide using Duo
https://duo.com/docs/openvpn
-
IMO, your best bet is something that integrates with RADIUS like Duo. That way all your devices have to support is RADIUS, instead of having every device/system all support your chosen method of MFA.
You can also do things like appending
VerisignSymantec VIP from a dongle/card/app to your RADIUS password, etc.Yeah, management likes something they can "see." They can't be expected to understand how things actually work.
-
Lots of good and on point advice above, but this was missed …
If your server is set up (box checked) for common name to match certificate then you not only need a certificate and a user id BUT the certificate must match the user id you use to sign in. Different certificates for different users help you with this. (I used different ids for each pc, but openvpn just prefilled the userid field on the client pc - I wish they didn't.)
Also, you need to modify the openvpn config download files on the pc with different names from the user id.
For example, pfSense names the file and the certs with the user id. Rename them and edit config with the new names. It's a little tedious but nobody knows your name if you do it.
-
If you have enabled strict user/CN matching and your adversary has access to your computer she can just look in the certificate and get the CN there so you are not hiding anything from anyone by jumping through those hoops.
-
If you have enabled strict user/CN matching and your adversary has access to your computer she can just look in the certificate and get the CN there so you are not hiding anything from anyone by jumping through those hoops.
Not if you rename the certificates and the config file and put the new names in config file. I do this and it's flawless. It takes 30 seconds.
As I mentioned above, openVPN very recently changed the client program so the last user id defaults into the prompt. Before this, this method was foolproof. They accidentally made it less secure with this convenience. If they change it back or if there's a way to make the default client user always blanks again - just like the password - it will be good again.
-
The CN is in the certificate, dude. It has to be or the connection and strict CN/username matching will not work.
openssl x509 -text -in certificate.pem
Look for the CN= in the Subject:
-
The CN is in the certificate, dude. It has to be or the connection and strict CN/username matching will not work.
openssl x509 -text -in certificate.pem
Look for the CN= in the Subject:
Why do you keep arguing with me. Just spend 30 seconds renaming the ovpn file, the certs in the ovpn file and the actual certs on the pc. IT WORKS PERFECTLY. (except for the dumb OpenVPN change where the last user id automatically populates the field when you initiate a connection. It used to not do that, until very recently.)
*** ===> You continue to confuse the username with the file names on the PC. They are not the same thing even though pfSense names the file using the username as a part of the filename. (Please note that pfSense renames these files also but uses the userid as a part of the file name. I fix that security glitch with these changes. I'm doing exactly what pfSense does.)
The ovpn file calls the certificates. They could be named larry moe and curley joe on the pc as long as the same name is used in the ovpn file. The name on the server is not involved at this point.
the actual user id could be xyzbc123 for all it matters. It HAS to match the OpenVPN server.
The checkbox on the server that says CN must match username (or something like that) is checked.example:
file tun01.ovpn (downloaded from pfSense and renamed)
dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote xxxxxxxxxxx 443 tcp-client
lport 0
verify-x509-name "openvpn_routed" name
auth-user-pass
pkcs12 tun01.p12
tls-auth tun01.key 1
ns-cert-type serverNote the last few lines and the cert names! The certificate files in the folder were renamed to tun01.p12 and tun01.key
I've been doing this for over a year. on multiple devices with different usernames on each. All use the same pc file name - tun01 or tun02. On each, the actual user name is NOT tun01 or tun02 or anything even close. the username MUST MATCH the cert name. If you use the wrong username IT WILL NOT CONNECT - even if the username is an otherwise valid username on the server. IT WORKS FINE!
If OpenVPN goes back to blanking out the last userid used on the pc, it will again be foolproof.
-
Renaming the file hides nothing from anyone. It is an unnecessary, useless step. That is my point. It is not a "security glitch."
The user name is STILL in the certificate bundle the file name references, in the clear.
$ openssl pkcs12 -in pfSense-a-udp-1195-testuser.p12
Enter Import Password:
MAC verified OK
Bag Attributes
localKeyID: CD 83 F7 D9 A2 44 34 6E 0F CD 5D DD B4 C2 BD 38 C6 7E AB A8
subject=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=testuser
issuer=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=test-openvpn-ca
–---BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t -
Renaming the file hides nothing from anyone. It is an unnecessary, useless step. That is my point. It is not a "security glitch."
The user name is STILL in the certificate bundle the file name references, in the clear.
$ openssl pkcs12 -in pfSense-a-udp-1195-testuser.p12
Enter Import Password:
MAC verified OK
Bag Attributes
localKeyID: CD 83 F7 D9 A2 44 34 6E 0F CD 5D DD B4 C2 BD 38 C6 7E AB A8
subject=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=testuser
issuer=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=test-openvpn-ca
–---BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t-
I just looked at my three files downloaded for pc config. These's no reference to the username. Perhaps it's there for different client downloads for different platforms. In other words, it works for me on my windows laptops but might not if I were not using a pc.
-
I just downgraded to openvn 2.3.14. The username is not preloaded as a default in this version. I'm secure again.
-
-
Horse. Water.
-
Horse. Water.
Download the standard archive and unzip it. You will get a folder with three files - none have a CN like your download files. I think the android or an inline download will, however.
If you don't believe me, believe your own eyes. Actually download one and look. Anyone with pfsense can do the same. They will see what I am describing.
One of the standard archive files looks encrypted - the p12 I think . It's probably in there somewhere ENCRYPTED.
edit: I had put excerpts from actual files here but decided against it and edited them out. Even a partial file is a security issue. I can create a fake user and download a profile if you're to unmotivated to see for yourself.
edit 2: No changed my mind. Your debating gravity. I'm done Trust me, it really exists. I described a very safe method for two plus factor security that anyone with a pc can use. It apparently won't work unless you use the standard zipped archive files. And OpenVPN 2.3.14 since newer versions retain the last used username field contents. I use it on my pc windows laptops and what I said can be validated in a few seconds by anyone with even a little self motivation.
-
@coffeecup25 I simply don't get what you are talking about. You take those files from the standard archive and rename them. Fine.
So now they aren't named like <firewallname>-<proto>-<port>-<user>.any but are called fred.p12, fred.key and fred.ovpn. Fine again.
Your real VPN user name is - just for example purposes -> fr3d981.So you say nothing in those files point to that name? That isn't the case with strict user CN matching active. With that option, your VPN user fr3d981 must have a matching cert with correct common name belonging to said name. So as @Derelict tries telling you, the .p12 file has this name in its CN Tag encoded. Thats nothing you can simply rename as the certificate itself is created with it.
We use that for remote access type of OpenVPN Servers all the time and regardless of using it in windows only or on Android, Linux, Mac or whatever, you can check on the correct username via certificate on all these systems because the CN simply HAS to match, otherwise it would not fulfill that option. And if you don't use strict user CN matching, you could use any cert valid from the same CA as a login factor, that's not what many of us wants. Just out of curiosity I checked a few of those "standard archive" packages and any .p12 file has its CN= value correctly set to the username it needs for logging in. Anything else would be very strange indeed.
And NO, this is not "encrypted" anywhere in the certificate but plain text readable as those certificated created via pfSense and the webGUI don't have a password set on them. You just hit enter.
Example:
Enter Import Password: (just hit enter) MAC verified OK Bag Attributes localKeyID: 4D 73 A3 1B A8 30 CC E1 E4 70 8E 21 90 2A 4F C6 37 91 7C 89 subject=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=jegr/OU=VPN issuer=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=Company - VPN/OU=VPNI x'ed the other values as they aren't important but the CN from the subject line. Regardless how you name the file, the CN is always there. Sorry, but I don't see how your renaming would add any security if you can check the username with a simple call to "openssl pkcs12 -in <certname>" - seems more like obscurity without security gain. No offense.
Greets</certname></user></port></proto></firewallname>
-
@coffeecup25 I simply don't get what you are talking about. You take those files from the standard archive and rename them. Fine.
So now they aren't named like <firewallname>-<proto>-<port>-<user>.any but are called fred.p12, fred.key and fred.ovpn. Fine again.
Your real VPN user name is - just for example purposes -> fr3d981.So you say nothing in those files point to that name? That isn't the case with strict user CN matching active. With that option, your VPN user fr3d981 must have a matching cert with correct common name belonging to said name. So as @Derelict tries telling you, the .p12 file has this name in its CN Tag encoded. Thats nothing you can simply rename as the certificate itself is created with it.
We use that for remote access type of OpenVPN Servers all the time and regardless of using it in windows only or on Android, Linux, Mac or whatever, you can check on the correct username via certificate on all these systems because the CN simply HAS to match, otherwise it would not fulfill that option. And if you don't use strict user CN matching, you could use any cert valid from the same CA as a login factor, that's not what many of us wants. Just out of curiosity I checked a few of those "standard archive" packages and any .p12 file has its CN= value correctly set to the username it needs for logging in. Anything else would be very strange indeed.
And NO, this is not "encrypted" anywhere in the certificate but plain text readable as those certificated created via pfSense and the webGUI don't have a password set on them. You just hit enter.
Example:
Enter Import Password: (just hit enter) MAC verified OK Bag Attributes localKeyID: 4D 73 A3 1B A8 30 CC E1 E4 70 8E 21 90 2A 4F C6 37 91 7C 89 subject=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=jegr/OU=VPN issuer=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=Company - VPN/OU=VPNI x'ed the other values as they aren't important but the CN from the subject line. Regardless how you name the file, the CN is always there. Sorry, but I don't see how your renaming would add any security if you can check the username with a simple call to "openssl pkcs12 -in <certname>" - seems more like obscurity without security gain. No offense.
Greets</certname></user></port></proto></firewallname>
If it's encoded then it's encrypted because nothing is readable in that file. NOTHING. Yet OpenVPN works fine and it won't connect unless the username matches the CN on the certificate. I used to work in IT and it frustrated me to no end when people argued about gravity even when proof of gravity was right in front of their nose. Generally they were thinking of things that had nothing to do with the example at hand yet resisted change and used arguing with gravity to fight change. IT people are by far the most resistant to new idea people I have ever met in my long life. If you can't fight gravity, then look for 'inconsistencies' or destroy reputations if all else fails. Ah … the good old days.
The excerpt in your post did not come from the p12 file I referenced. The reason I know is that some of it is humanly readable. Nothing in my p12 file is. So you must be looking in the wrong place ... the place that does work as you described ... not the place that works as I describe.
OpenVPN apparently supports several client config file formats. Your favorite will not support my objective. Mine does.
Or - just spitballing here - perhaps the CN field you see is not the CN the client program references to validate matching. Maybe the server does that using another method that matches the username to the certificate in use and, on the server, to the certificate the username should be using? Therefore, it's use is for something other than matching and an alternate OpenVPN client format does not necessarily require it. Just a guess.
Actually try it and you will see what I mean. Really. Gravity exists. I use it frequently.
You try to help someone out and get ganged up on by people who shriek ... "I don't do it that way and I never heard of it so it can't work and you are wrong. I will argue with you about it and ignore everything you say until you agree I am smarter than you." Why do I bother?
-
It's encoded with pkcs12 but it is NOT encrypted, bro. It's there for anyone to see.
SEE ALSO: pkcs12(1)
This is not "encrypted" either:
-----BEGIN CERTIFICATE----- MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t
