From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Sat, 14 Oct 2023 13:05:45 +0100 Message-ID: <12FC3F17-E00D-4BBD-A6DB-099A1463C7A8@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2660952218554194124==" List-Id: --===============2660952218554194124== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello everyone, Apologies for my late response on this. The last week had a couple of urgent = things that were tying me in, but I was happy to see that we are finally maki= ng some progress on OpenVPN=E2=80=A6 > On 9 Oct 2023, at 13:05, Adolf Belka wrote: >=20 > Hi All, >=20 >=20 > Over the last week I have been working on the openvpn update using Erik's p= revious patches as my starting point. Could you please push those changes to a Git repository for review? Or did th= at happen already and I just was too blind to find them... > My first attempt to try and be able to understand the changes from each pat= ch to figure out what I needed to do proved difficult for me to work with. >=20 > What I then did was take the current ovpnmain.cgi and apply all of Erik's p= atches to it. >=20 > Then I have gone through that new version of ovpnmain.cgi and made the chan= ges based on previous discussions with Michael. >=20 > So I have removed the b2sum options that were present for the Data and Chan= nel Authentication. >=20 > I also moved all the cryptographic options from an additional advanced cryp= tographic options button into the Advanced Server options button. >=20 > I was successful in doing all the above and then tested the ovpnmain.cgi ou= t with a vm using the existing openvpn-2.5.9 version for openvpn. >=20 > My old profile for my laptop which had a ciphers entry worked without any p= roblem. My laptop was working withy openvpn-2.6.6 >=20 > I then created a new profile using the new ovpnmain.cgi using the negotiati= on option which ended up with a data-ciphers line. That also worked in making= a successful openvpn tunnel with my laptop without any issues. >=20 > I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1= .1 to make that work. >=20 > With that client version on my laptop both the old and new profiles connect= ed with a tunnel with no problems. >=20 > I then tried downgrading my laptop to openvpn-2.3.14 but to make this work = I would have had to downgrade the laptop to openssl-1.0.0 which I was not wil= ling to do as that is very old and very insecure. >=20 > The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nea= rly 7 years old. I think that it is an acceptable baseline to only support OpenVPN 2.4 and up.= That is already a lot more than we actually need to do, and we would support= clients that are probably vulnerable to many things=E2=80=A6 If we need to d= rop support for OpenVPN 2.4 in this process, that might also be acceptable. What is *not* so acceptable is that the client configuration file has to be c= hanged in order to keep working with newer clients, because that would requir= e that admins update every single configuration file if the client software i= s being updated. And that can be a nightmare with hundreds of connections. Being on the topic of compatibility, I do believe that it is acceptable that = connections that are generated today are only working with clients OpenVPN >= =3D 2.6 if we have to do it. > That version also worked with both the old and new laptop profiles. >=20 > I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6= version of openvpn. >=20 > Both these openvpn versions worked with both the old and new laptop connect= ion profiles with my laptop on version 2.4.0 and on 2.6.6 >=20 > All the above was using network manager with its openvpn plugin option on t= he laptop for making the openvpn tunnel connections. >=20 > As far as I can tell everything is working fine when negotiation is specifi= ed on the server. Old profiles that just use the cipher option also work fine= . Therefore my plan is to only use the negotiation option and not make it sel= ectable for older clients. The data-ciphers-fallback option in the server see= ms to be doing its job. >=20 > The negotiation option on the server was able to connect to a 2.4.0 client = on my laptop. >=20 > According to the OpenVPN wiki on cipher negotiation the data-ciphers-fallba= ck option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need t= o be using openssl-1.0.0 then I think if those clients work then fine but not= hing further back. >=20 > Overall, I am very happy with what I have succeeded in doing so far. I achi= eved things much quicker than I had expected. >=20 > I will now try and see about creating a profile on a CU 179 based system th= at uses one of the old insecure ciphers such as Blow Fish and restore that in= to my evaluation vm and see how that works with my laptop when I have it down= graded to openvpn-2.4.0 >=20 > I already know that if the laptop is at openvpn-2.6.6 then it will not acce= pt a blowfish cipher (or another weak cipher such as DES) as that is somethin= g I tested in the past. >=20 > If that also works then my plan will be to take the updated ovpnmain.cgi an= d split the changes into a new range of patches and then submit them for cons= ideration. Okay, just to sum this up for me, what will happen is this (in no particular = order): * The cipher option in the configuration file will be removed and changed to = data-cipher-fallback. That way, we will continue to support older clients and= new ones will use NCP. * There will be a new UI element where people can select ciphers to use in = =E2=80=9Cdata-ciphers=E2=80=9D very similarly to how to select a cipher for I= Psec * There will be a deprecation warning for people who use an older (64 bit) = =E2=80=9CCIPHER=E2=80=9D and they will be encouraged to upgrade all their cli= ents to OpenVPN >=3D 2.4 (which should already have happened anyways) and the= y should use NCP only (i.e. no data-cipher-fallback option in the server conf= iguration file any more). This will also be the new default. How do we do all this for N2N connections? Is is safe to just remove the ciph= er option entirely because we assume that all clients perform NCP anyways? * In the near future (2.7), the fallback option will have to be removed for a= ll, which will render clients that are OpenVPN <=3D 2.4 unusable. This is pro= bably acceptable at this point in time. * We will have to deprecate LZO as well. Do your patches include anything abo= ut that? > That will probably end up later in November as I will be busy with personal= things at the end of October / beginning of November. >=20 >=20 > Regards, >=20 > Adolf. >=20 -Michael --===============2660952218554194124==--