From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: OpenVPN cipher negotiation patch set Date: Mon, 18 Mar 2024 16:39:22 +0000 Message-ID: <9AB3D624-7E9A-4F56-9FCB-95B5DEC3C9AA@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1345183621730707646==" List-Id: --===============1345183621730707646== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 sadl= y have to deal with. In a more perfect world, I am sure we would be able to m= ake 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 recei= ved patching, but never anything substantial. > On 17 Mar 2024, at 12:34, Nick Howitt wrote: >=20 > Can I ask a question? Why are we playing around with Cipher strings and has= hes? The minute you do that you make things much harder to get a good connect= ion. 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 th= e 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 becau= se what you have chosen is no longer recommended, you have a nightmare on you= r hands because you will have to update every remote client config where it h= as 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=E2=80=99t m= atch, 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 n= egotiation and so we can=E2=80=99t 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=E2=80=99s 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 dropd= owns need to be maintained to stay in line with every update to the underlyin= g openvpn code. >=20 > There is a possibly useful document at https://community.openvpn.net/openvp= n/wiki/CipherNegotiation. I am very well aware of that. >=20 > Regards, >=20 > Nick >=20 > On 17/03/2024 11:35, Adolf Belka wrote: >>=20 >> Hi Michael,=20 >>=20 >> I am afraid I don't have a patch set. It is just a single diff change.=20 >>=20 >> 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.=20 >>=20 >> 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.=20 >>=20 >> 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.=20 >>=20 >> My next step was therefore going to be to go back to an unmodified ovpnmai= n.cgi file and make the changes a step at a time, to match what I had previou= sly done and therefore end up with a patch set of small self consistent chang= es.=20 >>=20 >> However to do this I had to go back to the start and figure out which of E= rik's changes to apply and what parts of those changes and every time I did s= omething else in IPFire for a week or so I was having to go back to square on= e in trying to remember what I had been going to do next.=20 >>=20 >> The diff patch file I created is at=20 >>=20 >> https://git.ipfire.org/?p=3Dpeople/bonnietwin/ipfire-2.x.git;a=3Dcommit;h= =3D4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035=20 >>=20 >> Hopefully you can use this as a basis to extract just the bits needed for = the cipher negotiation.=20 >>=20 >> 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 modificati= on.=20 >>=20 >> Regards,=20 >>=20 >> Adolf.=20 >>=20 >=20 --===============1345183621730707646==--