Random Bits on OpenVPN 2.4

I upgraded syslog-ng to v3.8 on my RT-AC56U recently. Together I also took the chance to migrate Dnsmasq to 2.76 final and OpenVPN server to 2.4. All packages are from Entware-ng. The migration from built-in Asuswrt-Merlin to Entware-ng is straight forward since originally I already set both up in a way independent of any NVRAM and launched from /opt/etc/init.d scripts. Now Samba is the only application on that list which is not yet migrated. My RT-AC56U currently has a solid and non-stop run over five months. Very happy with its extended useful life.

OpenVPN v2.4

Many people consider v2.4 a major upgrade. New features include:

  • IPv6 support outside tunnel
  • floating client IP and port
  • GCM family of data channel ciphers
  • negotiable data channel ciphers (ncp-ciphers)
  • control channel encryption (tls-crypt)
  • LZ4 compression

v2.3 allows IPv6 to go through inside a tunnel. v2.4 additionally allows users to establish an OpenVPN tunnel over IPv6 network. With more ISPs rolling out IPv6 around the world, this support is significant though of little practical value for home users.

Floating client IP and port allows the IP address and/or port of a client to change but the connection remains alive as long as passing authentication check. The IP can change on clients e.g. due to DHCP update and carrier-grade NAT for mobile users. Such functionality is not new. IPsec has similar implemented years before OpenVPN. There is a standard extension known as MOBIKE for IKEv2 IPsec. This feature will benefit road warriors, and other dynamic IP users.

LZ4 compression is considered super fast and faster than its peers. Personally I don't turn on compression. Most traffic today is http/https. I would wager every webserver I visit explicitly or in the background already has deflate/gzip in place. That means most traffic won't be compressible. Both LZO and LZ4 will expand space if the data isn't compressible. For example, LZ4 will expand by up to 0.4%.

Control Channel Encryption

OpenVPN v2.3 had control channel authentication (tls-auth). The manpage describes its use well:

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.  

tls-crypt takes one step further to additionally encrypt the control channel. Hence, OpenVPN traffic is way less obvious to detect by firewall such as the GFW in China. I haven't followed the development of tls-crypt but won't be surprised it's the proper response to the request of XOR scramble patch (and its rejection).


v2.4 adds three new ciphers AES-128-GCM, AES-196-GCM and AES-256-GCM. I'm no crypto expert but want to decide if I should switch to GCM.

Let's begin with AES-128-CBC + 160-bit SHA1 HMAC. AES-128 is the block cipher that takes a 128-bit block of input and chews out 128-bit ciphertext. CBC indicates the operation mode i.e. how a stream of plaintext is turned into ciphertext. As a whole AES-128-CBC is the encryption for privacy. 160-bit SHA1 HMAC is the authentication algorithm which ensures data integrity i.e. payloads have not been altered by a man in the middle. 160-bit SHA1 is the default in OpenVPN if no tls-auth is specified. So yes, that adds 20-byte per packet overhead in OpenVPN (btw it's only a small portion of total overhead). For this reason, I justify myself to personally use 128-bit MD5 HMAC where I save 4 bytes per packet over cellular data. Paranoid people might disagree with me here.

Now look at the similar AES-128-GCM. The block cipher is same. GCM is both an authentication and encryption operation, and replaces CBC and 160-bit SHA1 HMAC in the previous example. GCM simultaneously produce ciphertext and calculates up to 128-bit authentication tag which is good but weaker than many including 160-bit SHA1 HMAC. Moreover, AES-128-CBC can team up with stronger authentication such as SHA256 and SHA384 at the expense of higher computing load and space overhead. GCM doesn't have such flexibility.

Difference in operation mode. Here is a paper with painstaking details that cover many modes in addition to CBC and GCM. In a nutshell, take encrypt as an example. CBC takes previous ciphertext XOR'ed with plaintext (plus necessary padding to fill up block size). Pass the result through the block cipher to get ciphertext. GCM takes an integer known as counter (the C in Galois/Counter Mode). Pass it through the block cipher. The result is XOR'ed with plaintext to get ciphertext. GCM doesn't require padding because zero's is assumed if plaintext isn't block size.

GCM requires less computing than CBC. Its operation can parallelise in hardware and software. OpenVPN isn't multi-threaded so can't benefit from such parallelism but less computation still increases throughput at the same CPU clock. Also GCM requires no padding and uses at most 128-bit authentication. Both features reduce space overhead.

My conclusion...

IPsec is my primary VPN where I use AES-128 + 96-bit SHA1 because my ER-X can accelerate them in hardware but not GCM. OpenVPN is my backup where it runs hardware acceleration not available. I intend switch OpenVPN to use AES-128-GCM together with ncp-ciphers.

Personally I consider tls-crypt, ncp-ciphers and GCM family of ciphers the major incentives to v2.4 upgrade. Unfortunately as of today official OpenVPN clients for both iOS and Android have not moved to v2.4!


Stephen Yip

Something about you know. Come and share.

comments powered by Disqus