From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: OpenVPN cipher negotiation patch set Date: Sun, 17 Mar 2024 15:05:05 +0100 Message-ID: <4fc12507-df74-4752-ae30-184693e1d897@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4556658846765778799==" List-Id: --===============4556658846765778799== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 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. > When the cipher negotiation was introduced by OpenVPN it was not backwards co= mpatible. If we had changed to cipher negotiation at that time then users wit= h older clients would have just failed. This was not acceptable, especially a= s 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 ciphe= r negotiation is enabled. The previous issue with older clients no longer hol= ds as users would have to be still using clients at version 2.3 or older. Cip= her 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 ope= nssl-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 s= election for those users that have clients with older ciphers. These may be i= nsecure but again we need to allow users to update their clients one at a tim= e, 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 mi= xed situation of some clients with newer ciphers specified and others still w= ith 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 b= e able to move to the openvpn-2.6.x series. We then would have to stay on Ope= nVPN-2.6.x for a specified period to allow users to update any clients that a= re 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 pr= event 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 dropd= owns need to be maintained to stay in line with every update to the underlyin= g openvpn code. > > There is a possibly useful document at https://community.openvpn.net/openvp= n/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 su= re 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 a= ll clients stop working and all have to be updated at the same time during wh= ich no users of the organisation are able to use their roadwarrior connection= s. 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 f= or 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 n= ow have to find a way to move forward from that current status to the next st= ep, again without creating a breaking, backwards incompatible approach. Always open to alternative approaches, if they are easier to implement and ma= intain the non-breaking, backwards compatible policy and give a migration pat= h 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 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. >> >> 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. >> >> The diff patch file I created is at >> >> https://git.ipfire.org/?p=3Dpeople/bonnietwin/ipfire-2.x.git;a=3Dcommit;h= =3D4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035 >> >> 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 modificati= on. >> >> Regards, >> >> Adolf. >> > --===============4556658846765778799==--