Hi, On Fri, Feb 10, 2023 at 09:45:41AM +0100, Ralf Hildebrandt via Openvpn-users wrote: > > It does, and it matters a lot. Mullvad breaks the OpenVPN protocol > > with their server configs (they should never ever push "comp-lzo" > > settings to a client that is not signalling it's willingness to accept > > them). > > That's a bit like the problem we had locally. We were pushing > "compress" to 2.6 clients. But how can I check what the client is > willing to support?
The client will send you a set of IV_ variables, which are present
in the environment for --client-connect scripts. Most interesting
here are those that look like this:
Feb 10 09:56:22 boyle3 openvpn_s11[51694]: peer info:
IV_CIPHERS=AES-256-GCM:AES-128-GCM
Feb 10 09:56:22 boyle3 openvpn_s11[51694]: peer info: IV_LZ4=1
Feb 10 09:56:22 boyle3 openvpn_s11[51694]: peer info: IV_LZ4v2=1
Feb 10 09:56:22 boyle3 openvpn_s11[51694]: peer info: IV_LZO=1
Feb 10 09:56:22 boyle3 openvpn_s11[51694]: peer info: IV_COMP_STUB=1
Feb 10 09:56:22 boyle3 openvpn_s11[51694]: peer info: IV_COMP_STUBv2=1
so, IV_CIPHERS lists "which ciphers would the client accept", and
IV_$ALGORITHM=1 lists the accepted arguments to "compress $ALG"
(lowercasing).
If you see an incoming IV_COMP_STUBv2, push a "compression stub-v2",
which will effectively turn off compression.
Technically all the "v2" algorithms (like, "compression lz4-v2") send
uncompressed packets / incompressible packets without compression framing,
unlike "v1" which always changes the framing. So "stub-v2" enables
"compression with the no-compression algorithm", and since it's a v2
alg, uncompressed packets will be sent with "no compression framing".
When the "v2" stuff was designed, compression was still considered a good
thing, and "v2 framing" makes things more efficient... shortly after,
VORACLE happend, and "nah, compression is bad", so we're stuck with
overly complex ways to turn off something we do no longer want, but for
compatibility reasons cannot "just rip out". Apologies for the mess.
IV_COMP_STUB=1 says you can push "compress stub" which is, I think,
the same as "comp-lzo no" = turn *on* compression framing, but do not
compress.
One server instance can handle compression / comp-stub v1 / no compression
clients in parallel, *if* DCO is off on the server. In that case, your
client-connect script needs to generate compression config for the
server *and* for the client
compress lz4-v2
push "compress lz4-v2"
or
compress stub-v2
push "compress stub-v2"
or
comp-lzo no
push "comp-lzo no"
Alternatively you can just disallow compression on the server, and refuse
all clients that do not send IV_COMP_STUBv2=1 - this is about as old
as AES-GCM support, so all clients that could connect to a DCO enabled
server (= AES-GCM or ChachaPoly) should be willing to support stub-v2...
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
