OpenVPN infrastructure

From Wikipedia, the free encyclopedia

OpenVPN Infrastructure describes any specific implementation of OpenVPN servers and clients to provide a certain type, quality, and quantity of secure network interconnection between them. This encompasses the sets of keys, certificates, signatures, and associated trust relationships used to authenticate and encrypt OpenVPN tunnels. This also includes design decisions made to effect a working infrastructure, such as encryption type, tunnel type (tap vs. tun), compression, and persistence.

Major infrastructure design choices include:

• Trust Model: Use of a trust chain that stems from a CA, or use of peer-based trust.
• Authentication Model: Use of CA based PKI, peer-peer PKI, key possession, or passphrase between endpoints.
• Encryption Model: Symmetric (Use of shared secret keys), or asymmetric (a PKI based on public/private key pairs), which can include a CA.
• Number of links: Is the infrastructure a single point-to-point link between a client and server, or will the server support multiple connections?
• Multiple Link Implementation: One link per openVPN server configuration, or multiple links per configuration?
• Transport: UDP or TCP. Port 1194 is the default. TCP over TCP can stall, however.

This list is not exhaustive.

Most of these decisions can be combined in different ways, so some exemplary types are given. A simple symmetric peering design and a complex asymmetric PKI hierarchical design are each described below. These approximately illustrate the range of available complexity. Other permutations are possible, notably the non-keyed passphrase-only infrastructure.

[edit] Simple: OpenVPN Shared Static Key

This infrastructure is the simplest: Each side uses the same shared static key to encrypt the VPN. The key is shared by some safe transport mechanism, such as a USB drive or QKD (Quantum key distribution). If the key is compromised, all past messages in both directions can be decrypted by the attacker.

It is suitable for automated tunnel setup/teardown, because no interactive/file passwords are used.

Creation of an example key (chosen here to be static.key) illustrates this infrastructure:

keymaker@safeplace:~# openvpn --genkey --secret static.key
keymaker@safeplace:~# file static.key
static.key: ASCII text

secret static.key
# ifconfig 10.99.99.1 10.99.99.2
# dev tun
#

secret static.key
# ifconfig 10.99.99.2 10.99.99.1
# dev tun
# remote openvpnserver.serverdomain.tld

...that's it. This defaults to UDP 1194, so appropriate rulesets for intermediary firewalls must be crafted.

This is symmetric cryptography.

[edit] OpenVPN PKI, with CA, over TLS

This infrastructure is very scalable and flexible, at the expense of complexity. Everybody trusts the CA. All keys/certificates rooted at this CA are used to negotiate and validate a TLS connection channel. Separate random session keys are negotiated over this channel and used for the tunnel.

[edit] The CA

The CA does not need to be on the same system as the OpenVPN server. It is safer to have it in a less accessible place. A public/private key pair is cut and used as follows:

• CA key (CA private key, ca.key) secret, used to sign certs, is the root of trust
• CA cert (CA signed CA public key, ca.crt) signed by CA, used by everyone to check CA signatures, The root certificate. X.509 PEM format.

keymaker@safeplace:$KEY_DIR# openssl req -days 3650 -nodes -new -x509 -keyout ca.key -out ca.crt -config $KEY_CONFIG

[edit] The OpenVPN Server

A public/private key pair is cut and used as follows:

• Server Key (Server private key) secret
• Server Cert (signed Server public key) signed by CA
• DH Parameters for Diffie-Hellman key exchange protocol, in PEM format

root@server:~# openssl dhparam -out permkey.pem 1024
root@server:~# openssl req -nodes -new -keyout servercert.key -out servercert.csr
   ...scp to keymaker...
keymaker@safeplace:~# openssl ca -out servercert.crt -in servercert.csr
   ...scp back to server...
root@server:~# file servercert.crt
servercert.crt:  ASCII text

[edit] An OpenVPN Client

A public/private key pair is cut and used as follows:

• Client Key (Client private key) secret
• Client Cert (signed Client public key) signed by CA

root@client:~# openssl req -nodes -new -keyout clientcert.key -out clientcert.csr
   ...scp to keymaker...
keymaker@safeplace:~# openssl ca -out clientcert.crt -in clientcert.csr
   ...scp back to client...
root@client:~# file clientcert.crt
clientcert.crt:  ASCII text

[edit] Configurations

ccd-exclusive   # make sure the client config file is present
tls-server      # invoke TLS control channel negotiation
dh dh1024.pem   #   
ca ca.crt       # to check clientcert.crt
cert servercert.cert
key servercert.key

#--------------#
tls-client     # so the negotiation can be accepted
remote server-IP
ca ca.crt      # to check servercert.crt
cert clientcert.crt
key clientcert.key

This is Asymmetric cryptography.

[edit] Orthogonal Options:

[edit] Channel Hardening with tls-auth

HMAC signature (of cyphertext) appended to all SSL/TLS packets. Signature is generated by a shared secret, ta.key.

keymaker@safeplace:~# openvpn --genkey --secret ta.key

tls-auth ta.key 0

tls-auth ta.key 1

Packets failing the signature check (which include DoS attacks and port probes) get dropped.

[edit] Passphrase-encrypted keys

Unless -nodes is used during key generation, the key will be passphrase protected.

askpass   #get password from console (or file when --enable-password-save is built in)

[edit] References

OpenVPN man page [1]
OpenVPN Static Key Mini-HOWTO [2]