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.