diff mbox series

[Openvpn-devel] Fix 'compress migrate' for 2.2 clients.

Message ID 20210402134529.27866-1-gert@greenie.muc.de
State Accepted
Headers show
Series [Openvpn-devel] Fix 'compress migrate' for 2.2 clients. | expand

Commit Message

Gert Doering April 2, 2021, 2:45 a.m. UTC 
Commit 8fa8a17528c001a introduces "compress migrate" to move old clients
that have "compress" or "comp-lzo" in their config towards a connection
without compression.  This is done by looking at incoming OCC strings
to see if the client has compression enabled, and at incoming IV_
strings to see whether it can do "compress stub-v2" or needs to be sent
"comp-lzo no".

That check fails for 2.2 clients that do not send *any* peer-info by
default, so the server will not push back any "disable compression"
command.  It works if the client connects with "--push-peer-info".

Fix: turn around the order of checks, treat "no peer_info" the same
as "peer_info does not contain IV_COMP_STUBv2".

Signed-off-by: Gert Doering <gert@greenie.muc.de>
---
 src/openvpn/multi.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

Comments

Arne Schwabe April 2, 2021, 3:23 a.m. UTC | #1 
Am 02.04.21 um 15:45 schrieb Gert Doering:
> Commit 8fa8a17528c001a introduces "compress migrate" to move old clients
> that have "compress" or "comp-lzo" in their config towards a connection
> without compression.  This is done by looking at incoming OCC strings
> to see if the client has compression enabled, and at incoming IV_
> strings to see whether it can do "compress stub-v2" or needs to be sent
> "comp-lzo no".
> 
> That check fails for 2.2 clients that do not send *any* peer-info by
> default, so the server will not push back any "disable compression"
> command.  It works if the client connects with "--push-peer-info".
> 
> Fix: turn around the order of checks, treat "no peer_info" the same
> as "peer_info does not contain IV_COMP_STUBv2".

I actually did not test with 2.2 so I didn't notice this but the patch
looks good.

Acked-By: Arne Schwabe <arne@rfc2549.org>
Gert Doering April 2, 2021, 3:49 a.m. UTC | #2 
Patch has been applied to the master branch.

commit aba8776e6721030565b7b4ba3f88ac537ddcc5e0
Author: Gert Doering
Date:   Fri Apr 2 15:45:29 2021 +0200

     Fix 'compress migrate' for 2.2 clients.

     Signed-off-by: Gert Doering <gert@greenie.muc.de>
     Acked-by: Arne Schwabe <arne@rfc2549.org>
     Message-Id: <20210402134529.27866-1-gert@greenie.muc.de>
     URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21974.html
     Signed-off-by: Gert Doering <gert@greenie.muc.de>


--
kind regards,

Gert Doering
Simon Matter April 2, 2021, 7:35 a.m. UTC | #3 
> Commit 8fa8a17528c001a introduces "compress migrate" to move old clients
> that have "compress" or "comp-lzo" in their config towards a connection
> without compression.  This is done by looking at incoming OCC strings
> to see if the client has compression enabled, and at incoming IV_
> strings to see whether it can do "compress stub-v2" or needs to be sent
> "comp-lzo no".

Hi,

What I'm still wondering is why is compression so dangerous with OpenVPN
but not so with things like SSH or SCP?

Say I connect from my client to my server via SSH with compression is
fine. Doing the same trough an OpenVPN tunnel with compression using an
unencrypting tool like telnet is considered dangerous. I fail to
understand how the SSH tunnel can be considered okay and the OpenVPN
tunnel is not?

I've read a lot of the CRIME and BREACH stuff but still don't really
understand.

Thanks,
Simon

>
> That check fails for 2.2 clients that do not send *any* peer-info by
> default, so the server will not push back any "disable compression"
> command.  It works if the client connects with "--push-peer-info".
>
> Fix: turn around the order of checks, treat "no peer_info" the same
> as "peer_info does not contain IV_COMP_STUBv2".
>
> Signed-off-by: Gert Doering <gert@greenie.muc.de>
> ---
>  src/openvpn/multi.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 5c495036..56b4fc0d 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -2485,14 +2485,9 @@ multi_client_connect_compress_migrate(struct
> multi_context *m,
>      struct options *o = &mi->context.options;
>      const char *const peer_info = mi->context.c2.tls_multi->peer_info;
>
> -    if (!peer_info)
> -    {
> -        return CC_RET_SUCCEEDED;
> -    }
> -
>      if (o->comp.flags & COMP_F_MIGRATE &&
> mi->context.c2.tls_multi->remote_usescomp)
>      {
> -        if(strstr(peer_info, "IV_COMP_STUBv2=1"))
> +        if(peer_info && strstr(peer_info, "IV_COMP_STUBv2=1"))
>          {
>              push_option(o, "compress stub-v2", M_USAGE);
>          }
> --
> 2.26.3
>
>
>
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
Gert Doering April 2, 2021, 7:57 a.m. UTC | #4 
Hi,

On Fri, Apr 02, 2021 at 08:35:36PM +0200, Simon Matter wrote:
> What I'm still wondering is why is compression so dangerous with OpenVPN
> but not so with things like SSH or SCP?

The problem is adversary-controlled traffic in a VPN tunnel, like
"you surf on a web site, and there is java script that makes your
browser send carefully crafted requests while someone looks at your
VPN tunnel from the outside".

If compression is active, an attacker can see if "the parts of the
header that he can not see" are similar to "the parts that the java
script creates", due to compression making the resulting packets 
smaller if sequences are identical.

Supposedly you can use this to steal stuff like session cookies, 
which java script would normally not be able to see.


Now, I personally find this all a bit unrealistic in practice - it's
quite a number of "ifs", and even then, it's unclear if possible in
practice, or even interesting enough, given the myriard of easier to
exploit attack vectors.  

But it *is* a possible attack, and if weighting "is this a good feature?" 
against maintenance effort and possible security effects, compression 
starts drifting towards the negative side (because most traffic inside 
VPNs is already compressed or encrypted anyway today, so compression won't 
have a big effect).


Now, in ssh, you copy files of your own choice.  Compression is useful
there, if the files are not already compressed.  An attacker won't be
able to manipulate just *part* of one file, to see if the neighbouring
100 bytes are "similar"... so this class of attacks does not exist.

(Crypto people, correct me if I misstated something...)

gert
Simon Matter April 2, 2021, 9:04 a.m. UTC | #5 
> Hi,
>
> On Fri, Apr 02, 2021 at 08:35:36PM +0200, Simon Matter wrote:
>> What I'm still wondering is why is compression so dangerous with OpenVPN
>> but not so with things like SSH or SCP?
>
> The problem is adversary-controlled traffic in a VPN tunnel, like
> "you surf on a web site, and there is java script that makes your
> browser send carefully crafted requests while someone looks at your
> VPN tunnel from the outside".
>
> If compression is active, an attacker can see if "the parts of the
> header that he can not see" are similar to "the parts that the java
> script creates", due to compression making the resulting packets
> smaller if sequences are identical.
>
> Supposedly you can use this to steal stuff like session cookies,
> which java script would normally not be able to see.
>
>
> Now, I personally find this all a bit unrealistic in practice - it's
> quite a number of "ifs", and even then, it's unclear if possible in
> practice, or even interesting enough, given the myriard of easier to
> exploit attack vectors.
>
> But it *is* a possible attack, and if weighting "is this a good feature?"
> against maintenance effort and possible security effects, compression
> starts drifting towards the negative side (because most traffic inside
> VPNs is already compressed or encrypted anyway today, so compression won't
> have a big effect).
>
>
> Now, in ssh, you copy files of your own choice.  Compression is useful
> there, if the files are not already compressed.  An attacker won't be
> able to manipulate just *part* of one file, to see if the neighbouring
> 100 bytes are "similar"... so this class of attacks does not exist.
>

To me it seems like you can of course build a scenario where compression
_could_ be a problem some how, but there are certainly many use cases
where it can be considered almost impossible to have your security
weakaned by compression. I mean, there is also the SSH VPN mode with c<n
be used with compression and I've never heard someone saying it's less
secure with compression.

In our case where we connect several subnets via OpenVPN and there goes a
lot of different traffic from dozens of hosts in every location, I still
fail to understand how our security would be impacted by compression?

In the end my only question is is it worth to remove compression from
OpenVPN in the long run, or is this not planned?

Thanks,
Simon
Arne Schwabe April 2, 2021, 9:40 a.m. UTC | #6 
> 
> To me it seems like you can of course build a scenario where compression
> _could_ be a problem some how, but there are certainly many use cases
> where it can be considered almost impossible to have your security
> weakaned by compression. I mean, there is also the SSH VPN mode with c<n
> be used with compression and I've never heard someone saying it's less
> secure with compression.

That will be also affected by VORACLE style attacks. But SSH VPN and SSH
is also by no mean safe against these kind of attacks. They might be
harder to pull off but the underlying attacks still apply.

> In our case where we connect several subnets via OpenVPN and there goes a
> lot of different traffic from dozens of hosts in every location, I still
> fail to understand how our security would be impacted by compression?

The attacks are not that easy to understand. So not to patronise you but
if you if you don't understand it, then it might be better to err on the
safe side?

> In the end my only question is is it worth to remove compression from
> OpenVPN in the long run, or is this not planned?
> 

Attacks are becoming better and better if there is a vector to attack.
But Beast/Crime/VORACLE have shown that these attacks are possible, so
enabling compression by default is no longer safe.

The benefit of VPN compression are also dimished a lot in recent years.
Most traffic nowadays is already encrypted and even if the traffic is
still plain text, the VPN compression only works on a packet per time,
so the achievable gains are low.

I haven't seen any real life example of VPN compression doing anything
tangible in the recent years that wasn't a speedtest that send large
blocks of zeros.

Arne
Kristof Provost via Openvpn-devel April 2, 2021, 1:43 p.m. UTC | #7 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, 2 April 2021 19:35, Simon Matter <simon.matter@invoca.ch> wrote:

> > Commit 8fa8a17528c001a introduces "compress migrate" to move old clients
> > that have "compress" or "comp-lzo" in their config towards a connection
> > without compression. This is done by looking at incoming OCC strings
> > to see if the client has compression enabled, and at incoming IV_
> > strings to see whether it can do "compress stub-v2" or needs to be sent
> > "comp-lzo no".
>
> Hi,
>
> What I'm still wondering is why is compression so dangerous with OpenVPN
> but not so with things like SSH or SCP?
>

Simon, I believe the detail which you have over-looked is this:

A lot of people use openvpn as a client to VPN service providers believing
things which are not true.  They then surf the web with over-confidence.

In such a scenario, while pulling off such an attack on a compressed VPN
stream may seem remote, when you have such a vast number of victims to
potentially abuse, the temptation to do so and potential success rate
increase dramatically.

But i believe you need to have access to both the compressed VPN data
and the uncompressed https packets to exploit such an attack.

Still, it was shown to be a genuine attack vector none-the-less.

--
Regards
R
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsBzBAEBCAAGBQJgZ7oZACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ2Qzwf9GFUFmJrJv4ny2uvbLUWKHAGsFKsD12I5YeJLQArsAsP39w7k
H4chac7T/XLA2nBYLxIizioc3fiFqPTrlyx2AdwIuTpWhqf4FuU+pXt9JhqJ
spI6j907aSN/G1jDjWhzltrWrjhJg/a6VQvtuTzAcBx3h1AA3WwKvRCUVhm6
r0/jqRpb5OhA05Ux6JG0uqlCfG5zTURSaFdjwhEotvHpuzg9IpzEIBx42dnU
EgS+aoJPdxYSCldYbdwj9EWus1+MzNHd+JjZsxadqiGarC+I+r5q2fHC9bBA
EPdlbWGIdPcASeB0edWSI9uOO18UBpuaOnU4aBN/SXQJE4wApq1wUQ==
=LhbH
-----END PGP SIGNATURE-----
Kristof Provost via Openvpn-devel April 2, 2021, 1:50 p.m. UTC | #8 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 3 April 2021 01:43, tincantech via Openvpn-devel <openvpn-devel@lists.sourceforge.net> wrote:


>
> But i believe you need to have access to both the compressed VPN data
> and the uncompressed https packets to exploit such an attack.
>

Edit:
The attacker also needs to control the https website that the victim visits.

It's a tall order .. but do you really want to argue with the sort of people
that figured out how to do it ?

> Still, it was shown to be a genuine attack vector none-the-less.
>

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsBzBAEBCAAGBQJgZ7usACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ3yaAgAvefAvhIBj2izSl5JoOH2oPeCYunedXsrFOXjrvteC1GX/Hem
gRpLgcjNjdhcWdfW8NCFhihozr1Hrb9cLIxmvNLw5zmAIf6DRtcPPaExsyYJ
mDLXMFlKZmSoGc3Jh9hsXxFy5oEH2K2RtQxJevGciAHn6GSkPx0MrHLJlmCH
EPhUThW+QpEq+NdqNUo9dPJe9ByUUrZ9c/eySjXG8Eo7hYSLu0AhoYUr/zY1
OqpRNg3lsH6CRFkH7LV5cJEBGLF6qZLeAZ5x7UYGjWWR1pwI02AKknF5E9bW
s+4P64TLyIVerUsewJ9EbzU4kI5abf+pammwmqBHFrPaI1foNUS/dA==
=s7Ma
-----END PGP SIGNATURE-----
Simon Matter April 2, 2021, 9:32 p.m. UTC | #9 
>
>>
>> To me it seems like you can of course build a scenario where compression
>> _could_ be a problem some how, but there are certainly many use cases
>> where it can be considered almost impossible to have your security
>> weakaned by compression. I mean, there is also the SSH VPN mode with c<n
>> be used with compression and I've never heard someone saying it's less
>> secure with compression.
>
> That will be also affected by VORACLE style attacks. But SSH VPN and SSH
> is also by no mean safe against these kind of attacks. They might be
> harder to pull off but the underlying attacks still apply.
>
>> In our case where we connect several subnets via OpenVPN and there goes
>> a
>> lot of different traffic from dozens of hosts in every location, I still
>> fail to understand how our security would be impacted by compression?
>
> The attacks are not that easy to understand. So not to patronise you but
> if you if you don't understand it, then it might be better to err on the
> safe side?
>
>> In the end my only question is is it worth to remove compression from
>> OpenVPN in the long run, or is this not planned?
>>
>
> Attacks are becoming better and better if there is a vector to attack.
> But Beast/Crime/VORACLE have shown that these attacks are possible, so
> enabling compression by default is no longer safe.

I'm not asking to enable it by default or even compile it by default. I'm
only asking to keep the code in so those who know what they are doing can
enable it as a compile time option or expert mode option or something like
that.

Simon
Antonio Quartulli April 2, 2021, 9:43 p.m. UTC | #10 
Hi,

On 03/04/2021 10:32, Simon Matter wrote:
> I'm not asking to enable it by default or even compile it by default. I'm
> only asking to keep the code in so those who know what they are doing can
> enable it as a compile time option or expert mode option or something like
> that.

If you ask everybody, they always knew what they were doing, even when
something went wrong.

If there is no real usecase for a feature, and this feature is known to
be a potential risk, it is our duty to make sure people will not shoot
themselves in the foot.

If you have a use case that you think can benefit big time by having
compression, please feel free to describe it in details. Therefore might
be saner ways to address it.


If somebody feels being expert enough and knows what he is doing more
than the others, he can still re-add the feature (i.e. by reverting any
patch that might be removing the code) and recompile OpenVPN. The beauty
of Open Source :-)

Cheers,
Simon Matter April 2, 2021, 10:18 p.m. UTC | #11 
> Hi,
>
> On 03/04/2021 10:32, Simon Matter wrote:
>> I'm not asking to enable it by default or even compile it by default.
>> I'm
>> only asking to keep the code in so those who know what they are doing
>> can
>> enable it as a compile time option or expert mode option or something
>> like
>> that.
>
> If you ask everybody, they always knew what they were doing, even when
> something went wrong.
>
> If there is no real usecase for a feature, and this feature is known to
> be a potential risk, it is our duty to make sure people will not shoot
> themselves in the foot.
>
> If you have a use case that you think can benefit big time by having
> compression, please feel free to describe it in details. Therefore might
> be saner ways to address it.
>
>
> If somebody feels being expert enough and knows what he is doing more
> than the others, he can still re-add the feature (i.e. by reverting any
> patch that might be removing the code) and recompile OpenVPN. The beauty
> of Open Source :-)

I knew such answers will come :-)

But, back to security, why do you still allow OpenVPN being built on M$
Windows then? That's the real place where people are comforted with snake
oil and may be tempted to feel safe when using an OpenVPN tunnel but in
reality are vulnerable. Isn't this much worse than leaving compression in
as a compile time option?

Simon
Antonio Quartulli April 2, 2021, 10:40 p.m. UTC | #12 
Hi,

On 03/04/2021 11:18, Simon Matter wrote:
>> If you have a use case that you think can benefit big time by having
>> compression, please feel free to describe it in details. Therefore might
>> be saner ways to address it.
>>

It sounds like there is no answer to this?
Then why are we even discussing further? :-)

>>
>> If somebody feels being expert enough and knows what he is doing more
>> than the others, he can still re-add the feature (i.e. by reverting any
>> patch that might be removing the code) and recompile OpenVPN. The beauty
>> of Open Source :-)
> 
> I knew such answers will come :-)

It wasn't meant to be just "such answer". It is an option that people
willing to have compression can use.

I personally do that for other projects, because I believe I have a
usecase, but I also understand my case does not follow the project
philosophy or it is too specific.

> 
> But, back to security, why do you still allow OpenVPN being built on M$
> Windows then? That's the real place where people are comforted with snake
> oil and may be tempted to feel safe when using an OpenVPN tunnel but in
> reality are vulnerable. Isn't this much worse than leaving compression in
> as a compile time option?

This is totally orthogonal to having compression or not.


Cheers,
Simon Matter April 2, 2021, 10:52 p.m. UTC | #13 
> Hi,
>
> On 03/04/2021 11:18, Simon Matter wrote:
>>> If you have a use case that you think can benefit big time by having
>>> compression, please feel free to describe it in details. Therefore
>>> might
>>> be saner ways to address it.
>>>
>
> It sounds like there is no answer to this?
> Then why are we even discussing further?

It could be at least one feature to prevent people from moving over to
WireGuard?

Simon
Gert Doering April 2, 2021, 10:56 p.m. UTC | #14 
Hi,

On Sat, Apr 03, 2021 at 11:52:59AM +0200, Simon Matter wrote:
> > It sounds like there is no answer to this?
> > Then why are we even discussing further?
> 
> It could be at least one feature to prevent people from moving over to
> WireGuard?

Unless people can come up with real use cases why compression makes
sense for them, and just move over to wireguard "BECAUSE IT HAS NO
COMPRESSION EITHER, BUT YOU TOOK IT AWAY FROM ME!! STAMP FOOT!" this
is hardly a compelling argument.

Wireguard is a good protocol, and if what it can do for you is *enough*,
it might be a better solution.

OpenVPN solves a vastly larger problem space, so any comparision to
wireguard based on features that wireguard doesn't have is a bit weird.

gert
Simon Matter April 2, 2021, 11:06 p.m. UTC | #15 
> Hi,
>
> On Sat, Apr 03, 2021 at 11:52:59AM +0200, Simon Matter wrote:
>> > It sounds like there is no answer to this?
>> > Then why are we even discussing further?
>>
>> It could be at least one feature to prevent people from moving over to
>> WireGuard?
>
> Unless people can come up with real use cases why compression makes
> sense for them, and just move over to wireguard "BECAUSE IT HAS NO
> COMPRESSION EITHER, BUT YOU TOOK IT AWAY FROM ME!! STAMP FOOT!" this
> is hardly a compelling argument.

Our use case is simple, we don't want ANY application in our company to
consume more WAN bandwidth than is absolutely needed. Of course we're
using compression like in rsync where it's possible, but that's not
possible everywhere and with every application. So we also try to catch
those cases by using compression over the VPN links. In case there is no
compressible data, it doesn't hurt much, but it can help a lot with
compressible data.

That's the only reason why OpenVPN was better for us.

Simon
Antonio Quartulli April 3, 2021, 12:10 a.m. UTC | #16 
Hi,

On 03/04/2021 12:06, Simon Matter wrote:
> Our use case is simple, we don't want ANY application in our company to
> consume more WAN bandwidth than is absolutely needed. Of course we're
> using compression like in rsync where it's possible, but that's not
> possible everywhere and with every application. So we also try to catch
> those cases by using compression over the VPN links. In case there is no
> compressible data, it doesn't hurt much, but it can help a lot with
> compressible data.

Out of curiosity, would you be able to provide statistics of how much
you are saving and with which application protocol?


Cheers,
Simon Matter April 3, 2021, 2:07 a.m. UTC | #17 
> Hi,
>
> On 03/04/2021 12:06, Simon Matter wrote:
>> Our use case is simple, we don't want ANY application in our company to
>> consume more WAN bandwidth than is absolutely needed. Of course we're
>> using compression like in rsync where it's possible, but that's not
>> possible everywhere and with every application. So we also try to catch
>> those cases by using compression over the VPN links. In case there is no
>> compressible data, it doesn't hurt much, but it can help a lot with
>> compressible data.
>
> Out of curiosity, would you be able to provide statistics of how much
> you are saving and with which application protocol?

No, I can not show applications but I can tell you it's from a huge number
of different devices. There are thin clients but also a zoo of document
printers, different label printer types, barcode scanning devices, payment
terminals, DECT VoIP phones, alarm systems, lots of embedded systems,
document scanners, video cameras and the list goes on. It's quite
difficult to analyze every protocol and see how or if it can be compressed
which is why it's nice to know things get at least compressed when running
over the WAN links.

Example status shows this:

Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472

Apr  3 15:00:09 gw-X2 openvpn[1502]: pre-compress bytes,3152837867
Apr  3 15:00:09 gw-X2 openvpn[1502]: post-compress bytes,3142711232
Apr  3 15:00:09 gw-X2 openvpn[1502]: pre-decompress bytes,3045691308
Apr  3 15:00:09 gw-X2 openvpn[1502]: post-decompress bytes,4980566715

It shows at least that it does something. It's clear that the gain is not
so big but, this status doesn't show the negative effect that one stupid
protocol can have on the connection. If there is one device doing lots of
compressible traffic during half an hour per day, this can greatly disturb
connectivity during the half an hour. That's half an hour too much.

Simon
Gert Doering April 3, 2021, 5:53 a.m. UTC | #18 
Hi,

On Sat, Apr 03, 2021 at 03:07:11PM +0200, Simon Matter wrote:
> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472

This is indeed fairly significant - and if WAN circuits are full and/or
cost money per Gbyte, compression is still a win.

I'm more of a compression fan than not :-) - so this will be interesting
discussions indeed.

(Still, having "compress migrate" is a useful feature so if a VPN admin
decides "I want to disable this for my road warrior VPN users", he can,
without user complaints about "I HAVE THIS OCC WARNING IN THE LOG NOW!" -
more of a commercial support issue than anything else)

gert
Simon Matter April 4, 2021, 9:38 p.m. UTC | #19 
> Hi,
>
> On Sat, Apr 03, 2021 at 03:07:11PM +0200, Simon Matter wrote:
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472
>
> This is indeed fairly significant - and if WAN circuits are full and/or
> cost money per Gbyte, compression is still a win.
>
> I'm more of a compression fan than not :-) - so this will be interesting
> discussions indeed.

Hi Gert,

Based on the answers I got on this list I'm afraid there won't be any
discussion and compression is gone. That's really sad as it is a useful
feature for many use cases as I was easily able to show.

Regards,
Simon
Antonio Quartulli April 4, 2021, 9:59 p.m. UTC | #20 
Hi Simon

On 05/04/2021 09:38, Simon Matter wrote:
>> Hi,
>>
>> On Sat, Apr 03, 2021 at 03:07:11PM +0200, Simon Matter wrote:
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472
>>
>> This is indeed fairly significant - and if WAN circuits are full and/or
>> cost money per Gbyte, compression is still a win.
>>
>> I'm more of a compression fan than not :-) - so this will be interesting
>> discussions indeed.
> 
> Hi Gert,
> 
> Based on the answers I got on this list I'm afraid there won't be any
> discussion and compression is gone. That's really sad as it is a useful
> feature for many use cases as I was easily able to show.
> 


at the moment there is neither a patch nor a point on any meeting agenda
about removing compression from the OpenVPN codebase.

Please don't hastily draw such conclusions.

So far it was *you* opening this discussion about compression removal as
OT of the patch in the subject. We only expressed our personal opinions
about your statements.

[note that this patch is not about removing compression, but only about
helping those people who want to disable it]


*If* somebody will feel the need to remove compression at all, such
topic will definitely be discussed in an open community meeting first
(everybody is welcome to join).

Only then a a bunch of patches (for deprecation first and removal later)
that will appear and at that point there will be even more room for
discussion.


Still, this is the process we take for almost every feature
deprecation/removal, but nobody has started it for compression.


Regards,
Simon Matter April 4, 2021, 10:16 p.m. UTC | #21 
> Hi Simon
>
> On 05/04/2021 09:38, Simon Matter wrote:
>>> Hi,
>>>
>>> On Sat, Apr 03, 2021 at 03:07:11PM +0200, Simon Matter wrote:
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472
>>>
>>> This is indeed fairly significant - and if WAN circuits are full and/or
>>> cost money per Gbyte, compression is still a win.
>>>
>>> I'm more of a compression fan than not :-) - so this will be
>>> interesting
>>> discussions indeed.
>>
>> Hi Gert,
>>
>> Based on the answers I got on this list I'm afraid there won't be any
>> discussion and compression is gone. That's really sad as it is a useful
>> feature for many use cases as I was easily able to show.
>>
>
>
> at the moment there is neither a patch nor a point on any meeting agenda
> about removing compression from the OpenVPN codebase.
>
> Please don't hastily draw such conclusions.
>
> So far it was *you* opening this discussion about compression removal as
> OT of the patch in the subject. We only expressed our personal opinions
> about your statements.

Then I misunderstood what is written here?

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--compress

"Compression is not recommended and is a feature users should avoid using.
To signal this clearly, --comp-lzo and --compress are discouraged and
considered deprecated features. Beginning with 2.5, these options will no
longer enable compression, just enable the compression framing to be able
to receive compressed packets."

That made me feel compression support in 2.5 is only on a compatibility
level.

Regards,
Simon
Gert Doering April 4, 2021, 10:34 p.m. UTC | #22 
Hi,

On Mon, Apr 05, 2021 at 10:16:07AM +0200, Simon Matter wrote:
> Then I misunderstood what is written here?
> 
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--compress
> 
> "Compression is not recommended and is a feature users should avoid using.
> To signal this clearly, --comp-lzo and --compress are discouraged and
> considered deprecated features. Beginning with 2.5, these options will no
> longer enable compression, just enable the compression framing to be able
> to receive compressed packets."
> 
> That made me feel compression support in 2.5 is only on a compatibility
> level.

This is half-correct, and half-incomplete.  Look at 

  --allow-compression yes

(new in 2.5).

Yes, 2.5 will no longer send compressed packets unless explicitly permitted
by "allow-compression yes" - but the infrastructure is still there, and
still tested, but moved from "this is something everybody will want" to
"if you know what you are doing and why, you can still have it".

Regarding your other mail where you doubted that "there will be a discussion"
- well, I can assure you that there are discussions about every feature we
take out of OpenVPN (and usually, mails to openvpn-devel and openvpn-users
to figure out who might still be using it).  Many of these discussions do
not happen on the list but on the #openvpn-devel and #openvpn-meeting
IRC channels - but Samuli is sending the meeting minutes to the -devel
list (and they are on the trac web page), so we try to make transparent 
what we discuss and why.


As always, code is a balance between features, maintenance effort, bugs,
and security...

gert
Arne Schwabe April 4, 2021, 10:39 p.m. UTC | #23 
Am 05.04.21 um 09:38 schrieb Simon Matter:
>> Hi,
>>
>> On Sat, Apr 03, 2021 at 03:07:11PM +0200, Simon Matter wrote:
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472
>>
>> This is indeed fairly significant - and if WAN circuits are full and/or
>> cost money per Gbyte, compression is still a win.
>>
>> I'm more of a compression fan than not :-) - so this will be interesting
>> discussions indeed.
> 
> Hi Gert,
> 
> Based on the answers I got on this list I'm afraid there won't be any
> discussion and compression is gone. That's really sad as it is a useful
> feature for many use cases as I was easily able to show.

Currently compression is not planned to be removed for an upcoming
release. However from our discussion it should be clear that compression
has evolved from a once useful feature for VPN when the security impact
wasn't known and HTTP still was 90% vs 10% HTTPS to a niche feature as
enabling compression by default on a VPN is not reasonable any more.

The future will tell how long compression will stay in OpenVPN. It
depends on how big/small the niche is and how much work it is to
continue supporting this feature.

Arne
Simon Matter April 4, 2021, 10:48 p.m. UTC | #24 
> Hi,
>
> On Mon, Apr 05, 2021 at 10:16:07AM +0200, Simon Matter wrote:
>> Then I misunderstood what is written here?
>>
>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--compress
>>
>> "Compression is not recommended and is a feature users should avoid
>> using.
>> To signal this clearly, --comp-lzo and --compress are discouraged and
>> considered deprecated features. Beginning with 2.5, these options will
>> no
>> longer enable compression, just enable the compression framing to be
>> able
>> to receive compressed packets."
>>
>> That made me feel compression support in 2.5 is only on a compatibility
>> level.
>
> This is half-correct, and half-incomplete.  Look at
>
>   --allow-compression yes
>
> (new in 2.5).
>
> Yes, 2.5 will no longer send compressed packets unless explicitly
> permitted
> by "allow-compression yes" - but the infrastructure is still there, and
> still tested, but moved from "this is something everybody will want" to
> "if you know what you are doing and why, you can still have it".
>
> Regarding your other mail where you doubted that "there will be a
> discussion"
> - well, I can assure you that there are discussions about every feature we
> take out of OpenVPN (and usually, mails to openvpn-devel and openvpn-users
> to figure out who might still be using it).  Many of these discussions do
> not happen on the list but on the #openvpn-devel and #openvpn-meeting
> IRC channels - but Samuli is sending the meeting minutes to the -devel
> list (and they are on the trac web page), so we try to make transparent
> what we discuss and why.
>
>
> As always, code is a balance between features, maintenance effort, bugs,
> and security...
>
> gert

Ok, thanks for explaining.

Regards,
Simon
diff mbox series

Patch

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 5c495036..56b4fc0d 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2485,14 +2485,9 @@  multi_client_connect_compress_migrate(struct multi_context *m,
     struct options *o = &mi->context.options;
     const char *const peer_info = mi->context.c2.tls_multi->peer_info;
 
-    if (!peer_info)
-    {
-        return CC_RET_SUCCEEDED;
-    }
-
     if (o->comp.flags & COMP_F_MIGRATE && mi->context.c2.tls_multi->remote_usescomp)
     {
-        if(strstr(peer_info, "IV_COMP_STUBv2=1"))
+        if(peer_info && strstr(peer_info, "IV_COMP_STUBv2=1"))
         {
             push_option(o, "compress stub-v2", M_USAGE);
         }