Post
by openvpn_inc » Wed Nov 01, 2023 4:27 pm
Hello,
I just want to provide a bit of background on this. In the past compression was an option that could be enabled, with the idea that easily-compressable data could be minimized and thus take less time to transfer. But the Voracle vulnerability that was discovered when compression and encryption are combined proved that there is no sensible way to have compression and be absolutely sure that no data could be gleaned from the compressed and encrypted data. The trick is in the length of compressed and encrypted data that can give a clue about what's in the original data. If you're interested to learn more, read up on Voracle vulnerability.
In short though, this meant OpenVPN had to phase out compression.
Modern clients are capable of using DCO. DCO, or Data Channel Offload, is a new addition to OpenVPN where transportation of data can be handled in the kernel, which is faster. Obviously it makes no sense to implement a feature like compression in DCO when it is known to be flawed. So DCO does not have compression support and will not get it either (because that would be insecure and silly to do).
The situation described in the original post by Markco is the case where the client side wants to use DCO. And the server side is telling the client to do compression. In such a case, the client side will abort, because that's not possible, because the client side uses DCO and it does not know how to do compression and never will.
The suggestion that Fadim provided was to use the mentioned allow-compression option to turn compression on, on the client side. Doing so forces DCO off, because DCO cannot do compression. So the client has now become a little 'dumber' and falls back to non-DCO behavior. So it doesn't use the kernel module to speed up data transfer, but it just goes back to using good old OpenVPN data transfer without that new stuff. And that still does support compression, even though it is not encouraged for security reasons of course.
However the suggestion specifically enables compression in both directions. It may be wiser instead to do allow-compression asym which lets the client receive compressed data from the server (since it has no control over what the server sends anyway), but at least it doesn't SEND compressed data by itself. So at least the client side is being 'safe'.
The better solution would be to have the server side reconfigured to adjust compression options, so it doesn't use compression and doesn't tell clients to use compression either. This addresses the Voracle vulnerability issue when compression is enabled, which is good for security. And it allows DCO to be used, which is good for performance.
Hopefully this information will be useful to someone in the future.
Kind regards,
Johan
OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support