4 ms·

If your budget is tight you might consider the following for MF for your VPNs: pfSense VM at work with a single interface and an OpenVPN server listening with

If your budget is tight you might consider the following for MF for your VPNs: pfSense VM at work with a single interface and an OpenVPN server listening with a server cert minted from your AD CA - this is your VPN concentrator. You get your OpenVPN server to hand off auth to RADIUS which is a DC with the NPS service installed. Mint SSL certs for all your domain joined users and computers via your AD CA. Investigate this parameter: cryptoapicert "SUBJ:" on your OpenVPN clients. All of this stuff is documented in various places and I've dropped most of the clues! You can actually fold in more factors with this. So the PC/user must have a SSL cert minted by the AD CA and a password, and a OTP via something like Google authenticator. I'd start with short lived (say one month) AD minted SSL certs and then decide whether you need more factors. Remember that a domain joined PC doesn't work very well at password change time if encryption and VPN connections rely on AD passwords. Now, once you allow your folks on site - what do you allow them to access? Get your firewall rules sorted.

nszceta 5y ago
This is hilariously complicated compared to deploying Wireguard VPN
- gerdesj 5y ago
  Wireguard, OpenVPN, IPSEC etc are just ways of shuffling packets of data with encryption. What I'm describing is actually a really easy or at least really cheap way for an organisation to grab an extra factor when authenticating their VPNs. There are loads of howtos (most are completely wank but there are some decent ones) on minting AD SSL certs for users and computers. That's something you "have". You could simply use SSL certs or you could also insist on a username and maybe a password ("something you know"). You use RADIUS because that is a long, long standard way of meditating auth/auth to facility.
- jcrawfordor 5y ago
  Compared to Wireguard with MFA? as far as I can tell Wireguard doesn't support MFA at all. Pure key auth is not acceptable in these contexts because of stolen keys and devices.
  - nszceta 5y ago
    Rotate keys regularly through a secure channel. At some point these discussions devolve into a variant of "Which ammunition is least likely to kill me when I inevitably shoot myself?"
    - gruez 5y ago
      >Rotate keys regularly through a secure channel the secure channel being...? The point of "complicated" solutions like this is that the complicated stuff is done by the sysadmin, not the user.
      - deleted 5y ago
        [deleted]
  - mbreese 5y ago
    You could probably setup MFA with WireGuard using firewall rules, but I haven’t done it personally. But now I’m curious to see if it could be done.
    - KMag 5y ago
      I think instead of firewall rules, it's better to use WireGuard pre-shared keys. WireGuard supports per-peer 256-bit pre-shared keys that get hashed with the ECDH result when setting up the session keys. If you've set up WireGuard without pre-shared keys, then behind the scenes the all-zero pre-shared key is used. These pre-shared keys are set in the WireGuard server from userspace via ioctls. If the peer doesn't know its assigned pre-shared key, it's unable to complete the WireGuard key negotiation. So, you can use this mechanism to have a userspace daemon enable and disable WireGuard peers. This morning, I was looking into a daemon to use a post-quantum algorithm and 2FA to set up a new WireGuard peer for 24 hours. Grover's quantum search algorithm effectively cuts the 256-bit pre-shared key to 128 bits, but if you use post-quantum algorithms to secure the pre-shared key generation, even a powerful quantum attacker has to do 2**128 work for every 24-hour session they want to break. The post-quantum algorithms are a bit computationally expensive, but they only need to be done every 24 hours to still give you forward secrecy against a quantum attacker. The idea is the daemon exposes long-term Curve25519, NTRU, and Classic McEliece public keys. The client generates a new Curve25519 keypair to use as the 24-hour WireGuard peer's identity. The client sets up an encrypted session using the hash of all 3 key exchange mechanisms as the session's symmetric key. The username and a timestamp are sent to the auth server, which responds with the user's password salt, along with ephemeral Curve25519, NTRU, and McEliece values. The pre-shared key for the 24-hour WireGuard peer is the hash of all three ephemeral key agreements (using the same client-side ephemeral keys used in setting up the encrypted channel) concatenated with the Argon2 hash of the user's password and the RFC 6238 TOTP (Google Authenticor) time-based value. If the client responds with a correct Poly1305 MAC (using the auth session key) on the 24-hour pre-shared key, then the daemon will set up the 24-hour peer using that pre-shared key (using ioctl sycalls to communicate with the WireGuard kernel module). After 24 hours, the daemon removes the new peer. Note that Grover's quantum search algorithm will cut the 256-bit pre-shared key and the ChaCha20-Poly1305 256-bit keys down to effectively 128 bits. Even if Curve25519 and one of the two post-quantum algorithms used are completely broken, you still get a secure channel. You lose perfect forward secrecy, getting forward secrecy blocked to 24-hour chunks. If Cruve25519, NTRU, and McElice are all broken, then you lose forward secrecy (and the attacker can read the user names, but presumably traffic pattern analysis is pretty good at identifying the user anyway) and the password is the weak point, vulnerable to Grover's quantum search algorithm. The strongest password I've memorized and used in production was a wordlist generated from 128 bits from /dev/urandom. I'm weird; 99.9% of users would rebel at memorizing 160-bit to 256-bit passwords. In order to prevent user enumeration, if a user doesn't exist, instead of returning an Argon2 passowrd salt, return some concatenated siphash values (with secret keys) of the username (so repeated queries for non-existing users give consistent results). I've also worked out how to use key rotation to get non-existing users changing their password salts every 60 days (as wold happen when real users change their passwords), but have the offsets uniformly distributed, so all of the fake users don't appear to change their passwords the same day.
- neeleshs 5y ago
  If you are in gsuite, you can easily turn on 2fa for OpenVPN. OpenVPN + Gsuite LDAP + Authenticator.
  - XorNot 5y ago
    This user experience still sucks, and it doesn't have to. Every company I've ever worked for hands me a corporate laptop and says "you must use this". The laptop always sucks. But that's not the point, the point is: the laptop is something I have. Why in the heck are we not doing remote attestation with TPMs?
    - DHPersonal 5y ago
      Stealing the laptop would be too easy a method for gaining access though, wouldn’t it? With a key- or code-based 2FA method I would not have to carry the laptop everywhere to keep my account safe.
zomgwat 5y ago
Duo is another option for a nice OpenVPN MFA option. https://duo.com/docs/openvpn https://duo.com/docs/openvpn

nszceta 5y ago

This is hilariously complicated compared to deploying Wireguard VPN

gerdesj 5y ago
Wireguard, OpenVPN, IPSEC etc are just ways of shuffling packets of data with encryption. What I'm describing is actually a really easy or at least really cheap way for an organisation to grab an extra factor when authenticating their VPNs. There are loads of howtos (most are completely wank but there are some decent ones) on minting AD SSL certs for users and computers. That's something you "have". You could simply use SSL certs or you could also insist on a username and maybe a password ("something you know"). You use RADIUS because that is a long, long standard way of meditating auth/auth to facility.
jcrawfordor 5y ago
Compared to Wireguard with MFA? as far as I can tell Wireguard doesn't support MFA at all. Pure key auth is not acceptable in these contexts because of stolen keys and devices.
- nszceta 5y ago
  Rotate keys regularly through a secure channel. At some point these discussions devolve into a variant of "Which ammunition is least likely to kill me when I inevitably shoot myself?"
  - gruez 5y ago
    >Rotate keys regularly through a secure channel the secure channel being...? The point of "complicated" solutions like this is that the complicated stuff is done by the sysadmin, not the user.
    - deleted 5y ago
      [deleted]
- mbreese 5y ago
  You could probably setup MFA with WireGuard using firewall rules, but I haven’t done it personally. But now I’m curious to see if it could be done.
  - KMag 5y ago
    I think instead of firewall rules, it's better to use WireGuard pre-shared keys. WireGuard supports per-peer 256-bit pre-shared keys that get hashed with the ECDH result when setting up the session keys. If you've set up WireGuard without pre-shared keys, then behind the scenes the all-zero pre-shared key is used. These pre-shared keys are set in the WireGuard server from userspace via ioctls. If the peer doesn't know its assigned pre-shared key, it's unable to complete the WireGuard key negotiation. So, you can use this mechanism to have a userspace daemon enable and disable WireGuard peers. This morning, I was looking into a daemon to use a post-quantum algorithm and 2FA to set up a new WireGuard peer for 24 hours. Grover's quantum search algorithm effectively cuts the 256-bit pre-shared key to 128 bits, but if you use post-quantum algorithms to secure the pre-shared key generation, even a powerful quantum attacker has to do 2**128 work for every 24-hour session they want to break. The post-quantum algorithms are a bit computationally expensive, but they only need to be done every 24 hours to still give you forward secrecy against a quantum attacker. The idea is the daemon exposes long-term Curve25519, NTRU, and Classic McEliece public keys. The client generates a new Curve25519 keypair to use as the 24-hour WireGuard peer's identity. The client sets up an encrypted session using the hash of all 3 key exchange mechanisms as the session's symmetric key. The username and a timestamp are sent to the auth server, which responds with the user's password salt, along with ephemeral Curve25519, NTRU, and McEliece values. The pre-shared key for the 24-hour WireGuard peer is the hash of all three ephemeral key agreements (using the same client-side ephemeral keys used in setting up the encrypted channel) concatenated with the Argon2 hash of the user's password and the RFC 6238 TOTP (Google Authenticor) time-based value. If the client responds with a correct Poly1305 MAC (using the auth session key) on the 24-hour pre-shared key, then the daemon will set up the 24-hour peer using that pre-shared key (using ioctl sycalls to communicate with the WireGuard kernel module). After 24 hours, the daemon removes the new peer. Note that Grover's quantum search algorithm will cut the 256-bit pre-shared key and the ChaCha20-Poly1305 256-bit keys down to effectively 128 bits. Even if Curve25519 and one of the two post-quantum algorithms used are completely broken, you still get a secure channel. You lose perfect forward secrecy, getting forward secrecy blocked to 24-hour chunks. If Cruve25519, NTRU, and McElice are all broken, then you lose forward secrecy (and the attacker can read the user names, but presumably traffic pattern analysis is pretty good at identifying the user anyway) and the password is the weak point, vulnerable to Grover's quantum search algorithm. The strongest password I've memorized and used in production was a wordlist generated from 128 bits from /dev/urandom. I'm weird; 99.9% of users would rebel at memorizing 160-bit to 256-bit passwords. In order to prevent user enumeration, if a user doesn't exist, instead of returning an Argon2 passowrd salt, return some concatenated siphash values (with secret keys) of the username (so repeated queries for non-existing users give consistent results). I've also worked out how to use key rotation to get non-existing users changing their password salts every 60 days (as wold happen when real users change their passwords), but have the offsets uniformly distributed, so all of the fake users don't appear to change their passwords the same day.
neeleshs 5y ago
If you are in gsuite, you can easily turn on 2fa for OpenVPN. OpenVPN + Gsuite LDAP + Authenticator.
- XorNot 5y ago
  This user experience still sucks, and it doesn't have to. Every company I've ever worked for hands me a corporate laptop and says "you must use this". The laptop always sucks. But that's not the point, the point is: the laptop is something I have. Why in the heck are we not doing remote attestation with TPMs?
  - DHPersonal 5y ago
    Stealing the laptop would be too easy a method for gaining access though, wouldn’t it? With a key- or code-based 2FA method I would not have to carry the laptop everywhere to keep my account safe.

zomgwat 5y ago

Duo is another option for a nice OpenVPN MFA option. https://duo.com/docs/openvpn https://duo.com/docs/openvpn