On 17/03/2024 15:25, Adolf Belka
wrote:
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