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: Mon, 16 Oct 2023 11:05:43 +0100 Message-ID: <2E0BC987-2230-4CE5-8510-16B2CAD77C78@ipfire.org> In-Reply-To: <60ba3189-d498-4064-b8d5-f4011ccd0cdf@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2954068872876321421==" List-Id: --===============2954068872876321421== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 15 Oct 2023, at 14:43, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 14/10/2023 15:57, Adolf Belka wrote: >> Hi Michael, >>=20 >> 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 urg= ent things that were tying me in, but I was happy to see that we are finally = making some progress on OpenVPN=E2=80=A6 >>>=20 >>>> 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 previous patches as my starting point. >>>=20 >>> Could you please push those changes to a Git repository for review? Or di= d that happen already and I just was too blind to find them... >>=20 >> No, I have been working on them on my vm on my desktop system as there has= been a lot of coming and going as I worked on understanding various things. = What I have now is different from what I started with. >>=20 >> I will try and push the changes to my git repository but currently it is j= ust a single set of changes. I have not yet started to break the changes into= sections to have a commit patch against them yet. >>=20 > I have pushed the changes as a single diff into my IPFire repo. >=20 > https://git.ipfire.org/?p=3Dpeople/bonnietwin/ipfire-2.x.git;a=3Dcommit;h= =3D4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035 Thanks for pushing this. It is good to have something visual and a backup, ju= st in case :) > At the moment it is still a single set of all changes as that way I could u= nderstand the whole picture and the bits that I was changing. I still need to= add the LZO stuff plus other changes based on our email discussion in the la= st few days. >=20 > When that is all done and we are generally agreed on the approach then I wi= ll split all the changes into separate chunks to go in separate patches of a = patch set. >=20 > With the diff in my git repo you can apply that and see the changes and sim= plifications that I have made so far before our email discussions. Yes, this looks alright so far. I am not sure who wrote this, but you can use more lines. They are free :) print SERVERCONF "proto tcp4-server\n"; - print SERVERCONF "# Packet size\n"; + print SERVERCONF "# Packet size\n";&writeserverconf();#hier ok if ($cgiparams{'MTU'} eq '') {$tunmtu =3D '1400'} else {$tunmtu =3D $cgi This is hard to read :) =E2=80=94 And=E2=80=A6 do we need to put the data ciphers into the client configuration= ? Isn=E2=80=99t it enough if the server tells the client what to use? That al= lows changing the cipher later on without touching the client configuration a= gain - this is the massive advantage of NCP, isn=E2=80=99t it? -Michael >=20 >=20 > Regards, >=20 > Adolf. >=20 >>>=20 >>>> My first attempt to try and be able to understand the changes from each = patch 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 patches to it. >>>>=20 >>>> Then I have gone through that new version of ovpnmain.cgi and made the c= hanges based on previous discussions with Michael. >>>>=20 >>>> So I have removed the b2sum options that were present for the Data and C= hannel Authentication. >>>>=20 >>>> I also moved all the cryptographic options from an additional advanced c= ryptographic options button into the Advanced Server options button. >>>>=20 >>>> I was successful in doing all the above and then tested the ovpnmain.cgi= out 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 an= y problem. My laptop was working withy openvpn-2.6.6 >>>>=20 >>>> I then created a new profile using the new ovpnmain.cgi using the negoti= ation option which ended up with a data-ciphers line. That also worked in mak= ing 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 conn= ected with a tunnel with no problems. >>>>=20 >>>> I then tried downgrading my laptop to openvpn-2.3.14 but to make this wo= rk I would have had to downgrade the laptop to openssl-1.0.0 which I was not = willing 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 = nearly 7 years old. >>>=20 >>> 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 sup= port 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 acceptabl= e. >>>=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 re= quire that admins update every single configuration file if the client softwa= re is being updated. And that can be a nightmare with hundreds of connections. >>=20 >> From Erik's input and my understanding and my experiments there will be no= need for any client configuration to be done as an immediate consequence of = the changes I am working on. >>=20 >> If the users are using openvpn-2.4 up then the negotiation from the openvp= n server will work even if the client has BF-CBC specified as a cipher. I hav= e proven this with openvpn-2.4.0 on my laptop with a connection profile using= BF-CBC and the connection was made with AES-GCM. >>=20 >> The users will however need to take the opportunity of the migration appro= ach with this openvpn work to update the clients from BF-CBC on a one by one = basis. This needs to be done for when the change to openvpn-2.7 occurs becaus= e that version branch will no longer recognise those old 64 bit ciphers at al= l. >>=20 >> I can understand the concern if all client connections had to be updated i= n a big bang situation but with the changes being worked on in this openvpn c= gi 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 upd= ate and still maintaining the non-updated client connections. >>>=20 >>> Being on the topic of compatibility, I do believe that it is acceptable t= hat connections that are generated today are only working with clients OpenVP= N >=3D 2.6 if we have to do it. >>=20 >> I don't think there is any restriction like that, that will occur. However= any new client connection that is created will be made with the data-ciphers= option and older insecure ciphers will not be able to be selected for new co= nnections. If a new connection is being created then there will be a new .p12= certificate as well so the package set will need to be transferred to the cl= ient anyway so that restriction should not create a problem. >>>=20 >>>> 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 conn= ection 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 o= n the laptop for making the openvpn tunnel connections. >>>>=20 >>>> As far as I can tell everything is working fine when negotiation is spec= ified on the server. Old profiles that just use the cipher option also work f= ine. Therefore my plan is to only use the negotiation option and not make it = selectable for older clients. The data-ciphers-fallback option in the server = seems to be doing its job. >>>>=20 >>>> The negotiation option on the server was able to connect to a 2.4.0 clie= nt on my laptop. >>>>=20 >>>> According to the OpenVPN wiki on cipher negotiation the data-ciphers-fal= lback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients nee= d to be using openssl-1.0.0 then I think if those clients work then fine but = nothing further back. >>>>=20 >>>> Overall, I am very happy with what I have succeeded in doing so far. I a= chieved things much quicker than I had expected. >>>>=20 >>>> I will now try and see about creating a profile on a CU 179 based system= that uses one of the old insecure ciphers such as Blow Fish and restore that= into my evaluation vm and see how that works with my laptop when I have it d= owngraded to openvpn-2.4.0 >>>>=20 >>>> I already know that if the laptop is at openvpn-2.6.6 then it will not a= ccept a blowfish cipher (or another weak cipher such as DES) as that is somet= hing I tested in the past. >>>>=20 >>>> If that also works then my plan will be to take the updated ovpnmain.cgi= and split the changes into a new range of patches and then submit them for c= onsideration. >>>=20 >>> Okay, just to sum this up for me, what will happen is this (in no particu= lar order): >>>=20 >>> * 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 ca= n select ciphers to use in =E2=80=9Cdata-ciphers=E2=80=9D very similarly to h= ow 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 c= lients to OpenVPN >=3D 2.4 (which should already have happened anyways) and t= hey should use NCP only (i.e. no data-cipher-fallback option in the server co= nfiguration file any more). This will also be the new default. >>=20 >> No. The server will have both a data-cipher and a data-fallback-cipher opt= ion line, selected from the WUI. >>=20 >> However the server will try for a negotiation first using the ciphers list= ed in the data-ciphers list (can be more than one). If the server and client = find a cipher that they both have in their list then they will agree on that.= Only if nothing can be agreed will the server go to the fallback option. How= ever it seems that openvpn-2.4.x versions onwards include the AEAD ciphers an= d therefore all my testing even with a client of 2.4.0 resulted in a successf= ul negotiation of AES-GCM (256 bit) even when the config in the client had ci= pher BF-CBC specified. >>=20 >>>=20 >>> How do we do all this for N2N connections? Is is safe to just remove the = cipher option entirely because we assume that all clients perform NCP anyways? >>=20 >> I haven't started looking at that yet. I was trying to get to a working pr= ocess with RW tested out with old client versions and insecure ciphers. I an = just about at that point now so I will start to look at the N2N situation and= consequences for existing connections in early November. >>=20 >>>=20 >>> * In the near future (2.7), the fallback option will have to be removed f= or all, which will render clients that are OpenVPN <=3D 2.4 unusable. This is= probably acceptable at this point in time. >>=20 >> That is true, but it will also render clients unusable that have not taken= the opportunity from this openvpn cgi update that is being discussed, to upd= ate the clients from cipher 64_bit_insecure to data-cipher secure as mentione= d earlier. >>=20 >>>=20 >>> * We will have to deprecate LZO as well. Do your patches include anything= about that? >>=20 >> 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 = openvpn 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 th= e cgi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the s= ame way for all three versions. >>=20 >> 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 >>=20 >> To prevent asking users to make multiple updates of client connections (wh= ich I understand would also be undesirable) then we would need to issue the c= gi update together with an update to at least 2.6.0 and with the LZO changes. >>=20 >> I have not yet had the chance to work on those. They will probably come af= ter 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= that is not something I have evaluated to date. >>=20 >>=20 >> Regards, >> Adolf. >>=20 >>>=20 >>>> That will probably end up later in November as I will be busy with perso= nal things at the end of October / beginning of November. >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>=20 >>> -Michael --===============2954068872876321421==--