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.