1
1
mirror of https://github.com/namibia/openvpn-install.git synced 2024-11-17 09:45:11 +00:00

Rewrite README

Rewrite the encryption part, update with OpenVPN 2.4 stuff, improve FAQ, correct typos
This commit is contained in:
angristan 2018-09-23 00:43:05 +02:00
parent c2a502be92
commit ba1fc42aac

223
README.md
View File

@ -31,22 +31,25 @@ When OpenVPN is installed, you can run the script again, and you will get the ch
- Remove a client
- Uninstall OpenVPN
In your home directory, you will have `.ovpn` files. These are the client configuration files. Download them from your server and connect using your prefered OpenVPN client.
In your home directory, you will have `.ovpn` files. These are the client configuration files. Download them from your server and connect using your favorite OpenVPN client.
If you have any question, head to the [FAQ](#faq) first.
## Features
- Installs and configures a ready-to-use OpenVPN server
- Iptables rules and forwarding managed in a seamless way
- If needed, the script can cleanly remove OpenVPN, including configuration and iptables rules
- Customizable encryption settings, enhanced default settings
- Varitey of DNS resolvers to be pushed to the clients
- Customisable encryption settings, enhanced default settings (see [Security and Encryption](#security-and-encryption) below)
- OpenVPN 2.4 features, mainly encryption improvements (see [Security and Encryption](#security-and-encryption) below)
- Varietey of DNS resolvers to be pushed to the clients
- Choice to use a self-hosted resolver with Unbound (supports already existing Unboud installations)
- Choice between TCP and UDP
- NATed IPv6 support
- Compression disabled by default to prevent VORACLE. LZ4 and LZ0 algorithms available otherwise.
- Unprivileged mode: run as `nobody`/`nogroup`
- Block DNS leaks on Windows 10
- Randomized server certificate name
- Randomised server certificate name
- Choice to protect clients with a password (private key encryption)
- Many other little things!
@ -75,7 +78,7 @@ To be noted:
This script is based on the great work of [Nyr and its contributors](https://github.com/Nyr/openvpn-install).
Since 2016, the two scripts have diverged and are not alike anymore, especially under the hood. The main goal of the script was enhanced security. But since then, the script has been completely rewritten and a lot a features have been added. The script is only comptaible with recent distributions though, so if you need to use a very old server or client, I advise using Nyr's script.
Since 2016, the two scripts have diverged and are not alike anymore, especially under the hood. The main goal of the script was enhanced security. But since then, the script has been completely rewritten and a lot a features have been added. The script is only compatible with recent distributions though, so if you need to use a very old server or client, I advise using Nyr's script.
## FAQ
@ -89,7 +92,19 @@ Since 2016, the two scripts have diverged and are not alike anymore, especially
---
**Q:** The script has been udpated since I installed OpenVPN. How do I update?
**Q:** Which OpenVPN client do you recommend?
**A:** If possible, an official OpenVPN 2.4 client.
- Windows: [The official OpenVPN community client](https://openvpn.net/index.php/download/community-downloads.html).
- Linux: The `openvpn` package from your distribution. There is an [official APT repository](https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos) for Debian/Ubuntu based distributions.
- macOS: [Tunnelblick](https://tunnelblick.net/).
- Android: [OpenVPN for Android](https://play.google.com/store/apps/details?id=de.blinkt.openvpn).
- iOS: I don't own an iOS device. Please let me know if you find a fully 2.4-compatible client.
---
**Q:** The script has been updated since I installed OpenVPN. How do I update?
**A:** You can't. Managing updates and new features from the script would require way too much work. Your only solution is to uninstall OpenVPN and reinstall with the updated script.
@ -103,151 +118,173 @@ You can, of course, it's even recommended, update the `openvpn` package with you
---
**Q:** Is there an OpenVPN documentation?
**A:** Yes, please had to the [OpenVPN Manual](https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage), which references all the options.
---
**Q:** Can I use an OpenVPN 2.3 client?
**A:** Yes. I really recommend using an up-to-date client, but if you really need it, choose the following options:
- No compression or LZ0
- RSA certificate
- DH Key
- AES CBC
- tls-auth
If your client is <2.3.3, remove `tls-version-min 1.2` from your `/etc/openvpn/server.conf` and `.ovpn` files.
---
**Q:** IPv6 is not working on my Hetzner VM
**A:** This an issue on their side. See [issue #295](https://github.com/angristan/openvpn-install/issues/295).
---
## Encryption
## Security and Encryption
The main reason why I made this fork is to improve the encryption. Indeed, OpenVPN's default parameters are weak (and that's what [Nyr's script](https://github.com/Nyr/openvpn-install) uses).
OpenVPN's default settings are pretty weak regarding encryption. This script aims to improve that.
I want to justify all my choices regarding the encryption settings I have chosen, to prove that I'm not some random noob as some may think. 😉
OpenVPN 2.4 was a great update regarding encryption. It added support for ECDSA, ECDH, AES GCM, NCP and tls-crypt.
However I'm far from a crypto expert, so don't hesitate to doubt what I say (I put links to my sources anyway), and to open an issue to correct me.
If you want more information about an option mentioned below, head to the [OpenVPN manual](https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage). It is very complete.
OpenVPN 2.4 will be a great update on the encryption part, because we'll be able to use elliptic curves, so ECDSA and ECDH (as well for the control channel), and AES GCM. They are faster and more secure. I will, of course, update the script when it will be available.
Most of OpenVPN's encryption-related stuff is managed by [Easy-RSA](https://github.com/OpenVPN/easy-rsa). Defaults parameters are in the [vars.example](https://github.com/OpenVPN/easy-rsa/blob/v3.0.6/easyrsa3/vars.example) file.
### Compression
**Note:** With OpenVPN's default parameters, you have a relatively weak encryption. Nonetheless, your trafic is still encrypted, so unless you're under surveillance, probably no one will try to decrypt it. Yet it's not a reason to use old and weak algorithm when there are much better ones available. 😉
By default, OpenVPN doesn't enable compression. This script provides support for LZ0 and LZ4 algorthms, the latter being more efficient.
However, it is discouraged to use compression since it since the [VORACLE attack](https://protonvpn.com/blog/voracle-attack/) makes use of it.
### TLS version
OpenVPN uses TLS 1.0 by default, which is nearly [20 years old](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.0).
OpenVPN accepts TLS 1.0 by default, which is nearly [20 years old](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.0).
With `tls-version-min 1.2` we use at least TLS 1.2, which the best protocol available currently. I could have used `tls-version-min highest` but this does not ensure we use TLS 1.2 which is the only secure protocol available.
With `tls-version-min 1.2` we enforce TLS 1.2, which the best protocol available currently for OpenVPN.
[OpenVPN documentation for tls-version-min](https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage#lbAK)
TLS 1.2 is only supported since OpenVPN 2.3.3. This is one of the reasons of the script uses third-party repositories, because some distributions have an older version of OpenVPN.
TLS 1.2 is supported since OpenVPN 2.3.3.
### Certificate
#### Key
OpenVPN uses an RSA certificate with a 2048 bits key by default.
OpenVPN uses an RSA certificate with a 2048 bits key [by default](https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/vars.example#L97).
OpenVPN 2.4 added support for ECDSA. Elliptic curve cryptography is faster, lighter and more secure.
2048 bits is OK, but both [NSA](https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf) and [ANSSI](https://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf) recommend at least a 3072 bits for a future-proof key. As the size of the key will have an impact on speed, I leave the choice to use 2048, 3072 or 4096 bits RSA key. 4096 bits is what's most used and recommened today, but 3072 bits is still good.
This script provides:
In OpenVPN 2.4, we will be able to use an ECDSA certificate. This algorithm uses elliptic curves instead of prime numbers' factorization for a reduced key size and calculation time, thus it's faster and more secure.
- ECDSA: `secp256r1`/`secp384r1`/`secp521r1` curves
- RSA: `2048`/`3072`/`4096` bits keys
#### Signature hash
It defaults to ECDSA with `secp256r1`.
OpenVPN uses SHA-256 [by default](https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/vars.example#L192).
OpenVPN uses `SHA-256` as the signature hash by default, and so does the script. It provides no other choice as of now.
It also supports SHA1 and MD5, which are unsafe, and all the SHA2 family. I didn't find any reason to use something other than SHA-256 in the SHA2 group, so the script still uses the default hash algorithm.
### Data channel
### Data channel's cipher
By default, OpenVPN uses `BF-CBC` as the data channel cipher. Blowfish is an old (1993) and weak alogorithm. Even the official OpenVPN documentation admits it.
By default, OpenVPN uses `BF-CBC` as the data channel cipher. Blowfish is an old (1993) and weak alogorithm. What's *funny* is that even the official OpenVPN documentation admits it.
>The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode.
Using BF-CBC is no longer recommended, because of its 64-bit block size. This small block size allows attacks based on collisions, as demonstrated by SWEET32. See https://community.openvpn.net/openvpn/wiki/SWEET32 for details.
[Source](https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage#lbAI)
> The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode.
>
> Using BF-CBC is no longer recommended, because of its 64-bit block size. This small block size allows attacks based on collisions, as demonstrated by SWEET32. See https://community.openvpn.net/openvpn/wiki/SWEET32 for details.
>Security researchers at INRIA published an attack on 64-bit block ciphers, such as 3DES and Blowfish. They show that they are able to recover plaintext when the same data is sent often enough, and show how they can use cross-site scripting vulnerabilities to send data of interest often enough. This works over HTTPS, but also works for HTTP-over-OpenVPN. See https://sweet32.info/ for a much better and more elaborate explanation.
>
> OpenVPN's default cipher, BF-CBC, is affected by this attack.
[Source](https://community.openvpn.net/openvpn/wiki/SWEET32)
>Blowfish's use of a 64-bit block size (as opposed to e.g. AES's 128-bit block size) makes it vulnerable to birthday attacks, particularly in contexts like HTTPS. In 2016, the SWEET32 attack demonstrated how to leverage birthday attacks to perform plaintext recovery (i.e. decrypting ciphertext) against ciphers with a 64-bit block size such as Blowfish.[9]
>A reduced-round variant of Blowfish is known to be susceptible to known-plaintext attacks on reflectively weak keys. Blowfish implementations use 16 rounds of encryption, and are not susceptible to this attack. Blowfish users are encouraged by Bruce Schneier, Blowfish's creator, to use the more modern and computationally efficient alternative Twofish. He is quoted in 2007 as saying:
>"At this point, though, I'm amazed it's still being used. If people ask, I recommend Twofish instead."
[Source](https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors)
Convinced ?
The [SWEET32 vulnerability page](https://community.openvpn.net/openvpn/wiki/SWEET32) from OpenVPN's documentation says :
>The following ciphers are affected, and should no longer be used:
- BF-*
- DES* (including 3DES variants)
- RC2-*
>The following ciphers are *not* affected:
- AES-*
- CAMELLIA-*
- SEED-*
Indeed, AES is today's standard. It's the fastest and more secure cipher available today. [SEED](https://en.wikipedia.org/wiki/SEED) and [Camellia](https://en.wikipedia.org/wiki/Camellia_(cipher)) are not vulnerable to date but are slower than AES and relatively less trusted.
Currently AES is only available in its CBC mode, which is weaker than GCM.
> Of the currently supported ciphers, OpenVPN currently recommends using AES-256-CBC or AES-128-CBC. OpenVPN 2.4 and newer will also support GCM. For 2.4+, we recommend using AES-256-GCM or AES-128-GCM.
To quote the [OpenVPN documentation](https://community.openvpn.net/openvpn/wiki/SWEET32) :
AES-256 is 40% slower than AES-128, and there isn't any real reason to use a 256 bits key over a 128 bits key with AES. (Source : [1](http://security.stackexchange.com/questions/14068/why-most-people-use-256-bit-encryption-instead-of-128-bit),[2](http://security.stackexchange.com/questions/6141/amount-of-simple-operations-that-is-safely-out-of-reach-for-all-humanity/6149#6149)). Moreover, AES-256 is more vulnerable to [Timing attacks](https://en.wikipedia.org/wiki/Timing_attack).
>Of the currently supported ciphers, OpenVPN currently recommends using AES-256-CBC or AES-128-CBC. OpenVPN 2.4 and newer will also support GCM. For 2.4+, we recommend using AES-256-GCM or AES-128-GCM.
AES-GCM is an [AEAD cipher](https://en.wikipedia.org/wiki/Authenticated_encryption) which means it simultaneously provides confidentiality, integrity, and authenticity assurances on the data.
Of course I will update the script to add AES-GCM mode (as well as ECDH and ECDSA) as soon as OpenVPN 2.4 is released.
The script supports the following ciphers:
For now, these cipher are available in the setup :
- `AES-128-GCM`
- `AES-192-GCM`
- `AES-256-GCM`
- `AES-128-CBC`
- `AES-192-CBC`
- `AES-256-CBC`
- AES-128-CBC
- AES-192-CBC
- AES-256-CBC
And defaults to `AES-128-GCM`.
AES-256 is 40% slower than AES-128, and there isn't any real reason to use a 256 bits key over a 128 bits key with AES. (Source : [[1]](http://security.stackexchange.com/questions/14068/why-most-people-use-256-bit-encryption-instead-of-128-bit),[[2]](http://security.stackexchange.com/questions/6141/amount-of-simple-operations-that-is-safely-out-of-reach-for-all-humanity/6149#6149)).
OpenVPN 2.4 added a feature called "NCP": *Negociable Crypto Parameters*. It means you can provide a cipher suite like with HTTPS. It is set to `AES-256-GCM:AES-128-GCM` by default and overrides the `--cipher` parameter when used with an OpenVPN 2.4 client. For the sake of simplicity, the script set both the `--cipher` and `--ncp-cipher` to the cipher chosen above.
Moreover, AES-256 is more vulnerable to [Timing attacks](https://en.wikipedia.org/wiki/Timing_attack).
### Control channel
Thus, the best data channel cipher currently available in OpenVPN is `AES-128-CBC`.
OpenVPN 2.4 will negotiate the best cipher available by default (e.g ECDHE+AES-256-GCM)
### Control channel's cipher
The script proposes the following options, depending on the certificate:
According to the [Hardening](https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher) page of the OpenVPN wiki, TLS 1.2 is not supported by OpenVPN <2.3.3, so it uses a TLS 1.0 cipher by default, which is insecure.
- ECDSA:
- `TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256`
- `TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384`
- RSA:
- `TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256`
- `TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384`
> The following are TLSv1.2 DHE + RSA choices, requiring a compatible peer running at least OpenVPN 2.3.3:
- TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
- TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
- TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
- TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
It defaults to `TLS-ECDHE-*-WITH-AES-128-GCM-SHA256`.
AES GCM is more secure than AES CBC, and AES 128 is secure enough today. I didn't find any security difference between SHA-256 and SHA-384 so we're going to use SHA-256.
### Diffie-Hellman key exchange
Thus, I have chosen `TLS-DHE-RSA-WITH-AES-128-GCM-SHA256` as the control channel cipher.
OpenVPN uses a 2048 bits DH key by default.
### Diffie-Hellman key
OpenVPN 2.4 added support for ECDH keys. Elliptic curve cryptography is faster, lighter and more secure.
OpenVPN uses a 2048 bits DH key [by default](https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/vars.example#L97).
Also, generating a classic DH keys can take a long, looong time. ECDH keys are ephemeral: they are generated on-the-fly.
2048 bits is OK, but both [NSA](https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf) and [ANSSI](https://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf) recommend at least a 3072 bits for a future-proof key. Like RSA, the size of the key will have an impact on speed, I leave the choice to use a 2048, 3072 or 4096 bits key. 4096 bits is what's most used and recommended today, but 3072 bits is still good.
The script provides the following options:
In OpenVPN 2.4, we will be able to use ECDH key. It uses elliptic curves instead of prime numbers' factorization for a reduced key size and calculation time, thus it's faster and more secure.
- ECDH: `secp256r1`/`secp384r1`/`secp521r1` curves
- DH: `2048`/`3072`/`4096` bits keys
### HMAC authentication algorithm
It defaults to `secp256r1`.
To quote the OpenVPN wiki :
### HMAC digest algorithm
>Authenticate packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.
OpenVPN's usage of HMAC is to first encrypt a packet, then HMAC the resulting ciphertext.
From the OpenVPN wiki, about `--auth`:
SHA-1 is not safe anymore, so I use SHA-256 which is safe and widely used.
> Authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.
>
> 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. Note that alg still specifies the digest used for tls-auth.
### TLS-Auth
SHA1 [isn't safe anymore](https://en.wikipedia.org/wiki/SHA-1#Attacks).
>The --tls-auth option uses a static pre-shared key (PSK) that must be generated in advance and shared among all peers. This features adds "extra protection" to the TLS channel by requiring that incoming packets have a valid signature generated using the PSK key. If this key is ever changed, it must be changed on all peers at the same time (there is no support for rollover.)
The script provides the following choices:
>The primary benefit is that an unauthenticated client cannot cause the same CPU/crypto load against a server as the junk traffic can be dropped much sooner. This can aid in mitigating denial-of-service attempts.
- `SHA256`
- `SHA384`
- `SHA512`
>This feature by itself does not improve the TLS auth in any way, although it offers a 2nd line of defense if a future flaw is discovered in a particular TLS cipher-suite or implementation (such as CVE-2014-0160, Heartbleed, where the tls-auth key provided protection against attackers who did not have a copy). However, it offers no protection at all in the event of a complete cryptographic break that can allow decryption of a cipher-suite's traffic.
It defaults to `SHA256`.
[Source](https://openvpn.net/index.php/open-source/documentation/howto.html#security)
### `tls-auth` and `tls-crypt`
TLS-Auth is not enabled by default by OpenVPN, but it is in this script.
From the OpenVPN wiki, about `tls-auth`:
> Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack.
>
> In a nutshell, --tls-auth enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped immediately without response.
About `tls-crypt`:
> Encrypt and authenticate all control channel packets with the key from keyfile. (See --tls-auth for more background.)
>
> Encrypting (and authenticating) control channel packets:
> - provides more privacy by hiding the certificate used for the TLS connection,
> - makes it harder to identify OpenVPN traffic as such,
> - provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy).
So both provide an additional layer of security and mitigate DoS attacks. They aren't used by default by OpenVPN.
`tls-crypt` is an OpenVPN 2.4 feature that provides encryption in addition to authentication (unlike `tls-auth`). It is more privacy-friendly.
The script supports both and uses `tls-crypt` by default.
## Say thanks
@ -255,6 +292,6 @@ You can [say thanks](https://saythanks.io/to/Angristan) if you want!
## Credits & Licence
Thanks to the [contributors](https://github.com/Angristan/OpenVPN-install/graphs/contributors) and of course Nyr's orginal work.
Many thanks to the [contributors](https://github.com/Angristan/OpenVPN-install/graphs/contributors) and Nyr's orginal work.
[MIT Licence](https://raw.githubusercontent.com/Angristan/openvpn-install/master/LICENSE)
This project is under the [MIT Licence](https://raw.githubusercontent.com/Angristan/openvpn-install/master/LICENSE)