Bug 11819

Hi Michael,
am currently implementing the LZ4 compression for RWs and N2N where i can go also for a warning message with appropriate hints (if in usage to only use HTTPS sides, usage of Chrome browser, etc.) via the upcoming patch https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=400c8afd9841bed350c192099a34bc84f3a04535 . 

Another possible important point is, i have tested old Roadwarrior connections with "--comp-lzo" entries in client.ovpn but the compression algorithms can also be pushed via CCD by the server and can be configured also after the client.ovpn has been distributed whereby algorithm parameter can be "lzo", "lz4", "lz4-v2", or empty (to disable the compression) and the pushed directive will always be precedented to the written ones in the config files. So if "--comp-lzo" is written to client.ovpn but the server pushes "--compress" only (empty to deactivate the compression) it should be possible to deactivate the compression even it is present in the client.ovpn (no further changes are needed then).

As far as i can see it, Voracle works only in server/client environment so N2N should be save in the manner cause it´s a p2p environment ?

Another point is the compression are deactivated per default on IPFire but the comp-lzo is available at the first glance on the global section. It might be also a possibility to 1) bing it to the advanced section or to 2) make it only available via CCD ?

Some thoughts from here even with no tests at the moment causing this topic cause i am currently on the road again.

Best,

Erik

(In reply to Erik Kapfer from comment #1)
> Hi Michael,
> am currently implementing the LZ4 compression for RWs and N2N where i can go
> also for a warning message with appropriate hints (if in usage to only use
> HTTPS sides, usage of Chrome browser, etc.) via the upcoming patch
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;
> h=400c8afd9841bed350c192099a34bc84f3a04535 .

Yes, this vulnerability is not because of a weakness in LZO. It is basically a problem in the concept of "compress+encrypt".

You can go ahead with implementing LZ4, but I suppose it will have the same weakness.

> Another possible important point is, i have tested old Roadwarrior
> connections with "--comp-lzo" entries in client.ovpn but the compression
> algorithms can also be pushed via CCD by the server and can be configured
> also after the client.ovpn has been distributed whereby algorithm parameter
> can be "lzo", "lz4", "lz4-v2", or empty (to disable the compression) and the
> pushed directive will always be precedented to the written ones in the
> config files. So if "--comp-lzo" is written to client.ovpn but the server
> pushes "--compress" only (empty to deactivate the compression) it should be
> possible to deactivate the compression even it is present in the client.ovpn
> (no further changes are needed then).

That's great. Let's implement this so the admin can later change this.

> As far as i can see it, Voracle works only in server/client environment so
> N2N should be save in the manner cause it´s a p2p environment ?

I guess this is for all connections.

> Another point is the compression are deactivated per default on IPFire but
> the comp-lzo is available at the first glance on the global section. It
> might be also a possibility to 1) bing it to the advanced section or to 2)
> make it only available via CCD ?

CCD doesn't make much sense because you want compression on for everyone or no one instead of on an individual basis. I would be fine with moving it to the advanced section.

(In reply to Michael Tremer from comment #2)
> (In reply to Erik Kapfer from comment #1)
> > Hi Michael,
> > am currently implementing the LZ4 compression for RWs and N2N where i can go
> > also for a warning message with appropriate hints (if in usage to only use
> > HTTPS sides, usage of Chrome browser, etc.) via the upcoming patch
> > https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;
> > h=400c8afd9841bed350c192099a34bc84f3a04535 .
> 
> Yes, this vulnerability is not because of a weakness in LZO. It is basically
> a problem in the concept of "compress+encrypt".
> 
> You can go ahead with implementing LZ4, but I suppose it will have the same
> weakness.
Yes i think also that it makes no difference which compression algorithm is in usage.
The selection menu is now ready:
- Have moved now the compression option from the "Globale" to "Advanced settings".
- Have integrated it also into the CCD section so it should be possible to deactivate the compression on the fly for already configured clients with enabled compression <-- in there i did some tests whereby the connection comes up even if the server.conf do uses any kind of compression, the client do uses also the old compression directive ('comp-lzo') but the CCD is configured with compression 'off' which means the following entry

#Compression has been deactivated for this client
compress
push "compress"

in that case, the connection start looks like this:

Aug 18 12:32:43 ipfire-prime openvpnserver[28286]: 192.168.10.2:51896 LZO compression initializing

but with the CCD options import:

Aug 18 12:36:50 ipfire-prime openvpnserver[30518]: testrwcomp/192.168.10.2:41796 OPTIONS IMPORT: reading client specific options from: /var/ipfire/ovpn/ccd/testrwcomp
Aug 18 12:36:50 ipfire-prime openvpnserver[30518]: testrwcomp/192.168.10.2:41796 MULTI_sva: pool returned IPv4=10.25.178.14, IPv6=(Not enabled)
Aug 18 12:36:50 ipfire-prime openvpnserver[30518]: testrwcomp/192.168.10.2:41796 OPTIONS IMPORT: compression parms modified
Aug 18 12:36:50 ipfire-prime openvpnserver[30518]: testrwcomp/192.168.10.2:41796 MULTI: Learn: 10.25.178.14 -> testrwcomp/192.168.10.2:41796
Aug 18 12:36:50 ipfire-prime openvpnserver[30518]: testrwcomp/192.168.10.2:41796 MULTI: primary virtual IP for testrwcomp/192.168.10.2:41796: 10.25.178.14
Aug 18 12:36:51 ipfire-prime openvpnserver[30518]: testrwcomp/192.168.10.2:41796 PUSH: Received control message: 'PUSH_REQUEST'
Aug 18 12:36:51 ipfire-prime openvpnserver[30518]: testrwcomp/192.168.10.2:41796 SENT CONTROL [testrwcomp]: 'PUSH_REPLY,route 10.25.178.1,topology net30,ping 10,ping-restart 120,redirect-gateway,compress,route 192.168.7.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,ifconfig 10.25.178.14 10.25.178.13,peer-id 0,cipher AES-256-GCM' (status=1)

'compress' only are used. The connections are stable after 30 Minutes.


> 
> > Another possible important point is, i have tested old Roadwarrior
> > connections with "--comp-lzo" entries in client.ovpn but the compression
> > algorithms can also be pushed via CCD by the server and can be configured
> > also after the client.ovpn has been distributed whereby algorithm parameter
> > can be "lzo", "lz4", "lz4-v2", or empty (to disable the compression) and the
> > pushed directive will always be precedented to the written ones in the
> > config files. So if "--comp-lzo" is written to client.ovpn but the server
> > pushes "--compress" only (empty to deactivate the compression) it should be
> > possible to deactivate the compression even it is present in the client.ovpn
> > (no further changes are needed then).
> 
> That's great. Let's implement this so the admin can later change this.

Done, but i need to implement also some warning messages if this directive is used so affected users are better informed. How does this looks like ?

> 
> > As far as i can see it, Voracle works only in server/client environment so
> > N2N should be save in the manner cause it´s a p2p environment ?
> 
> I guess this is for all connections.

Have found a list of 5 attacking vectors which are.

Quote from https://nordvpn.com/blog/voracle-attack/ :

    They need to be on the same network as you;
    You need to be using an HTTP connection;
    You need to be using a browser vulnerable to VORACLE (anything but Chrome);
    You need to visit a website that the hacker controls;
    You need to be using OpenVPN with compression engaged.

> 
> > Another point is the compression are deactivated per default on IPFire but
> > the comp-lzo is available at the first glance on the global section. It
> > might be also a possibility to 1) bing it to the advanced section or to 2)
> > make it only available via CCD ?
> 
> CCD doesn't make much sense because you want compression on for everyone or
> no one instead of on an individual basis. I would be fine with moving it to
> the advanced section.

We would need compression configuration via CCD to accomplish the possibility to enable/disable compression via the server only (CCD pushes the deactivation of this directive if needed) otherwise the configuration files needs to be adapted on server and on client side.

One thing i´am currently not 100% sure. The OpenVPN manpage points the following out:

Quote from https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage :

--compress [algorithm]
    Enable a compression algorithm.

    The algorithm parameter may be "lzo", "lz4", or empty. LZO and LZ4 are different compression algorithms, with LZ4 generally offering the best performance with least CPU usage. For backwards compatibility with OpenVPN versions before v2.4, use "lzo" (which is identical to the older option "--comp-lzo yes").

    If the algorithm parameter is empty, compression will be turned off, but the packet framing for compression will still be enabled, allowing a different setting to be pushed later. 


whereby i get stuck with the following 
"compression will be turned off, but the packet framing for compression will still be enabled"
what does that mean for this kind of attack if the packet framing is still enabled ? 

May you have some ideas causing that ?

Best,

Erik

It seems that pushing 

compress
push "compress"

via CCD file do deactivates compression on client side without changing the client configuration file (if compression is active in config file).
However, there is a problem since the compression directive has been changed with OpenVPN-2.4 from

2.3 = comp-lzo
to
2.4 = compress lzo

this makes it more complicated to solve this problem in that way. If 2.3 clients get the

compress
push "compress"

pushed, the connection won´t work anymore. Error message:

Bad compression stub (swap) decompression header byte: 250

cause 2.3 clients do not know the new '--compress' directive. They would expect 

comp-lzo no
push 'comp-lzo no'

which is equivalent to the old directive '--comp-lzo'. This directives are not known anymore by the 2.4 clients and they will throw then the error message:

Bad compression stub (swap) decompression header byte: 250

. Every client do uses it´s own CCD file so two things needed to be done in case we would solve this problem in here like described above.

1) The admin needs to know which OpenVPN client version is on the other side.
2) We would need to provide a 2.3 and a 2.4 push directive option over the WUI.

Not that good in my opinion but i currently see no other way...

Testing reference for this can be found in here --> https://forums.openvpn.net/viewtopic.php?f=4&t=26913 .

Currently not sure how to proceed further.

Best,

Erik

Hmm, so from your two messages I get that it is basically impossible to have a smooth migration path. That's fine with me.

What if we do the following:

a) Change the checkbox into a dropdown where you can select between "- None -", "LZO (Good compression)", "LZ4 (Excellent Compression)".

b) Move the dropdown to advanced.

c) Make no compression the default option.

d) Add a warning that enabling compression can harm the security of the tunnel: "Enabling compression increases chances for an eavesdropper to decrypt the connection"

Systems that use LZO won't be touched and if someone wants to disable it, they need to do it manually on all clients.

Does that sound good to you?

Hi Michael,

(In reply to Michael Tremer from comment #5)
> Hmm, so from your two messages I get that it is basically impossible to have
> a smooth migration path. That's fine with me.
> 
> What if we do the following:
> 
> a) Change the checkbox into a dropdown where you can select between "- None
> -", "LZO (Good compression)", "LZ4 (Excellent Compression)".
This is already done.

> 
> b) Move the dropdown to advanced.
Also done.

> 
> c) Make no compression the default option.
Done too.

> 
> d) Add a warning that enabling compression can harm the security of the
> tunnel: "Enabling compression increases chances for an eavesdropper to
> decrypt the connection"
Needs to be done. Thanks for the text, will go for a warning message then.

> 
> Systems that use LZO won't be touched and if someone wants to disable it,
> they need to do it manually on all clients.
That´s a little sad in my opinion... I can integrate also a menu in CCD section with e.g.

OFF
Disable compression for 2.3 clients
Disable compression for 2.4 clients
Enable LZO
Enable LZ4-v2

? In that case we have one more menu point (the 2.3 one) ? But this could be also a little overkill ?

> 
> Does that sound good to you?
In general yes. It might be handy to disable the compression via the server only without doing the changes on the clients (huge work if you have a lot cause all client changes needs to be done at once).

Best,

Erik

On Fri, 2018-08-24 at 12:59 +0000, IPFire Bugzilla wrote:
> That´s a little sad in my opinion... I can integrate also a menu in CCD section
> with e.g.
> 
> OFF
> Disable compression for 2.3 clients
> Disable compression for 2.4 clients
> Enable LZO
> Enable LZ4-v2

I have no idea how someone should use that. It might make sense if you
know what is going in behind, but I find this quite complicated.

It makes sense to enable/disable compression per connection for N2N,
but not for RW.

> ? In that case we have one more menu point (the 2.3 one) ? But this could be
> also a little overkill ?
> 
> > 
> > Does that sound good to you?
> In general yes. It might be handy to disable the compression via the server
> only without doing the changes on the clients (huge work if you have a lot
> cause all client changes needs to be done at once).

That might be handy but it breaks backwards compatibility. OpenVPN does
that every time. I am so sick of writing tons of glue-code to make
their bad design decisions work. This is impossible to maintain in the
long-term.

(In reply to Michael Tremer from comment #7)
> On Fri, 2018-08-24 at 12:59 +0000, IPFire Bugzilla wrote:
> > That´s a little sad in my opinion... I can integrate also a menu in CCD section
> > with e.g.
> > 
> > OFF
> > Disable compression for 2.3 clients
> > Disable compression for 2.4 clients
> > Enable LZO
> > Enable LZ4-v2
> 
> I have no idea how someone should use that. It might make sense if you
> know what is going in behind, but I find this quite complicated.
Yes true. You would need to know the inside of this vulnerability and how to fix it + you need also to know how CCD can be used for this...
Let´s forget this one.

> 
> It makes sense to enable/disable compression per connection for N2N,
> but not for RW.
For existing N2N connections is the need to make this on both sides equal. On new ones the compression is per default off.

> 
> > ? In that case we have one more menu point (the 2.3 one) ? But this could be
> > also a little overkill ?
> > 
> > > 
> > > Does that sound good to you?
> > In general yes. It might be handy to disable the compression via the server
> > only without doing the changes on the clients (huge work if you have a lot
> > cause all client changes needs to be done at once).
> 
> That might be handy but it breaks backwards compatibility. OpenVPN does
> that every time. I am so sick of writing tons of glue-code to make
> their bad design decisions work. This is impossible to maintain in the
> long-term.
ACK.

So i will work on the warning if compression is in usage and will include LZ4 for N2N and RW then only...

Best,

Erik

Hi Michael,
have found in a testing round today a problem with N2N and the compression directive.

The manpage says that writing only 'compression' into the configuration disables the compression algorithm. This was not true in my N2N tests.

One site has had no entry for 'comp-lzo' (compression disabled), the other side did have an entry with 'compression' only (which should disable it too) but i do get error messages


n2n[31014]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1475', remote='link-mtu 1474'
n2n[31014]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'

...

n2n[31014]: Bad compression stub (swap) decompression header byte: 42


which is a typical message for one side have an active and the other side an inactive compression.

This is a kind of BS... it means leave the directive out of the config is different then to deactivate it with (like outlined in manpage) an 'compress'
 only entry.

Did a lot of tests in Roadwarrior section especially with CCD whereby pushing the directive worked but i didn´t tested all possibilities (which i do think now i should before starting with a merge request).

Setting now the new directive name also in global RW section would break also the backwards compatibility for < 2.4 clients.
Same for N2N, if an OpenVPN-2.4 machine configures an TLS-Client connection which is < 2.4 with the new compress directive, it makes the connection unusable even the connection to each other is established.

I think this "new" option is currently not usable if there are a lot´s of clients and there are not all update to 2.4 . This site --> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--comp-lzo lines out that comp-lzo is deprecated but there is no date when OpenVPN will remove it.

Long story short:
- I would suggest to leave this option for some time behind until client updates to 2.4 are mostly common.
- I would add only a warning via webinterface if comp-lzo is in usage to inform the users about the compression+encryption vulnerability.


Best,

Erik

(In reply to Erik Kapfer from comment #9)
> Hi Michael,
> have found in a testing round today a problem with N2N and the compression
> directive.

Good that you are having a close look.

> The manpage says that writing only 'compression' into the configuration
> disables the compression algorithm. This was not true in my N2N tests.
> 
> One site has had no entry for 'comp-lzo' (compression disabled), the other
> side did have an entry with 'compression' only (which should disable it too)
> but i do get error messages
> 
> 
> n2n[31014]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu
> 1475', remote='link-mtu 1474'
> n2n[31014]: WARNING: 'comp-lzo' is present in local config but missing in
> remote config, local='comp-lzo'
> 
> ...
> 
> n2n[31014]: Bad compression stub (swap) decompression header byte: 42

Great.

> which is a typical message for one side have an active and the other side an
> inactive compression.
> 
> This is a kind of BS... it means leave the directive out of the config is
> different then to deactivate it with (like outlined in manpage) an 'compress'
>  only entry.

Absolutely. OpenVPN is being ridiculous here and becoming very hard to ship for us.

I guess this leaves us with just shipping the legacy option here and not to integrate anything new.

> Did a lot of tests in Roadwarrior section especially with CCD whereby
> pushing the directive worked but i didn´t tested all possibilities (which i
> do think now i should before starting with a merge request).
> 
> Setting now the new directive name also in global RW section would break
> also the backwards compatibility for < 2.4 clients.
> Same for N2N, if an OpenVPN-2.4 machine configures an TLS-Client connection
> which is < 2.4 with the new compress directive, it makes the connection
> unusable even the connection to each other is established.

If it doesn't work 100% reliable and people have to consider which version of the client they are running, this is becoming useless. VPNs need to just work.

> I think this "new" option is currently not usable if there are a lot´s of
> clients and there are not all update to 2.4 . This site -->
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--comp-lzo
> lines out that comp-lzo is deprecated but there is no date when OpenVPN will
> remove it.

Let's keep it then.

> Long story short:
> - I would suggest to leave this option for some time behind until client
> updates to 2.4 are mostly common.

Agreed. That probably won't happen soon because it is hard to migrate.

> - I would add only a warning via webinterface if comp-lzo is in usage to
> inform the users about the compression+encryption vulnerability.

Okay. And still move it to "advanced"?

(In reply to Michael Tremer from comment #10)
> > - I would add only a warning via webinterface if comp-lzo is in usage to
> > inform the users about the compression+encryption vulnerability.
> 
> Okay. And still move it to "advanced"?
Yes, good idea.

Best,

Erik

Hi,
patch has been send to mailinglist --> https://patchwork.ipfire.org/patch/2220/ .

I consider this being fixed by now. If it is not, please reopen.