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:45:21 +0000 Message-ID: <0449C11A-8F45-4D2D-8001-685956D4572D@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2910914002340871853==" List-Id: --===============2910914002340871853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 17 Mar 2024, at 15:47, Nick Howitt wrote: >=20 > What about the idea of using the dropdown to populate --data-ciphers-fallba= ck instead of whatever it populates now. Then you can enable autonegotiation = at the same time, if I've read the doc correctly. >=20 > Re compression, you can ignore the settings in the raodwarriors by setting: > compress stub-v2 > push "compress stub-v2" > in the server. I did that years ago for the ClearOS server. It effectively = ignores what is set in the client unless the client uses the settings to disa= llow pushes but that would not be normal. If I remember correctly we tested that we cannot push =E2=80=9Cno compression= =E2=80=9D once the client has any kind of compression configured. We now totally discourage using compression because it weakens the cryptograp= hy. We only have the checkbox to support installations that are old and have = it enabled. >=20 > On 17/03/2024 15:25, Adolf Belka wrote: >> Hi Nick, >>=20 >> On 17/03/2024 15:56, Nick Howitt wrote: >>> Crumbs. Still supporting 2.3? That should be a no-no. Anyone with an expl= icit cipher in their roadwarriors will have problems if they are old, whateve= r you do. The oldest version at openvpn.net is 2.4.6 dating back to 2018. Eve= n then plenty of water has passed under the bridge e.g SWEET32 etc. Compressi= on should have been disabled and stubbed a long time ago. The minute you allo= w 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 (defau= lt) in the GUI?=20 >>>=20 >> 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 bre= ak. 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 fallbac= k 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. >>>=20 >> There is a migration path now with the move to cipher negotiation on the b= asis that all clients are 2.4.x or newer, which should now be a reasonable as= sumption but would not have been 6 years ago. >> The question would also be is it our role to break users systems because w= e think they are using too old or too insecure ciphers. I would say that is n= ot our role. So we need to find a path forward that allows users to make that= upgrade on a client by client basis. >>=20 >> We also need to ensure that all changes are dealt with in one go and not a= sk users to update their clients for ciphers now and then later on for compre= ssions settings etc. >>=20 >> The path forward I have looked at would also deal with the changes in comp= ression settings. If people currently have compression set in their clients t= hen compression is not used, just the headers are implemented but no compress= ion. >> However in future openvpn updates if compression is specified the client w= ill 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 u= sers are asked to update their client settings on a client by client basis on= ly once. >>=20 >> Regards, >>=20 >> Adolf. >>=20 >>> On 17/03/2024 14:05, Adolf Belka wrote: >>>>=20 >>>> Hi Nick,=20 >>>>=20 >>>> 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 con= nection. 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 o= f the remote end matching you with strong ciphers. If you specify a cipher, t= hen 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 b= ecause 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.=20 >>>>>=20 >>>> When the cipher negotiation was introduced by OpenVPN it was not backwar= ds compatible. If we had changed to cipher negotiation at that time then user= s with older clients would have just failed. This was not acceptable, especia= lly 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 system= s but maybe with older defined ciphers.=20 >>>>=20 >>>> Therefore we had to move to a situation where we had the ncp-disable opt= ion, so preventing cipher negotiation.=20 >>>>=20 >>>>> 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. Any= one who then wants to specify an option, then can, but they are going down th= eir 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.= =20 >>>>>=20 >>>> 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 longe= r holds as users would have to be still using clients at version 2.3 or older= . Cipher negotiation came in with version 2.4=20 >>>>=20 >>>> 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 wit= h openssl-1.0.1x. So anyone still using it must be minimal now and very insec= ure.=20 >>>>=20 >>>> So now we can move to cipher negotiation but we still need to enable cip= her 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.=20 >>>>=20 >>>> 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 st= ill with the older ones so they can update on a client by client basis over t= ime. Currently we are on OpenVPN-2.5.9. With cipher negotiation enabled we wo= uld be able to move to the openvpn-2.6.x series. We then would have to stay o= n OpenVPN-2.6.x for a specified period to allow users to update any clients t= hat are using the much older ciphers.=20 >>>>=20 >>>> Once the period is past we could then consider updating to openvpn-2.7 s= eries which is likely to come somewhere during this year but that will active= ly prevent any older ciphers being used so all users must have updated all cl= ients by that time.=20 >>>>=20 >>>>> Also, by specifying the options you get a maintenance issue where the d= ropdowns need to be maintained to stay in line with every update to the under= lying openvpn code.=20 >>>>>=20 >>>>> There is a possibly useful document at https://community.openvpn.net/op= envpn/wiki/CipherNegotiation.=20 >>>>>=20 >>>> 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 maki= ng sure we impact existing users the least and move to a position where the u= sers can update their clients one at a time, rather than a big bang update wh= ere all clients stop working and all have to be updated at the same time duri= ng which no users of the organisation are able to use their roadwarrior conne= ctions.=20 >>>>=20 >>>>=20 >>>> 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 abl= e to test this out in some way, to be sure we are not creating a breaking IPF= ire for users when the update is released to Testing and then Full Release.=20 >>>>=20 >>>> That is where I have been trying to work on, while at the same time tryi= ng 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 enoug= h and have been diverted by other things.=20 >>>>=20 >>>> Has the non-breaking, backwards compatible approach we have used histori= cally 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 ne= xt step, again without creating a breaking, backwards incompatible approach. = >>>>=20 >>>> Always open to alternative approaches, if they are easier to implement a= nd maintain the non-breaking, backwards compatible policy and give a migratio= n path to move forward on a client by client update basis.=20 >>>>=20 >>>> Regards,=20 >>>>=20 >>>> Adolf.=20 >>>>=20 >>>>> Regards,=20 >>>>>=20 >>>>> Nick=20 >>>>>=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 c= ould wait till later or were not needed.=20 >>>>>>=20 >>>>>> This created a single diff file, which I was able to apply and test ou= t 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 ea= sily 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 m= ake sense of.=20 >>>>>>=20 >>>>>> My next step was therefore going to be to go back to an unmodified ovp= nmain.cgi file and make the changes a step at a time, to match what I had pre= viously done and therefore end up with a patch set of small self consistent c= hanges.=20 >>>>>>=20 >>>>>> 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 d= id something else in IPFire for a week or so I was having to go back to squar= e one 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=3Dcommi= t;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 with= out diverting to anything else, after I have dealt with the wsdd patch modifi= cation.=20 >>>>>>=20 >>>>>> Regards,=20 >>>>>>=20 >>>>>> Adolf.=20 >>>>>>=20 >>>>>=20 >>>=20 >>=20 >> --=20 >> Sent from my laptop >=20 --===============2910914002340871853==--