Hi, On Sat, Aug 08, 2020 at 08:11:13PM +0200, Arne Schwabe wrote: > > Not sure how to tackle the "ccd/ push cipher is broken now with 2.4-NCP > > clients" part. I think this is useful functionality, but the current > > patch does not allow this "unless the client is already using the to-be- > > pushed cipher, or it's one of the two NCP=2 AEAD ciphers". Which makes > > it slightly less than useful... > > I am not sure we can fix this in a good way. The behaviour is bascially > blindly push a cipher no matter what the client announces.
Yes. And set the server instance to use this cipher.
So something like "--data-cipher-override-push"...
The use of that option would, basically, be "I have lots of 2.4 clients,
I can not update their client configs all over night, but for whatever
reason I do not want to use AES-GCM ciphers (and not BF-CBC either)". I
can not foresee a strong reason to not use AES-GCM, but maybe some sort
of embedded platform that performs great on ChaCha-Poly and very poorly
on AES... or, worst case, AES is broken.
Not sure how realistic that is.
> What we would need to still support this behaviour is a
>
> --data-cipher-force-cipher-if-only-iv_ncp2-present cipher
>
> that picks that cipher if the client has only IV_NCP=2. That sounds like
> a very ugly and obscure option. Or an option that is
>
> --iv-ncp-2-is-data-ciphers "foo:AES-128-CBC:MySpecial-Cipher"
>
> and then the server would translate IV_NCP=2 to that list instead of
> "AES-256-GCM:AES-128-GCM"
>
> All other options that I can come up break proper negotiation support.
Either this ("we pretend the client has really sent *this* list of
ciphers") or we override negotiation by forcing a particular cipher
for this client (use on the server and push to client - which a 2.3
and 2.2 client will ignore with a warning).
Overriding could come with a warning in the server log ("forcing a
cipher that is not in the list advertised by the client, might break").
> The option names are of course silly and would need to be replaced by
> better sounding alternatives. *If* we want to support this corner case I
> would suggest the second alternative and implement it in a follow up
> patch. The question is if this corner case is important enough to
> support it.
Doing this in a followup patch sounds reasonable... this could even
go into 2.5 later on (as it would fix a - small - regression).
So - let's get this in :-) - v3, please, which does not core dump.
Also, I think we need to better document what happens wrt cipher
negotiation depending on client/server combinations (2.2+2.3, 2.4,
2.5 to a 2.3 / 2.4 / 2.5 server, OCC/NCP/new NCP, ...).
Maybe a table in the Wiki? Or something in doc/
We have your commit message, which is a good start, but if people get
all confused about this (like I was :-) ), they will not look into the
git logs.
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-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
