5

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?

Improve this question
2
  • 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.
    – user163495
    Commented Apr 20, 2021 at 11:25
  • 1
    A lot of traffic will be ldr / raw printing protocol which should be fairly well compressible
    – Orsiris de Jong
    Commented Apr 20, 2021 at 11:59

2 Answers 2

Reset to default
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.

Improve this answer
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.

Improve this answer
1
  • 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
    Commented Apr 21, 2021 at 6:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .