Hello Nick,

You will have to know that a long long discussion has been preceding this. I appreciate your input, but you are not considering many problems that we sadly have to deal with. In a more perfect world, I am sure we would be able to make better decisions now. However, we have inherited a lot of debt with this feature. OpenVPN has been a huge pain point for many years and has only received patching, but never anything substantial.

On 17 Mar 2024, at 12:34, Nick Howitt <nick@howitts.co.uk> 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.

Exactly. In the past OpenVPN could not negotiate anything. Everything had to be configured on the client and the server side. If anything didn’t match, you might have a connection that considers itself up, but not a single packet can be transferred.

The client configurations that are currently out there might not use cipher negotiation and so we can’t remove this functionality easily. We have people out there with hundreds of OpenVPN connections which would have to be changed on the same day. It’s not going to happen.

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.

Nice idea, but not an option in this case.

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.

I am very well aware of that.

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.