Hi Nick,
On 17/03/2024 15:56, Nick Howitt
wrote:
Crumbs. Still supporting 2.3? That should be a no-no. Anyone
with an explicit cipher in their roadwarriors will have problems
if they are old, whatever you do. The oldest version at
openvpn.net is 2.4.6 dating back to 2018. Even then plenty of
water has passed under the bridge e.g SWEET32 etc. Compression
should have been disabled and stubbed a long time ago. The
minute you allow cipher negotiation, you risk breakage if the
client uses a cipher which is not currently supported. Are you
going to allow the cipher to be unset (default) in the GUI?
No not now but when the ncp-disable was added 6 years ago when
openvpn was at version 2.4.5 things were very different.
There isn't really an upgrade path if you have a number of
clients using explicit ciphers, because the minute you upgrade
the server, clients will break. If you update the client before
the server, the client will break as well. I have not studied
the effect of that document, but can you use the fallback cipher
(--data-ciphers-fallback) as the parameter you change from the
GUI? Then you will have auto negotiation enabled as well. Then
you give the users a fixed timeline to update their clients
software and/or configs after which you can remove it again.
This may work.
There is a migration path now with the move to cipher negotiation
on the basis that all clients are 2.4.x or newer, which should now
be a reasonable assumption but would not have been 6 years ago.
The question would also be is it our role to break users systems
because we think they are using too old or too insecure ciphers. I
would say that is not our role. So we need to find a path forward
that allows users to make that upgrade on a client by client
basis.
We also need to ensure that all changes are dealt with in one go
and not ask users to update their clients for ciphers now and then
later on for compressions settings etc.
The path forward I have looked at would also deal with the changes
in compression settings. If people currently have compression set
in their clients then compression is not used, just the headers
are implemented but no compression.
However in future openvpn updates if compression is specified the
client will fail to operate because it will be considered an
error. So again with the change from openvpn-2.5.x to 2.6.x there
is a compression migration path and we need to combine both the
compression and cipher migration paths so that users are asked to
update their client settings on a client by client basis only
once.
Regards,
Adolf.
On 17/03/2024 14:05, Adolf Belka
wrote:
Hi Nick,
On 17/03/2024 13:34, Nick Howitt wrote:
Can I ask a question? Why are we
playing around with Cipher strings and hashes? The minute
you do that you make things much harder to get a good
connection. The reason is because, if they are not
specified, OpenVPN chooses a good safe set that allows
multiple strong ciphers. This gives a high chance of the
remote end matching you with strong ciphers. If you specify
a cipher, then you restrict all connections to that single
cipher as you don't have any form of multi-select. Then, if
you ever want to change your choice, perhaps because what
you have chosen is no longer recommended, you have a
nightmare on your hands because you will have to update
every remote client config where it has also been specified.
When the cipher negotiation was introduced by OpenVPN it was
not backwards compatible. If we had changed to cipher
negotiation at that time then users with older clients would
have just failed. This was not acceptable, especially as to
update every client would have had to been updated at the same
time, not acceptable for users with 200 or more clients
running with their systems but maybe with older defined
ciphers.
Therefore we had to move to a situation where we had the
ncp-disable option, so preventing cipher negotiation.
At a minimum, the dropdowns should
have an option which says "default" when nothing is put in
the config, and this should be the default option. Anyone
who then wants to specify an option, then can, but they are
going down their own blind alley. If it were me, I would not
even give the user a choice. If I had to, I would give them
a choice to exclude ciphers, but not set them.
No we are looking at moving from the ncp-disable situation to
one where cipher negotiation is enabled. The previous issue
with older clients no longer holds as users would have to be
still using clients at version 2.3 or older. Cipher
negotiation came in with version 2.4
So any users still using version 2.3 will have to update but
that should be a very small number now, especially as that
older version only worked with openssl-1.0.1x. So anyone still
using it must be minimal now and very insecure.
So now we can move to cipher negotiation but we still need to
enable cipher selection for those users that have clients with
older ciphers. These may be insecure but again we need to
allow users to update their clients one at a time, not require
them to update all clients at the same time.
Once we have cipher negotiation in place, the users will be
able to have a mixed situation of some clients with newer
ciphers specified and others still with the older ones so they
can update on a client by client basis over time. Currently we
are on OpenVPN-2.5.9. With cipher negotiation enabled we would
be able to move to the openvpn-2.6.x series. We then would
have to stay on OpenVPN-2.6.x for a specified period to allow
users to update any clients that are using the much older
ciphers.
Once the period is past we could then consider updating to
openvpn-2.7 series which is likely to come somewhere during
this year but that will actively prevent any older ciphers
being used so all users must have updated all clients by that
time.
Also, by specifying the options you
get a maintenance issue where the dropdowns need to be
maintained to stay in line with every update to the
underlying openvpn code.
There is a possibly useful document at https://community.openvpn.net/openvpn/wiki/CipherNegotiation.
Yes, I am aware of that document and that has been the basis
of deciding how to move forward to allow the cipher
negotiation to be enabled while making sure we impact existing
users the least and move to a position where the users can
update their clients one at a time, rather than a big bang
update where all clients stop working and all have to be
updated at the same time during which no users of the
organisation are able to use their roadwarrior connections.
The next challenge is how to make all these changes in the
ovpnmain.cgi code, in a way that does allow the existing
systems to continue and to be able to test this out in some
way, to be sure we are not creating a breaking IPFire for
users when the update is released to Testing and then Full
Release.
That is where I have been trying to work on, while at the same
time trying to understand the code, as I am relatively new
into what currently exists and I have found it a big
challenge. I have made progress but not quick enough and have
been diverted by other things.
Has the non-breaking, backwards compatible approach we have
used historically been the best option. I don't know, but it
is what has been used and so we now have to find a way to move
forward from that current status to the next step, again
without creating a breaking, backwards incompatible approach.
Always open to alternative approaches, if they are easier to
implement and maintain the non-breaking, backwards compatible
policy and give a migration path to move forward on a client
by client update basis.
Regards,
Adolf.
Regards,
Nick
On 17/03/2024 11:35, Adolf Belka wrote:
Hi Michael,
I am afraid I don't have a patch set. It is just a single
diff change.
I took Erik's original patch set and applied it to the
latest ovpnmain.cgi version at that time and then removed
some of the items that I decided could wait till later or
were not needed.
This created a single diff file, which I was able to apply
and test out to confirm it did what I expected it to do,
which it seemed to do.
The next step I then had intended to do was to break that
single diff into multiple patches but I found this very
difficult to do as I could not easily figure out which
bits needed to go together in different patches. Trying to
understand all the changes and what each were related to I
struggled to make sense of.
My next step was therefore going to be to go back to an
unmodified ovpnmain.cgi file and make the changes a step
at a time, to match what I had previously done and
therefore end up with a patch set of small self consistent
changes.
However to do this I had to go back to the start and
figure out which of Erik's changes to apply and what parts
of those changes and every time I did something else in
IPFire for a week or so I was having to go back to square
one in trying to remember what I had been going to do
next.
The diff patch file I created is at
https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=commit;h=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
Hopefully you can use this as a basis to extract just the
bits needed for the cipher negotiation.
I will also go back and start again to work on it but
focus on it without diverting to anything else, after I
have dealt with the wsdd patch modification.
Regards,
Adolf.
--
Sent from my laptop