how to remove compression from viscosity ?

[nowala]

Hello,

• ubuntu focal fossa
  openvpn 2.6.10
  viscosity 1.11

Since compression is discouraged I wanted to remove it from both my server and client config files.
On the server I've tried :

Code: Select all

comp-lzo no 

and

Code: Select all

#comp-lzo

On Viscosity I've tried ( individually and both at the same time):
in the Options tab : Compression -> off
in the Advanced tab :

Code: Select all

comp-lzo no

and deleting the line

yet I still get this :

Code: Select all

2024-04-08 13:19:12: PUSH: Received control message: 'PUSH_REPLY,ping 10,ping-restart 220,comp-lzo,route-ipv6 *ipv6 addresses of my nextcloud instances* dhcp-option DNS *dns ipv6 address1*,dhcp-option DNS *dns ipv6 address2*,dhcp-option DOMAIN-ROUTE *domain name*,dhcp-option DOMAIN-SEARCH *domain name*,dhcp-option DOMAIN *domain name*,ifconfig-ipv6 *some ipv6 addresss taht I don't know*/80 *ipv6 address in my openvpn.conf on my server*,ifconfig 127.127.127.126 127.127.127.125,peer-id 1,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
2024-04-08 13:19:12: WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2024-04-08 13:19:12: Compression is not allowed since allow-compression is set to 'stub-only'
2024-04-08 13:19:12: OPTIONS ERROR: server pushed compression settings that are not allowed and will result in a non-working connection. See also allow-compression in the manual.
2024-04-08 13:19:12: ERROR: Failed to apply push options
2024-04-08 13:19:12: Failed to open tun/tap interface
2024-04-08 13:19:12: TCP/UDP: Closing socket
2024-04-08 13:19:12: SIGTERM[soft,process-push-msg-failed] received, process exiting
2024-04-08 13:19:12: State changed to Disconnected (Process Terminated)

[James]

Hi nowala,

You should make sure that the "comp-lzo" and "compression" commands are not used anywhere in the server's configuration. The "comp-lzo no" still enables compression framing support: instead make sure the command is removed.

You should also make sure the server isn't pushing any compression related commands using the "push" command. According to the log it is pushing the "comp-lzo" command, so you'll want to make sure the associated push command is also removed from the server's configuration.

You'll also need to restart the OpenVPN server for the changes to take effect. You mention you're using Ubuntu: assuming your setup is fairly standard you can restart the server using the following command:

Code: Select all

sudo systemctl restart openvpn@server

Replace the "server" portion with the name of your OpenVPN configuration file. For example, if it's myserver.conf you would use "sudo systemctl restart openvpn@myserver" instead.

You should also ensure that "comp-lzo" isn't listed as an Advanced Command in Viscosity:
https://www.sparklabs.com/support/kb/ar ... n-commands

Cheers,
James

[nowala]

Hello James !
thank you so much for you reply and I am so sorry for only responding now
Indeed i found that i have 4 places where compression are used:

• The openvpn configuration file (/etc/openvpn/openvpn.conf ):
  Code: Select all

  comp-lzo

  
  I run it as a daemon using
  Code: Select all

  sudo openvpn --config /etc/openvpn/openvpn.conf --daemon openvpn_process

  and get in the terminal
  Code: Select all

  WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.

  the warning disappears of course when i comment "comp-lzo" from the conf file or delete it

• In the user configuration file in /etc/openvpn/Users, I have
  Code: Select all

  push "comp-lzo"

  When I remove it , this warning disappears from the Viscosity log
  Code: Select all

  WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.

  (Kind of relevant in a moment )I am hosting some nextcloud instances on my server to which the routes are specified in the users configuration (/etc/openvpn/Users)

• Viscosity connection options tab (note, i took this image from the sparklabs website, the only options i have activated are
  • Peer certificate
  • Compression: LZO
  • Other : Pull Options
  • Compatibility: Latest
  
  

• And viscosity advanced tab
  • cipher AES-256-GCM
  • mssfix
  • pkcs11-pin-cache 86400
  • resolv-retry infinite
  • tun-ipv6
  • verb 4
  
  i removed comp-lzo no like you said

Noticed behavior:
I can connect to my server and access my nextcloud instances:

• When I remove comp-lzo from all four places,

or

• When I have comp-lzo in the openvpn config file and viscosity Options tab compression field

The user configuration on my server only seems to cause the warning in viscosity log.

Any other combinations results in being able to connect to my server but unable to access my nextcloud instance, which I believe is due to one part sending/expecting compressed data while the other isn’t ?

Since openvpn with comp-lzo shows that warning on the terminal, I guess my server doesn’t compress sent packets but is accepting compressed packets only, if viscosity doesn’t send compressed packets they can connect but my server doesn’t understand the data sent after ?
Please tell me if my guess is correct

i also found on the wiki page of openvpn https://community.openvpn.net/openvpn/wiki/Compression that

only upstream packets are vulnerable to the VORACLE Attack

So since compressed packets from client to server are vulnerable, I think I should go ahead with the first approach, and set the compression option off in viscosity since it's showing in the log

Code: Select all

LZO compression initializing

.
Is this the best approach for security? is there anything else i need to change?
Thank you so much for your time !

[James]

Any other combinations results in being able to connect to my server but unable to access my nextcloud instance, which I believe is due to one part sending/expecting compressed data while the other isn’t ?

Yes, that's correct.

if viscosity doesn’t send compressed packets they can connect but my server doesn’t understand the data sent after ?

Your server is likely configured to expect compressed packets in such an instance (or at least packets with the necessary compression structure around them). OpenVPN can be configured to use what it calls "stub" compression (and modern versions may use it automatically). This basically keeps the compression structure in place, but doesn't actually compress the data (avoiding any security concerns). However, this can make it complicated whether compression is actually active or not.

To make it easier, OpenVPN 2.6 also added an "allow-compression" advanced command you look at using, which can be used to force disable it no matter any other options.
https://www.sparklabs.com/support/kb/ar ... ompression

Cheers,
James

[nowala]

Oh i see thank you !

According to the warning:"Compression for receiving enabled" (i have comp-lzo in my conf file currently), my server is expecting/accepting received packets to be compressed with lzo (*not sure about accepting an lzo compression structure around the files without them actually being compressed ), but it doesn't compress the packets it sends.

no (default) OpenVPN will refuse any compression. If data-channel offloading is enabled, OpenVPN will additionally also refuse compression framing (stub).

I don't have data-channel offloading enabled ( at least not in the conf file),
*-> so I guess my server(Openvpn 2.6) does accept compression framing.

So the best option(for security) is to completely remove compression (comp-lzo) from both the server and viscosity's option tab as well as its support (comp-lzo yes/no) from the Advanced tab ? and use stub or stub-v2 or empty / off instead in my conf file and viscosity.

This might be a stupid question but here goes:

Is there a downside for not compressing files apart from using too much bandwidth? I rather just remove it completely (empty/off) without providing framing ( stub and stub-v2) if there are no "crucial" downsides.

Is Viscosity offering compression options for users who need it for bandwidth usage, like video streaming etc.. because although sending compressed packets is risky, it's not that critical for this use case ? Or am i completely misunderstanding the purpose of that option ?

Thank you for your time

[James]

Removing all compression related options from both ends is the recommended solution.

Compression offers no real performance benefit anymore: in fact in many instances it'll actually slow down performance.

This is because almost all network traffic these days is compressed already: whenever you view a webpage it has usually been gzip compressed by the web server, whenever you download an image it's already using compression as part of the image format, downloaded video is already compressed using the encoding standard, etc. etc. LZO/L4Z can't compress this data any further, and so you just end up wasting packet data (reserved for the compression framing) and CPU time (running compression over already compressed data).

When OpenVPN first introduced compression ~20 years ago, it did offer a benefit: web pages were uncompressed, many images were uncompressed, file sharing protocols like SMB didn't typically have compression, etc., and so compressing the tunnel data did offer a real world performance benefit. However this is rarely the case anymore.

Cheers,
James

[nowala]

Thank you so much James !!!

Have an amazing day !