#
# This config requires OpenVPN => 2.3.2 and OpenSSL => 1.0.0
#

# The 443 below is the UDP port to connect to the VPN on.
# You can change it to anything between 1 and 29999.
# Useful if you're on a network that blocks UDP port 443.
remote balancer.cstorm.is 443 udp
remote balancer.cstorm.net 443 udp
remote balancer.cryptostorm.pw 443 udp

# Change the below to "auth-user-pass somefile" to login automatically.
# That way you're not prompted for the username/password every time you connect.
# The 'somefile' needs to be a file containing your token's SHA512 hash on the first line,
# and any random text on the second line.
auth-user-pass

# Uncomment the line below to enable our DNS-based ad/tracker blocking service.
#dhcp-option DNS 10.31.33.7

# You probably don't need to change anything below these lines.

# Client mode
client

# tun devices encapsulate IPv4 or IPv6 (OSI Layer 3).
# tap devices encapsulate Ethernet 802.3 (OSI Layer 2).
# This is a VPN service for OSI Layer 3, so don't change this to tap.
dev tun

# "If hostname resolve fails for --remote, retry resolve for 16 seconds before failing."
resolv-retry 16

# "Require that peer certificate was signed with an explicit key usage and extended key usage based on
# RFC3280 TLS rules. This is a useful security option for clients, to ensure that the host they connect
# to is a designated server. This is an important security precaution to protect against a
# man-in-the-middle attack where an authorized client attempts to connect to another client by
# impersonating the server. The attack is easily prevented by having clients verify the server certificate
remote-cert-tls server

# "Accept connections only if a host's X.509 name is equal to name.
# The remote host must also pass all other tests of verification."
# This covers the scenario where a server gets confiscated/hacked by 'whoever', and 'whoever' also has the
# ability to perform a man-in-the-middle attack against traffic coming into another server
# (or leaving a client). They could use the stolen server certificate/key to impersonate that other server,
# if the CN is the same (or the verify command below wasn't used).

# Randomize the above node list as a kind of basic load-balancing.
# Not really necessary since balancing happens at the DNS level.
remote-random

# "Call --down cmd/script before, rather than after, TUN/TAP close."
# No down cmd/script is used in this configuration, but most Linux users will be adding an up/down script
# that updates the system's DNS. Without this the system would have to wait for the tunnel to close before
# it could update the DNS, which might lead to DNS resolution failures until TUN closes.
down-pre

# Increase --verb for more verbosity, 0 to disable (except fatal errors).
verb 4

# "Log at most 3 consecutive messages in the same category"
# Helps prevent the logs or STDOUT from getting flooded with the same messages.
mute 3

# This is necessary in UDP mode because otherwise it can take about 2 minutes for the server to timeout the session,
# which is also when the session counter decreases, so quickly disconnecting then reconnecting might cause
# authorization failed errors if your token has a low device limit as with the one week or one month tokens.
# explicit-exit-notify tells the server to immediately close it's client instance object whenever the client disconnects,
# which means the session counter is decreased immediately. The 3 is the maximum number of attempts that the client
# will try to resend the exit notification message.
explicit-exit-notify 3

# Uncomment the below line to enable --auth-nocache
#auth-nocache
# "this directive will cause OpenVPN to immediately forget username/password inputs after they are used".
# We're not enabling it because, for users that are inputting their token using standard input,
# it can be annoying since OpenVPN will constantly ask them for their token on every TLS renegotiation.
# For those providing a file to --auth-user-pass, --auth-nocache has no effect.

# "If an AEAD cipher mode (e.g. GCM) is chosen, the specified --auth algorithm is ignored for the data channel, 
# and the authentication method of the AEAD cipher is used instead."
# The default legacy cipher for these RSA configs is AES-256-CBC, with negotiable support for AES-256-GCM (see below)
auth SHA512

# This is the cipher that will encrypt OpenVPN's "data channel", i.e. your actual traffic.
cipher AES-256-CBC
# AES-256 = "256 bit key, 128 bit block". We recommend GCM over CBC mostly because it's more efficient.
# Here's a speed test of CBC vs GCM on a random Linux system:
#  echo $(($(openssl speed -mr -evp aes-256-cbc -bytes 128 2>&1|tail -n1|awk -F: '{print int($NF)}')/1024/1024))MBps
#  431MBps
#  echo $(($(openssl speed -mr -evp aes-256-gcm -bytes 128 2>&1|tail -n1|awk -F: '{print int($NF)}')/1024/1024))MBps
#  815MBps
# That means GCM encrypts data almost twice as fast as CBC, so long as your CPU supports the AES-NI instruction.
# If your CPU doesn't support AES-NI, CBC would perform better:
#  export OPENSSL_ia32cap="~0x200000200000000" # This temporarily disables AES-NI
#  echo $(($(openssl speed -mr -evp aes-256-cbc -bytes 128 2>&1|tail -n1|awk -F: '{print int($NF)}')/1024/1024))MBps
#  218MBps
#  echo $(($(openssl speed -mr -evp aes-256-gcm -bytes 128 2>&1|tail -n1|awk -F: '{print int($NF)}')/1024/1024))MBps
#  133MBps
# Only clients using very old versions of OpenVPN will get AES-256-CBC, for everyone else the server will use 
# --data-ciphers (formerly called --ncp-ciphers) to negotiate the cipher to AES-256-GCM.
# If you really want to use CBC, and you have OpenVPN 2.5, you can use --data-ciphers AES-256-CBC to force CBC mode.
# But if you're using OpenVPN 2.5, then you should just use the ECC configs and --cipher CHACHA20-POLY1305 instead.
# If you've got anything before 2.5, you can use --ncp-ciphers AES-256-CBC to force CBC mode.
# The padding oracle attack against CBC described @ https://en.wikipedia.org/wiki/Padding_oracle_attack doesn't apply 
# in this context since OpenVPN will use an HMAC, and OpenVPN's CBC does encrypt-then-mac, not mac-then-encrypt.

# Minimum TLS version allowed is 1.2 to prevent downgrade attacks.
tls-version-min 1.2

# The below tls-cipher defines the encryption algorithm used to encrypt the control channel:
#  "OpenVPN uses TLS to secure the control channel, over which the keys that
#  are used to protect the actual VPN traffic are exchanged."
# Elliptic Curve Diffie-Hellman + Elliptic Curve Digital Signature Algorithm with ChaCha20-Poly1305 + SHA256,
# which is what we recommend, but if it's unavailable, then instead
# Elliptic Curve Diffie-Hellman + Elliptic Curve Digital Signature Algorithm with AES-256-GCM + SHA384 is used,
# and if that's unavailable then
# Diffie-Hellman + RSA with AES-256-CBC-SHA is used, and perfect forward secrecy is provided using 8192-bit DH params server-side.
# The CA certificate uses secp521r1 and the server certificate uses 8192-bit RSA.
tls-cipher TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA

# "Enable TLS and assume client role during TLS handshake."
tls-client

# The CA certificate, which uses secp521r1 for the key and ecdsa-with-SHA512 for the signature algorithm.
# secp521r1 is a 521-bit elliptic curve, roughly equivalent to 15360-bit RSA, however some people choose
# not to use it because it's an NIST curve - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
# There was an incident involving the https://en.wikipedia.org/wiki/Dual_EC_DRBG algorithm where a backdoor
# was deliberately inserted by the NSA, and even though weaknesses in the algorithm's cryptographic security
# were publicly known, it was still included in https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
# Some cryptographers believe that if the NIST allowed something like that once, they'll probably do it again.
# There are no publicly known cryptographic weaknesses in secp521r1, but if you're still concerned about potential
# backdoors in secp521r1, you should use our ed25519 or ed448 configs (or WireGuard).
# The only reason we're not using ed25519/ed448 by default is because a lot of our customers are still using older
# versions of OpenVPN/OpenSSL that don't yet support ed25519/ed448.
# This part of the config is what prevents man-in-the-middle attacks from succeeding. If an attacker redirected you
# to their own malicious server, OpenVPN would spit out an error because that server wouldn't be able to generate a
# valid server certificate/key pair because they wouldn't have the CA's private key.
# We practice secure PKI management as described in https://community.openvpn.net/openvpn/wiki/Hardening
# which means that the CA private key is never stored on any of our VPN servers.
<ca>
-----BEGIN CERTIFICATE-----
MIICCzCCAW2gAwIBAgIUMRTTJ6nuPjmSxaRfbw5f+dZ9d/gwCgYIKoZIzj0EAwQw
GTEXMBUGA1UEAwwOY3J5cHRvc3Rvcm0gQ0EwHhcNMTgwOTE3MjAwODU4WhcNMzgw
OTE3MjAwODU4WjAZMRcwFQYDVQQDDA5jcnlwdG9zdG9ybSBDQTCBmzAQBgcqhkjO
PQIBBgUrgQQAIwOBhgAEARKu20PBrr226TP6mQQGtzCqQqBKfGaA05Ml5nrGSV6w
zBQDQga4/cPepGrE/tpzRX72KSfZD6nJfQLYen7kdc3PAEvWFBhCovq7e4L6xJ5q
V5aMf89QjNhJ/xn//dlxE8Z6UfIx63dJX9q3EHNxateU84lDkbCrqckkckcZF4C1
a9Ooo1AwTjAdBgNVHQ4EFgQUdaVDaoi48Yf2RugXqJ4yJ4Z4utgwHwYDVR0jBBgw
FoAUdaVDaoi48Yf2RugXqJ4yJ4Z4utgwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
BAOBiwAwgYcCQVcCw/8OVpNqltDYczqHmX4sMRsZTY0iIzl1rYY/0/ZPIvzjlMFn
ouHwb8asJZRMBNECq7u9PCbG3jdu6lYtcCm+AkIB3IYYKuXLKW7ucdttNODBqH2R
ail+9oBWTV2ZFKVVwELlKadHx9UvAcpAaV1alkN80CgI2tad2/qVdpSIQpfVvTI=
-----END CERTIFICATE-----
</ca>

# "Add an additional layer of HMAC authentication on top of the TLS control channel"
# Helps prevent DoS attacks by minimizing the amount of resources an unauthenticated client is able to consume,
# and also makes attacks against the TLS stack that much more difficult.
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
5de9814eb021477ce3b58638031072c5
b20f34a9f3c417bc95df950ae37bdbf4
12aa255734184171a9c46f8251cf9207
6c1d352ddcd7c71a411d7872d8d50090
b06fd70801dda425cd4ee474a81d2367
a372a22db2baeee2ef7ac1c4a9dd4867
32bd978244db2ae2dbfcb5ab3b8669bc
9c35e0a48e298109e9acff687d5698db
7a864247b38e036187cfdf81feefc388
411767b66891056abef9ffc6a2464428
e0ccbf8130536473a71b10263c7dafdb
160da61d4402be6a10d47c9fe08e57dd
121c6b7d2e6d767c1a18dc0aa6567d56
26e020308ed197b5bfc7374b3d135085
31afcf87e1ae90ec20ee072100daf478
5aaa3bce8db5d6eabef2495752c849b6
-----END OpenVPN Static key V1-----
</tls-auth>

# The server uses 'key-direction 1' for the above static key, so the client needs to use the opposite.
key-direction 0