From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Sat, 14 Oct 2023 15:57:25 +0200 Message-ID: <418a6116-2047-4e86-b737-0462f3e39311@ipfire.org> In-Reply-To: <12FC3F17-E00D-4BBD-A6DB-099A1463C7A8@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5469555845479471572==" List-Id: --===============5469555845479471572== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 14/10/2023 14:05, Michael Tremer wrote: > Hello everyone, >=20 > Apologies for my late response on this. The last week had a couple of urgen= t things that were tying me in, but I was happy to see that we are finally ma= king some progress on OpenVPN=E2=80=A6 >=20 >> On 9 Oct 2023, at 13:05, Adolf Belka wrote: >> >> Hi All, >> >> >> Over the last week I have been working on the openvpn update using Erik's = previous patches as my starting point. >=20 > Could you please push those changes to a Git repository for review? Or did = that happen already and I just was too blind to find them... No, I have been working on them on my vm on my desktop system as there has be= en a lot of coming and going as I worked on understanding various things. Wha= t I have now is different from what I started with. I will try and push the changes to my git repository but currently it is just= a single set of changes. I have not yet started to break the changes into se= ctions to have a commit patch against them yet. >=20 >> My first attempt to try and be able to understand the changes from each pa= tch to figure out what I needed to do proved difficult for me to work with. >> >> What I then did was take the current ovpnmain.cgi and apply all of Erik's = patches to it. >> >> Then I have gone through that new version of ovpnmain.cgi and made the cha= nges based on previous discussions with Michael. >> >> So I have removed the b2sum options that were present for the Data and Cha= nnel Authentication. >> >> I also moved all the cryptographic options from an additional advanced cry= ptographic options button into the Advanced Server options button. >> >> I was successful in doing all the above and then tested the ovpnmain.cgi o= ut with a vm using the existing openvpn-2.5.9 version for openvpn. >> >> My old profile for my laptop which had a ciphers entry worked without any = problem. My laptop was working withy openvpn-2.6.6 >> >> I then created a new profile using the new ovpnmain.cgi using the negotiat= ion option which ended up with a data-ciphers line. That also worked in makin= g a successful openvpn tunnel with my laptop without any issues. >> >> I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.= 1.1 to make that work. >> >> With that client version on my laptop both the old and new profiles connec= ted with a tunnel with no problems. >> >> 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 wi= lling to do as that is very old and very insecure. >> >> The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is ne= arly 7 years old. >=20 > I think that it is an acceptable baseline to only support OpenVPN 2.4 and u= p. That is already a lot more than we actually need to do, and we would suppo= rt clients that are probably vulnerable to many things=E2=80=A6 If we need to= drop support for OpenVPN 2.4 in this process, that might also be acceptable. >=20 > What is *not* so acceptable is that the client configuration file has to be= changed in order to keep working with newer clients, because that would requ= ire that admins update every single configuration file if the client software= is being updated. And that can be a nightmare with hundreds of connections. From Erik's input and my understanding and my experiments there will be no n= eed for any client configuration to be done as an immediate consequence of th= e changes I am working on. If the users are using openvpn-2.4 up then the negotiation from the openvpn s= erver will work even if the client has BF-CBC specified as a cipher. I have p= roven this with openvpn-2.4.0 on my laptop with a connection profile using BF= -CBC and the connection was made with AES-GCM. The users will however need to take the opportunity of the migration approach= with this openvpn work to update the clients from BF-CBC on a one by one bas= is. This needs to be done for when the change to openvpn-2.7 occurs because t= hat version branch will no longer recognise those old 64 bit ciphers at all. I can understand the concern if all client connections had to be updated in a= big bang situation but with the changes being worked on in this openvpn cgi = code the users will be able to update each client as they have time. This set= of changes provides the migration opportunity for a one by one client update= and still maintaining the non-updated client connections. >=20 > Being on the topic of compatibility, I do believe that it is acceptable tha= t connections that are generated today are only working with clients OpenVPN = >=3D 2.6 if we have to do it. I don't think there is any restriction like that, that will occur. However an= y new client connection that is created will be made with the data-ciphers op= tion and older insecure ciphers will not be able to be selected for new conne= ctions. If a new connection is being created then there will be a new .p12 ce= rtificate as well so the package set will need to be transferred to the clien= t anyway so that restriction should not create a problem. >=20 >> That version also worked with both the old and new laptop profiles. >> >> I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.= 6 version of openvpn. >> >> Both these openvpn versions worked with both the old and new laptop connec= tion profiles with my laptop on version 2.4.0 and on 2.6.6 >> >> All the above was using network manager with its openvpn plugin option on = the laptop for making the openvpn tunnel connections. >> >> As far as I can tell everything is working fine when negotiation is specif= ied on the server. Old profiles that just use the cipher option also work fin= e. Therefore my plan is to only use the negotiation option and not make it se= lectable for older clients. The data-ciphers-fallback option in the server se= ems to be doing its job. >> >> The negotiation option on the server was able to connect to a 2.4.0 client= on my laptop. >> >> According to the OpenVPN wiki on cipher negotiation the data-ciphers-fallb= ack option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need = to be using openssl-1.0.0 then I think if those clients work then fine but no= thing further back. >> >> Overall, I am very happy with what I have succeeded in doing so far. I ach= ieved things much quicker than I had expected. >> >> I will now try and see about creating a profile on a CU 179 based system t= hat uses one of the old insecure ciphers such as Blow Fish and restore that i= nto my evaluation vm and see how that works with my laptop when I have it dow= ngraded to openvpn-2.4.0 >> >> I already know that if the laptop is at openvpn-2.6.6 then it will not acc= ept a blowfish cipher (or another weak cipher such as DES) as that is somethi= ng I tested in the past. >> >> If that also works then my plan will be to take the updated ovpnmain.cgi a= nd split the changes into a new range of patches and then submit them for con= sideration. >=20 > Okay, just to sum this up for me, what will happen is this (in no particula= r order): >=20 > * The cipher option in the configuration file will be removed and changed t= o data-cipher-fallback. That way, we will continue to support older clients a= nd 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 IPsec > * 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. No. The server will have both a data-cipher and a data-fallback-cipher option= line, selected from the WUI. However the server will try for a negotiation first using the ciphers listed = in the data-ciphers list (can be more than one). If the server and client fin= d a cipher that they both have in their list then they will agree on that. On= ly if nothing can be agreed will the server go to the fallback option. Howeve= r it seems that openvpn-2.4.x versions onwards include the AEAD ciphers and t= herefore all my testing even with a client of 2.4.0 resulted in a successful = negotiation of AES-GCM (256 bit) even when the config in the client had ciphe= r BF-CBC specified. >=20 > How do we do all this for N2N connections? Is is safe to just remove the ci= pher option entirely because we assume that all clients perform NCP anyways? I haven't started looking at that yet. I was trying to get to a working proce= ss with RW tested out with old client versions and insecure ciphers. I an jus= t about at that point now so I will start to look at the N2N situation and co= nsequences for existing connections in early November. >=20 > * In the near future (2.7), the fallback option will have to be removed for= all, which will render clients that are OpenVPN <=3D 2.4 unusable. This is p= robably acceptable at this point in time. That is true, but it will also render clients unusable that have not taken th= e opportunity from this openvpn cgi update that is being discussed, to update= the clients from cipher 64_bit_insecure to data-cipher secure as mentioned e= arlier. >=20 > * We will have to deprecate LZO as well. Do your patches include anything a= bout that? No not yet. The cgi update being worked on also works with openvpn-2.5.9, the= current version. We could do the cgi release with the current version of ope= nvpn and after any debugging that is flagged up we could then do an update to= openvpn-2.6.x where x could be anywhere between 0 and 6. I have tested the c= gi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same= way for all three versions. For the LZO situation, the migration path to allow users with compression to = be update on a one by one basis is only available from version 2.6.0 To prevent asking users to make multiple updates of client connections (which= I understand would also be undesirable) then we would need to issue the cgi = update together with an update to at least 2.6.0 and with the LZO changes. I have not yet had the chance to work on those. They will probably come after= the N2N checks and evaluation with the changes have been completed. I will also need to do testing of any changes of the LZO with my setup and th= at is not something I have evaluated to date. Regards, Adolf. >=20 >> That will probably end up later in November as I will be busy with persona= l things at the end of October / beginning of November. >> >> >> Regards, >> >> Adolf. >> >=20 > -Michael >=20 --===============5469555845479471572==--