Docker-openvpn: Address SWEET32 cipher vulnerability

[kylemanna]

OpenVPN and SWEET32

Security researchers at INRIA published an attack on 64-bit block ciphers, such as 3DES and Blowfish [0]. 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.

https://community.openvpn.net/openvpn/wiki/SWEET32

[kylemanna]

Best path forward is to move to new ciphers:

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.

GCM is probably out as the default because of the need to maintain compatibility with a bunch of old clients.

[kylemanna]

It appears that OpenVPN automatically neogitates intelligent ciphers based on availability. My systems seems to negotiate:

Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

EDIT: This is the control channel, not the data channel it seems.

WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

I assume that disabling the ciphers that have warnings will cause breakage with the clients negotiating the older weaker ciphers which seems worse then having to renegotiate more often.

Anyone know for certain?

[travisolbrich]

I just upgraded to OpenVPN 2.4.0 x86_64-w64-mingw32 and I'm still seeing the warnings.

[DittmarSteiner]

I am running the client through Docker and also see the warning:

docker run --rm --net=host --cap-add=NET_ADMIN --device /dev/net/tun -itv `pwd`/my.ovpn:/config.ovpn kylemanna/openvpn openvpn --config /config.ovpn

I’d like to recreate all client certificates.
Is there a way to pass the --cipher option here?

docker run -v $OVPN_DATA:/etc/openvpn --rm -it kylemanna/openvpn easyrsa build-client-full CLIENTNAME nopass

[nrbrt]

This warning also shows on the server with the latest IOS openvpn client.

WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

it also logs this:
Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

[kylemanna]

The easiest way to fix this until OpenVPN 2.4 is released is to specify --cipher AES-128-CBC i.e.:

docker run ... -p ... kylemanna/openvpn ovpn_run --cipher AES-128-CBC

And update all your clients to follow the updated cipher or they will fail to connect.

OpenVPN 2.4 is still in the edge testing branch of Alpine Linux. When it's released it will fix this problem with new clients that support cipher negotiation.

Alternatively, we can pull the OpenVPN 2.4 release into the dev branch if enough people want to help test it ahead of time.

[nrbrt]

I used --cipher AES-256-CBC and that did the trick. No warnings, Thanks!

[phlegx]

@kylemanna Thanks for the explanation! I was wondering if it is also possible to pass the cipher via docker-compose somehow?

Here I don't see such an option actually: https://github.com/kylemanna/docker-openvpn/blob/master/docs/docker-compose.md

[jhazelwo]

For those interested, the way to have your client connect with the larger block size is to edit your connection.ovpn file and add "cipher AES-128-CBC" to an empty line at the top of the file, save, then import the file to the OpenVPN client.

@phlegx if I remember correctly add something like cmd: ovpn_run --cipher AES-128-CBC to the compose.yml file.

[warp-x]

@jhazelwo I tried and found it's command: instead of cmd: in the Compose file reference for version 2.

[LM1LC3N7]

For those interested, the way to have your client connect with the larger block size is to edit your connection.ovpn file and add "cipher AES-128-CBC" to an empty line at the top of the file, save, then import the file to the OpenVPN client.

This absolutely solve my problem! Thank you @jhazelwo

[kylemanna]

Anyone wanting 2.4 support, please provide comments on issue #267

[kylemanna]

This is now resolved with OpenVPN 2.4.x support.

[KurtStam]

So I'm running on the latest docker image with OpenVPN 2.4.2 x86_64-alpine-linux-musl and I'm seeing the SWEET32 warning. It'd be great if someone can summarize the steps to take to fix this.

[kylemanna]

It'd be great if someone can summarize the steps to take to fix this.

Sounds like your client is falling back to the old settings. Can you check your client version and update it if necessary?

[KurtStam]

@kylemanna, that was it. The setting in my Tunnelblick is 2.3 by default. I had to switch it to 2.4.2 (latest)! Thx and great project btw.

[tinnedpeaches]

I assume you changed OpenVPN in Tunnelblick by changing the 'OpenVPN version' in the settings? I've tried every version from 2.3.17 to 2.4.3. They all come back with the same 64bit error.

Here are the lines before:
Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

and after:
WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks

OS 10.10.5, MBP 3.1

Pls help.

[kopax]

Does anybody know how to remove these warning using a marathon deployment file ?
https://mesosphere.github.io/marathon/docs/deployments.html