2017-11-16 15:39 GMT+05:00 Jan Just Keijser <janj...@nikhef.nl>:
> Hi,
>
>
> On 16/11/17 11:29, Илья Шипицин wrote:
>
>
>
> 2017-11-16 15:21 GMT+05:00 Jan Just Keijser <janj...@nikhef.nl>:
>
>> Hi,
>>
>>
>> On 16/11/17 09:42, Илья Шипицин wrote:
>>
>>
>>
>> 2017-11-16 13:35 GMT+05:00 David Sommerseth <
>> open...@sf.lists.topphemmelig.net>:
>>
>>> On 16/11/17 06:59, Илья Шипицин wrote:
>>> > hi,
>>> >
>>> > I'm running vpn server since 2012, with comp-lzo enabled (on both
>>> client
>>> > and server side)
>>> >
>>> > in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
>>> >
>>> > also, I'm considering switching to lz4 from lzo.
>>> >
>>> > any best practice how to switch lzo --> lz4 without operation
>>> interruption ?
>>>
>>> First of all, I'd recommend you to do some performance testing on the
>>> typical payload you're pushing through your tunnel. You might find that
>>> LZO can perform better than LZ4 in some scenarios with a lower CPU load.
>>> But it is hard to come with a generic recommendation; it depends a lot
>>> on what you push through your tunnel and how compressible that data
>>> stream is. A bit more info can be found here: <
>>> https://github.com/lz4/lz4/>
>>>
>>> Another detail is the security aspects related to compressing data
>>> streams. The CRIME attack [0] is now an ageing side-channel attack
>>> vector which is made possible due to compression. And there are other
>>> compression oracle attacks [1] too, like BREACH [2].
>>>
>>> [0] <https://en.wikipedia.org/wiki/CRIME>
>>> [1] <https://en.wikipedia.org/wiki/Oracle_attack>
>>> [2]
>>> <https://threatpost.com/breach-compression-attack-steals-htt
>>> ps-secrets-in-under-30-seconds/101579/>
>>>
>>> --compress is pushable. Not sure if you can mix lzo and lz4
>>>
>>
>> it is a separate question, why pushing must be enabled (and it is not
>> enabled by default).
>>
>> this is mostly due to historical reasons: if you enable any form of
>> compression, one byte is reserved in each packet for a possible compression
>> flag. Thus, for incompressible data, it actually *hurts* performance to
>> enable compression.
>>
>>
>> however, I address here another question, are lzo and lz4 mutually
>> exclusive ?
>>
>> yes, they are: you can only specify one type of compression per server.
>>
>>
>> according to man page, you must explicitely specify either "compression
>> lzo" or "compression lz4".
>>
>>
>>> compression, but I'd just add 'compression' in all the config files and
>>>
>>
>> just "compression" is somewhat not clearly covered by documentation. is
>> it "stub" ? or is it "enable both lzo and lz4" ?
>>
>>
>>> then only push 'compress {lzo,lz4}' to those clients that is reasonable
>>> to use. I would not, however, enable compression itself on by default -
>>> just have the compression framing available.
>>>
>>>
>> by adding
>> compression
>> or
>> comp-lzo
>> to the client config, you turn on the compression bit in each packet, and
>> thus allow the server to push the compression algorithm of choice to all
>> clients.
>>
>
> so, if clients support pushes (2.3 or higher), I can leave "comp-lzo" in
> client configs .... enable "compress lz4" in server configs and push it ?
> those clients who do not support pushes will get broken ?
>
>
> yes, pretty much: all clients that have 'comp-lzo' in the client config
> and that support LZ4 can be told to use LZ4 compression by adding
> push "compress lz4"
> in the server config.
> "push-peer-info" will tell you whether a client supports LZ4 or not.
>
I missed that, thank you!
we already put all clients IV_xxx variables to log. I can check all clients.
>
> JJK
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
