data-ciphers mishandled during mixed-version deployments
I have a 2.5.8 server, with data-ciphers AES-256-GCM
. I have clients of 2.4 and 2.5 which, for legacy reasons, have cipher AES-256-CBC
as a common setting, until such time as we enforce everyone being on 2.5 and we'll pivot to using data-ciphers
in the client configs. This is obviously a cipher disconnect, but since ncp-disable
is not in play, clients negotiate up to GCM and are happy.
Today one of my Arch users upgraded and then couldn't connect through NM (Data channel cipher negotiation failed (no shared cipher)
) but could connect through raw openvpn
. commit 020ab0c4 has somewhat of a misthink in it.
For 2.5, --cipher
is deprecated, but it still means 'use this cipher', and then (assuming no --ncp-disable
) 'you can negotiate up to something else' if you have no --data-ciphers
specified. It can negotiate up to the unstated data-ciphers
defaults of AES-256-GCM:AES-128-GCM
.
When this commit kicked in, it replaced --data-ciphers
with --cipher
's contents. In the case of an absent --data-ciphers
directive, you end up taking data-ciphers
from "here's 2 default choices" to "here's 1 explicit choice", when the right answer (under principle of least surprise) is probably to append/merge --cipher
contents into the assumed-defaults of the default (GCM) data-ciphers.
This is certainly an edge case, but, wanted to call it out.