4

I'm having a hard time knowing whether the following setup is vulnerable to CRIME/BREACH type attacks (which target HTTPS).

I am running a Wireguard VPN that tunnels VXLAN protocol, using ChachaPoly20 encryption. I would like to add CPU cheap compression (LZ4) on the VXLAN frames (RFC3173 likewise).

Would the fact that I add LZ4 on my VXLAN frames make the encrypted VPN tunnel vulnerable to a potential attacker?

Side question: Since CRIME and BREACH target HTTPS specifically, are there any more generic versions of those attacks?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Orsiris de Jong
  • 143
  • 6
  • 3
    What benefit do you expect from adding compression? 99% of your traffic going through the VPN tunnel will *already* be encrypted (HTTPS), and encrypted data cannot be compressed. –  Apr 20 '21 at 11:25
  • 1
    A lot of traffic will be ldr / raw printing protocol which should be fairly well compressible – Orsiris de Jong Apr 20 '21 at 11:59

2 Answers2

6

To exploit the compression, as in CRIME/BREACH, the attacker must perform a chosen-plaintext attack. In other terms, this means that the attacker must already have an exploit on your computer:

  • Either a RCE, in which case your VPN, encrypted or not, will not help you as you are already pwned;
  • or a CSRF or similar, which is fairly uncommon on classical desktop software.

Avoiding compressing data before encryption is a "defense in depth" protection, in the sense that a prior exploit must be used. Compression exploitation can only be used to improve on an attack, on some very specific scenarios.

Also, as mentioned in this answer by MechMK1, you will most likely not gain much by compressing at the VPN level.

In conclusion, do as you wish, the impact in performance and security will most likely be minimal either way. If, however in your particular situation you know that you will gain a lot by adding compression, or that a CSRF is likely and unavoidable, then you now know what to choose between compression and security.

A. Hersean
  • 10,046
  • 3
  • 28
  • 42
5

It likely won't make a difference.

The reason being is that the vast majority of traffic going through your VPN tunnel will already be encrypted at a different OSI layer. So the traffic that you see in your VPN tunnel will have very high entropy, and high entropy cannot be compressed.

As a result, enabling compression will likely not change anything at all, unless you expect a significant portion of your VPN traffic to be unencrypted.

  • Adding to this, *much* of the compressible data will already be compressed at the application layer (in particular, HTTP(S) likes to use gzip for HTML and other text-based formats, and most binary formats are inherently compressed anyway). With a highly specialized re-compressing system you *might* be able to make small gains in efficiency, but it probably isn't worth it. – Kevin Apr 21 '21 at 06:08