OpenVPN and SWEET32

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 demonstrate how cross-site scripting vulnerabilities can be exploited to send data of interest frequently enough. This vulnerability affects HTTPS as well as HTTP-over-OpenVPN. For a more detailed explanation, visit sweet32.info ¹.

Am I affected?

This depends on the cipher you've chosen (OpenVPN's --cipher option). OpenVPN's default cipher, BF-CBC, is affected by this attack.

You can check if you're affected by installing OpenVPN 2.3.12 ² or newer, and running openvpn --show-ciphers. This will list which ciphers should no longer be used. For convenience, we provide a summary of commonly used ciphers here:

Affected ciphers that should no longer be used:

BF-*
DES* (including 3DES variants)
RC2-*

Ciphers that are not affected:

AES-*
CAMELLIA-*
SEED-*

Mitigation

1. Change to a larger block cipher

The best mitigation is to transition away from small-block ciphers. This requires editing the cipher setting in all server and client configs (or upgrading to our experimental branch, see below).

For currently supported ciphers, OpenVPN 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.

2. Renegotiate more often

If changing the cipher is not possible, for example, because you do not control the server or cannot update all client configs quickly, you can renegotiate new keys more frequently. For instance, add --reneg-bytes 64000000 to your config to renegotiate after every 64 megabytes.

If you're using two-factor authentication or username-password authentication, this might require users to re-enter their 2FA token or username and password. To avoid this, do not use --auth-nocache, and use the auth-token option (see below) in the client-connect and auth-user-pass-verify scripts on the server side to request 2FA only once per session.

The (undocumented) auth-token option can be pushed by a client-connect script (running on the server) to instruct the connecting client to return this token as the password during the next authentication. The auth-user-pass-verify script (running on the server) should accept this token during subsequent authentication sessions until the token expires.

The following client-connect and auth-user-pass-verify scripts illustrate how these options can be used. These scripts should not be used as-is! They are examples only and should be adapted to your specific needs.

#!/usr/bin/env python
# client-connect script
import base64
import hmac
import os
import sys
import time

username = os.environ['username']

ts = time.time()
to_auth = str(ts) + ":" + username

h = hmac.new('mysecret')
h.update(to_auth)
digest = base64.b64encode(h.digest())

auth_token = "push \"auth-token " + str(ts) + ":" + digest + "\""

print("Sending auth-token:", auth_token)

open(sys.argv[1], 'w').write(auth_token)

#!/usr/bin/env python
# auth-user-pass-verify script
import base64
import hmac
import os
import time

username = os.environ['username']
password = os.environ['password']

if (password == "mysecretpassword"):
    print("password OK")
    exit(0)

token = password.split(":")

to_auth = token[0] + ":" + os.environ['username']

h = hmac.new('mysecret')
h.update(to_auth)
digest = h.digest()

if digest != base64.b64decode(token[1]):
    print("Auth-token incorrect")
    exit(1)

if time.time() - float(token[0]) > 60:
    print("Auth-token expired")
    exit(1)

exit(0)

3. Cipher negotiation (OpenVPN 2.4 and newer)

OpenVPN 2.4 and newer support cipher negotiation. If both peers (client and server) support cipher negotiation, OpenVPN will default to using AES-GCM.

For more details, see the OpenVPN 2.4 man page on ncp-ciphers.