* https://ostif.org/?p=870&preview=true

* http://www.prweb.com/releases/2017/05/prweb14326488.htm

This issue have been assigned CVE-2017-7478.

An authenticated client can do the 'three way handshake' (P_HARD_RESET, P_HARD_RESET, P_CONTROL), where the P_CONTROL packet is the first that is allowed to carry payload. If that payload is too big, the OpenVPN server process will stop running due to an ASSERT() exception. That is also the reason why servers using tls-auth/tls-crypt are protected against this attack - the P_CONTROL packet is only accepted if it contains the session ID we specified, with a valid HMAC (challenge-response).

This affects OpenVPN 2.3.12 and newer. The problem has been fixed by commit "Don't assert out on receiving too-large control packets":

* release/2.3: feb35ee5ca

OpenVPN versions 2.3.15, 2.4.2 and later include these fixes.

This issue have been assigned CVE-2017-7479.

An authenticated client can cause the server's the packet-id counter to roll over, which would lead the server process to hit an ASSERT() and stop running. To make the server hit the ASSERT(), the client must first cause the server to send it 2^32 packets (at least 196GB).

* release/2.3: b727643cdf

OpenVPN versions 2.4.2 and 2.3.15 (and later) include these fixes. The "release/2.2" branch in Git has also been patched, primarily for the benefit of external package maintainers. We do not, however, intend to make a 2.2-release, not even in source-only format.

* release/2.4: 1ebd3ade

* release/2.4: 47d80b95

While this is low security issue, we will look into fixing this in a future release, as the fix is trivial.

The report states that this is of "informational" severity as it can't be exploited. Regardless we will fix this in a future release.

* release/2.4: a52fd9575e

The wording "would result in a complete loss of privacy" in the report is cryptographic jargon that might mislead non-cryptographers reading the report to conclude that his/her traffic is no longer protected at all if such an IV collision occurs. That is of course not the case; tls-crypt is an additional layer of protection, and even if IVs collide, one of the packets is with high probability an (unpredictable) encrypted TLS record. Colliding IVs would of course result in *some* loss of privacy, but are unlikely to lead to a *complete* loss of privacy. As such, we believe "would result in a loss of privacy" is more appropriate.

We want to emphasize that `--tls-crypt` is protecting the OpenVPN control channel. The control channel is used to establish the TLS connection between server and client, where certificate information is used. The TLS protocol is designed so that the certificate information (which in essence is a public key, with some signed meta data such as Common Name, etc) is passed over connection in clear-text. This is not unique for OpenVPN, even HTTPS does it like this. So when enabling `--tls-crypt`, OpenVPN adds another layer of encryption only on this control channel. All the tunnelled network traffic which is encrypted between the OpenVPN instances does not depend on --tls-crypt itself; thus the tunnelled network traffic is not directly affected by this issue.

* release/2.4: 9444506e

We believe that replacing authentication (`--tls-auth`) with authenticated encryption (`--tls-crypt`) does not introduce risks. At the exact place where `--tls-auth` authenticates the plaintext and checks for replays of control channel packets, `--tls-crypt` performs decryption, authenticates the plaintext and checks for replays. Our analysis is that `--tls-crypt` provides the same DoS protection as `--tls-auth` does, with the sole exception that `--tls-crypt` requires slightly more work to authenticate a packet (specifically, one AES-CTR operation).

[0] Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap

The current prng is non-standard, but seems to rely solely on the preimage-resistance of hash functions, which makes SHA1 (still) a sane default. This custom prng is mostly in place as a performant alternative for CBC IVs. *It is not used to produce keys.*

2. Rip out the OpenVPN prng implementation and rather use the crypto libraries' implementation directly. This has the side-effect of reduced performance in CBC-mode.

In regard to NIST compliance, OpenVPN users with such demands will need configure and use OpenVPN in a compliant way (e.g. --prng SHA256).

The --no-iv option is an advanced feature that reduces security for a slight improve in performance. This option has been deprecated in the release/2.4 branch (commit 4969f0d6bb) and removed in the master branch (commit ef910e3e3a). _It will not be present in OpenVPN 2.5._

The --no-replay is an advanced feature that allows disabling OpenVPN's replay attack protection. This option can only be used without reducing security if OpenVPN was already used in an insecure mode that disables authentication. We are considering to deprecate this feature.

The --reneg-bytes option can be used to disable SWEET32 mitigation in OpenVPN. The report suggests ignoring --reneg-bytes when 64-bit block ciphers such as Blowfish are used. In practice doing what the report suggests would break configurations that use OTP but cannot make use of --auth-gen-token. We believe that the current approach, where we use sane but overrideable defaults and log warnings if small block ciphers are used, suffices.

We will review the warning messages and possibly make them more scary in v2.5. If people are still using weak ciphers in the 2.6 release cycle we will consider doing what the report suggests.

Cipher negotiation (NCP) in OpenVPN 2.4 defaults to AES-256-GCM and allows negotiating stronger ciphers when clients support it. Using NCP is a more user-friendly way to migrating away from unoptimal defaults like BF-CBS and SHA-1.

We will continue to looking into gradually upgrade the connection's crypto parameters without breaking existing configurations. Once that has been deployed and widely used for a longer time we can truly consider changing the default values, or deprecate the old way of setting ciphers.

* release/2.4: 1935729fe6

We have initiated a discussion in the community about getting this code fixed. In addition we are discussing with the Tunnelblick maintainer if it would be more appropriate to transfer this code to the Tunnelblick project directly; the keychain-mcd contrib code is only targetting macOS.

A complete rewrite of the sample-plugins/defer/simple.c example plug-in has been sent for review. This will replace simple.c completely and resolves both this issue and OVPN-07.

The issue itself is very minor and very unlikely to cause problems. This piece of code can however definitely use some improving - which we'll tackle later.

This has been fixed commit "Require minimum OpenSSL 1.0.1" (039a89c331) in Git master branch.

A pending patch, "plugins: Replace defer/simple with an improved replacement", refactors the sample plugin code and gets rid of the code patch described in there report. This patch also covers OVPN-04-2.

We are not fully convinced there are any viable attack vectors on how this is used in OpenVPN. We acknowledge that environment variables of a process can be accessed with 'ps' or procfs (/proc/$PID/environ) on Linux. FreeBSD has this information only available via `ps`. However, based on our testing on Linux, FreeBSD and Windows the environment variables of a process (e.g. a script hook) launched by OpenVPN are only available to other processes that run with the same UID/GID as the OpenVPN process itself.

The `--tls-verify` option allows running a command to verify the X509 name of a pending TLS connection that has otherwise passed all other tests of certification, except the revocation test via --crl-verify, which occurs after `--tls-verify`. The `--tls-verify` option can be used to provide fine grained access control on the server side in ways where the alternative, `--verify-x509-name`, will not suffice.

We see `--tls-verify` as primarily server-side option. It could probably be removed from the client-side without any effect to our users. However, it is not altogether clear what the attack vector would be, so we currently don't have any plans on removing it.

We agree that we should warn users about the risks of using compression on encrypted protocols such as OpenVPN. In OpenVPN 2.4.3 we will warn users about this. In addition to --comp-lzo we will also warn about --compress.