Does the principle of the CRIME & BEAST attack affect VPNs?

Question

I was recently reading about the attacks on SSL/TLS that CRIME and BEAST were able to exploit by attacking the compression in the secure session. Upon reading this I remembered that OpenVPN has compression as an option in the VPN server configuration. I was wondering if the same sort of attack on TLS could be used against OpenVPN and other VPN connections that use compression.

Answer 1

No. It's not at all applicable.

To be clear, both these attacks involve a malicious attacker creating a vast number of connections through the protocol and examining the ciphertext in order to determine something about the plaintext. The only way this is possible is by having a malicious actor on your computer, in your browser conducting the attack. They did this through java/javascript under the assumption that you could surreptitiously end up running malicious code through visiting a dangerous website, even though your machine isn't otherwise compromised.

The concept doesn't really apply outside the weird world of web browsers. Browsers have the unusual task of running known-malicious code safely in a restricted environment. If you're running malicious code straight on your computer which can connect over your VPN, then you're already owned.

And in VPNs in particular, the session management is different. Whereas with HTTPS it's common to create dozens of connections between a client and server, with a VPN, you create just one encrypted tunnel with a single session through which all your individual network connections will be encrypted.

So no, it's an entirely different world.

Answer 2

BEAST and CRIME might be applicable. It depends on what you do within your VPN.

Both attacks are of the chosen-plaintext type: they work if:

• The attacker can observe the encrypted flow.
• There is a secret data element that is sent within the flow, and the attacker is very interested in it.
• The attacker can also trigger at will the sending of that element, and inject extra data of his own in the immediate vicinity of the secret element.

A scenario where BEAST and CRIME should work is if, with the VPN active, you use your Web browser to:

1. Access a plain-HTTP inner site (located near the VPN exit point) with "Basic Auth" or a cookie, and the attacker is interested in your password or cookie.

2. Also have a look at external Web sites, including one where the attacker can put evil Javascript.

Under these conditions, the concepts of BEAST and CRIME apply. BEAST is hard to pull off, because the attacker must be well synchronized with the outer SSL records, and be able to send arbitrary binary data with bit-to-bit precision; known holes allowing to do that have been fixed in browsers. CRIME is easier. A (minor) complication for the attacker is that OpenVPN maintains a single flow, so the compression "remembers" previous requests; the attacker must inject random junk at regular intervals to fill the compression window and put it back in the conditions where CRIME works well.

Of course, BEAST does not work if you use TLS 1.1 or 1.2; and the TLS implementation used by OpenVPN might include the protection mechanisms for TLS 1.0 (the "1/n-1 split"). If your connections to the inner site are protected with SSL, CRIME will not work either, because then the OpenVPN-level compression will see only encrypted data that it won't be able to compress. A contrario, CRIME should still be workable if the inner SSL uses compression, despite the VPN.

BEAST is blocked if any of the following applies:

• The TLS protocol version is 1.1 or more.
• The symmetric encryption algorithm is not a block cipher in CBC mode.
• The SSL/TLS library systematically applies the 1/n-1 split or a similar variant.

CRIME is blocked if no compression is applied, which encompasses both the secret value that the attacker targets, and the attacker's chosen plaintext.

To sum up, if you use your VPN as a substitute for SSL/TLS when connecting to some services within the local network around the VPN server, then HTTPS attacks like BEAST and CRIME are at least theoretically workable. In fact, BEAST and CRIME consider HTTPS as a dedicated SSL-powered VPN within which plain HTTP is used; if you reproduce the same model with an actual SSL-powered VPN, well, they should still apply. On the other hand, if you use the VPN only for routing (so that your connections seem to exit from the VPN server), and still use normal HTTPS for anything sensitive, then the vagaries of the VPN implementation won't matter for security.

Answer 3

VORACLE, "The attack vector bears similarities to the CRIME and BREACH attacks, which hit especially HTTPS based connections": https://community.openvpn.net/openvpn/wiki/VORACLE

Answer 4

CRIME and BEAST are applicable to browsers because of cross-domain requests. You might browser trustedsite.com in one tab and evilsite.com in another tab. evilsite.com can initiate cross-domain requests to trustedsite.com, and your authentication cookie is attached to those requests. If evilsite.com is also sniffing your encrypted stream, they have a lot to work with here; this is called an "adaptive chosen plaintext attack". Even then, the attacks are complex, and the general issue was known for a long time before a practical attack was developed.

On a VPN you might potentially have untrusted and private data mixing on the same encryption stream. However, it will not mix in a way that is as predictable as a cross-domain request. It seems extremely unlikely that anyone will develop a practical attack for this. However, extremely unlikely is not the same as impossible, so I expect the OpenVPN creators are thinking about workarounds they could include (like stuffing a bit of random data in the stream) - just like browsers have implemented workarounds for BEAST and CRIME.