Hi, On Mon, Apr 26, 2021 at 09:16:39PM +0000, Marc Lasch via Openvpn-users wrote: > WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This > allows attacks like SWEET32. Mitigate by using a --cipher with a larger > block size (e.g. AES-256-CBC). > > Somehow BF-CBC seems to be used, despite NCP should select AES-256-GCM. > Sadly, I cannot provide more insight, because as soon as I want to > increase the verbosity and restart the affected client, the warning > disappears and the client connects with AES-256-GCM. Enabling verb 4 > on all clients precautionary is not feasible. I am not yet able to > reproduce the behavior in a lab setup.
Set verb 4 on the server. It will show you the incoming IV_ strings
(of which "IV_NCP=1" will trigger negotiating AES-256-GCM) and the
PUSH_REPLY the server sends back to the client (containing a "cipher"
string - or not) and should give some insights on what is happening.
> What could cause a client (or server?) to suddenly fall back to BF-CBC even
> when NCP is enabled? The clients are MIPS and ARMv5 machines whereas the
> servers run ordinary x86_64. Updating to 2.5 is not an option right now.
We're not aware of anything that could trigger this.
You should investigate upgrading the server, though. 2.4.4 is really
old - 2.5.2 (on the server) should be a much better choice.
In the ChangeLog I'm not seeing a particular patch that could have this
effect, but there's about 200 patches from 2.4.4 to 2.4.11 - quite a few
bugfixes.
> I was wondering if there is some magic happening in edge cases during
> negotiation (e.g. losing a specific packet, firewall, proxy (I use TCP
> transport)).
If you use TCP, you can't lose packets. But even if you could, the
openvpn reliability layer would retransmit it.
Generally speaking, what happens is that the client sends a bunch of
"strings" to the server when connecting, as part of the initial TLS
handshake and authentication. One of them is IV_NCP=<number>, another
is IV_CIPHERS=<list>. If there is only IV_NCP=1, the server will assume
"this client is an early 2.4 client, and can do AES-128-GCM:AES-256-GCM"
and will pick one of those.
If there is IV_CIPHERS=..., the server will pick an acceptable cipher
from that list (acceptable = on the server ncp-ciphers list).
2.5 will also look at the incoming OCC string ("option consistency
check") to see what "cipher foo" was configured on the client. If
NCP fails, it will use that cipher.
So with 2.5 on the server, you can just put
cipher AES-256-GCM
into your client configs, and should NCP fail for whatever reasons, it
will still use this cipher.
> Does anybody have more insight in how the cipher negotiation works in detail?
openvpn-devel is a slightly better choice for "does anybody have more
insight?" style questions, as all the developers are on the -devel list,
and specifically Arne (who did most of the NCP work on 2.5) is not.
We do have a nice document, though :-)
https://community.openvpn.net/openvpn/wiki/CipherNegotiation
(this is more aimed at explaining what can happen when you mix stuff
like "2.2 client, 2.5 server", but it shows how the various cipher
commands interact)
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
