Is this enough security?

Patanata

Hey Community!

I have successfully setup a bridged VPN server with OpenVPN.

Here is my server.conf

script-security 2

mode server
tls-server

local 10.0.0.2  #ip/hostname of server
port 1194         #default open port
proto udp

#bridging directive
dev tap0          #If you need multiple tap devices, add them here
up "/etc/openvpn/up.sh br0 tap0 1500"
down "/etc/openvpn/down.sh br0 tap0"

persist-key
persist-tun

#certificates and encryption
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key   #this file is secret
dh /etc/openvpn/keys/dh1024.pem
#tls-auth /etc/openvpn/ta.key       #this file is secret

cipher BF-CBC                      #Blowfish (default)
comp-lzo

#DHCP information
ifconfig-pool-persist /etc/openvpn/ipp.txt
server-bridge 10.0.0.2 255.255.255.0 10.0.0.100 10.0.0.110
push "dhcp-option DNS 10.0.0.1"
#push "dhcp-option DOMAIN yourdomain.com"
max-clients 10                     #set this to the max number of clients to be connected at a time

#log and security
user nobody
group nogroup
keepalive 10 120
status /etc/openvpn/openvpn-status.log
verb 3

Do I have the maximum security?

Can I increase the secrity level to an even higher one?

Cheers

maikcat

you can always:

use AES-256-CBC instead of blowfish
use SHA512 (auth directive)
use larger keys (2048bit)
use tls-auth directive

Michael.

[deleted]

Hi and thanks for the reply!

Is AES-256-CBC more secure than BF-CBC? Or is it just another way of encryption?

Larger keys, yep, seems senseful. 🙂 Will it slow down the connection?

I tried myself on the tls-auth directive, though was not successfull. What I did, was copying the key to both sides client and server and then setting the directive on it, but the connection would not be estabilished. I did not quite understand why. How do I setup the tls-auth?

Cheers

maikcat

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

[deleted]

Ok, thanks for your reply and for all these advices.
I tried to change BF-CBC to AES-256-CBC by replacing the new keyword on the client side (client.conf) and the server side (server.conf).
After reboot of both machines the connection couldn't be estabilished anymore.

I believe further steps are necessary.

What do I have to do to change the encryption from BF-CBC to AES-256-CBC?

mwandelaar

you can view the available ciphers with

openvpn --show-ciphers

if you directly want to change the tls-ciphers you can check the availability with

openvpn --show-tls

when you picked your choice you have to modify both the server and client-configs with a line like:

cipher AES-256-CFB

tls-cipher AES256-SHA

as both of these directives have a fixed keysize, you do not need to put something like

keysize 256

in your config. Maybe you want to increase the HMAC for the authentication too. This can be viewed with

openvpn --show-digests

and pick your choice with, for example

auth SHA256

But remember to tell both server and client about these directives. My configs (usually) end with

cipher AES-256-CBC
keysize 256
auth SHA256

IncreasedSecurity

On older versions (2.2.x), I typically used 4096 bit RSA certificates/keys for authentication (with passphrases on the cert) for both client and server, and

cipher AES-256-CBC
auth SHA512
tls-cipher DHE-RSA-AES256-SHA

The CAMELLIA-xxx-CBC (European and Japanese standard) cipher would be roughly equivalent to the AES-xxx-CBC (United States standard) cipher. Both of these are currently secure at all three key sizes, and are slightly to massively better than any of the alternatives even in OpenVPN 2.3.0.

For authentication, SHA512, the largest SHA2 digest, is definitely the most secure choice. The U.S. NIST has recently chosen Keccak as SHA3, also available in 256, 384, and 512 bit versions, but has announced that SHA2 is still deemed secure - they will both be in use for the forseeable future, side by side. I am not aware of EU or Japanese hash standards, regrettably.

For tls-cipher, 2.2.x doesn't have any of the really modern ciphers (note that it's SHA1, not SHA256, SHA384, or SHA512), but DHE-RSA-AES256-SHA seems to be the best choice based on OpenVPN/OpenSSL recommendation.

With 2.3.0, I'm trying to figure out precisely what RSA-SHA512 does as a digest vs. plain SHA512 (and what the RSA parameters are), and I'd really like to get the TLS cipher suite ECDHE-RSA-AES256-GCM-SHA384 working, as Galois Counter Mode, a SHA2 hash, and elliptical curve cryptography are all significant improvements.

Regrettably, with the Windows 2.3.0 I004 binary install, the elliptical curve modes appear to simply error out when I try them as drop-in replacements.

At this time, I do not know how to have OpenVPN require multiple modes of authentication at once, i.e. require a certificate, and one or more a TOTP tokens, perhaps even and a username/password. Username/password by itself is an incredibly poor choice; TOTP token plus something else is going to be better than that something else by itself.

IncreasedSecurity

Note that one other thing you can do is increase the size of the dh parameters. I believe the syntax to create them is:

openssl dhparam -out dh2048.pem 2048

openssl dhparam -out dh3072.pem 3072

And then you'd just replace the dh1024.pem you already have in your config file. I'm unsure as to how much this will slow down key regeneration and what else that could lead to, however.

m4f1050

Hi, my dd-wrt has openvpn server, I have the option of doing AES-512-CBC cipher but OpenVPN client does not recognize it. Are there any future plans of updating this? Or is this something I missed and need to update my client?

Thanks!

Traffic

@ m4f1050

As a cipher option, OpenVPN does not support AES-512-CBC.

OpenVPN version 2.3.4 wrote

[root@arch-dik-live /etc/openvpn]
19:58:10 $ openvpn --version
OpenVPN 2.3.4 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on May  3 2014
library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no
[root@arch-dik-live /etc/openvpn]
19:59:09 $ openvpn --show-ciphers
The following ciphers and cipher modes are available
for use with OpenVPN.  Each cipher shown below may be
used as a parameter to the --cipher option.  The default
key size is shown as well as whether or not it can be
changed with the --keysize directive.  Using a CBC mode
is recommended.

DES-CBC 64 bit default key (fixed)
IDEA-CBC 128 bit default key (fixed)
RC2-CBC 128 bit default key (variable)
DES-EDE-CBC 128 bit default key (fixed)
DES-EDE3-CBC 192 bit default key (fixed)
DESX-CBC 192 bit default key (fixed)
BF-CBC 128 bit default key (variable)
RC2-40-CBC 40 bit default key (variable)
CAST5-CBC 128 bit default key (variable)
RC2-64-CBC 64 bit default key (variable)
AES-128-CBC 128 bit default key (fixed)
AES-192-CBC 192 bit default key (fixed)
AES-256-CBC 256 bit default key (fixed)
CAMELLIA-128-CBC 128 bit default key (fixed)
CAMELLIA-192-CBC 192 bit default key (fixed)
CAMELLIA-256-CBC 256 bit default key (fixed)
SEED-CBC 128 bit default key (fixed)

[root@arch-dik-live /etc/openvpn]
19:59:12 $

It is possible that the implementation of OpenVPN on your router offers --cipher AES-512-CBC as an extra option but you will need a router with support for AES-512-CBC as a client .. not true OpenVPN.

*Note* As of the date of this post.

maikcat

The Rijdael cipher comes in 128, 160, 192, 224, and 256-bit variants,
officially there is not 512bit variant by its original authors...

one of the 512bit variants is Moh'd, A., Jararweh, Y., & Tawalbeh, L. (2011) AES-512: 512-bit Advanced Encryption Standard algorithm design and evaluation. Information Assurance and Security (IAS),
2011 7th International Conference on. pp. 292 - 297. DOI 10.1109/ISIAS.2011.6122835

keep in mind though that these 512bit variants have not under gone the same deep analysis as the derivative of Rijndael that became AES.

my personal opinion is that for now AES-256 is enough....

Michael.

m4f1050

Awesome, thanks, it's what I switched to. AES-256-CBC.

I am now upgrading to DH2048

What I am having issues is with SHA512, I can't switch to SHA512 or my client won't connect to my server, do I need to create new certificates using SHA512 or something? My sec knowledge is limited.

Thanks!

m4f1050

m4f1050 wroteAwesome, thanks, it's what I switched to. AES-256-CBC.

I am now upgrading to DH2048

What I am having issues is with SHA512, I can't switch to SHA512 or my client won't connect to my server, do I need to create new certificates using SHA512 or something? My sec knowledge is limited.

Thanks!

Ok, I'm setup with AES-256-CBC and with a DH 2048, how do I switch to SHA512 (well, even SHA2, I don't want SHA1, it's "broken"...)

maikcat

what openvpn version is your client?

Michael.

mwandelaar

This is a long running topic with lot's of usefull information. And since the release of 2.4.0 we had some awesome new features.
As i'm constantly trying to improve security in my vpn-configs, i'm trying to wrap-up my ideas over here. Any comment would be very helpfull!

As thoroughly explained in the security-overview, we need to take care of 2 different security-issues:

The control-channel
The data-channel

The first is handled with a TLS-handshake, takes care of the authentication of both client and server and the exchange of keys for the data-channel. So it's very important to have a reliable crypto-channel here with Perfect Forward Secrecy , meaning an adversary cannot retreive keys over lang time (i do have tunnels running for years allready).
Luckily for us, this is all solved in current TLS versions, thus choosing a good TLS-ciphersuite does help us.
As this is pretty difficult to choose for a non-crypto-specialist (openvpn --show-tls gives lots of options) you can let OpenVPN choose for you, but enforcing a high-level of crypto by using:

tls-version-min 1.2

In both client and server config.
One of the great new features of 2.4 is the option tls-crypt , which crypts packets and lots of awesome things (see manpage and this topic )
Generate the tls-crypt key using:

openvpn --genkey --secret tc.key

And include in your client and server config, either inline using

<tls-crypt> and </tls-crypt>

tls-crypt /path/to/tc.key

Now we have a state-of-the-art control-channel which we use to setup our data-channel. As the data-channel has symmetric encryption, we need to use another set of crypto (openvpn --show-ciphers shows you the options) and hashing algoritm (HMAC).
As this another part of black magic for the most of us, i did some research(1) research(2) research(3) on some sources, including the openvpn documentation and for now it's advised to use AES-256-GCM and SHA256 (Eventually AES-256-CBC when GCM is not available)
Remark: I haven't played with the NCP-cipher options yet. More to follow

Now we need to use a good HMAC (Message Authentication using a hash-algoritm) protocol. SHA256 will do for this, as it it's recommended:

auth SHA256

Every now and then we need to renegotiate the key, used for crypto of the data-channel. The default value is 3600 seconds, which would be a secure enough option. If you are really paranoia you could lower this value to, i.e., 10 minutes by adding

reneg-sec 360

to both client and server.

Wrapping everything up to a server and client-config, i end up with a snippets like this:
tls-version-min 1.2
cipher AES-256-GCM
auth SHA256
dh /path/to/dh.param
tls-crypt /path-to/tc.key
# reneg sec 360 tls-version-min 1.2
cipher AES-256-GCM
auth SHA256
tls-crypt /path-to/tc.key
# reneg-sec 360 As said before, i haven't played with the ncp-ciphers options. And as GCM-mode allready includes HMAC-functions, what's the additional SHA256 adding for security? Still some questions left.

Please, any comments on this?