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: Sun, 15 Oct 2023 15:43:56 +0200 Message-ID: <60ba3189-d498-4064-b8d5-f4011ccd0cdf@ipfire.org> In-Reply-To: <418a6116-2047-4e86-b737-0462f3e39311@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6790651298917142827==" List-Id: --===============6790651298917142827== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 14/10/2023 15:57, Adolf Belka wrote: > Hi Michael, > > On 14/10/2023 14:05, Michael Tremer wrote: >> Hello everyone, >> >> Apologies for my late response on this. The last week had a couple of urge= nt things that were tying me in, but I was happy to see that we are finally m= aking some progress on OpenVPN=E2=80=A6 >> >>> 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. >> >> 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 = been a lot of coming and going as I worked on understanding various things. W= hat 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 ju= st a single set of changes. I have not yet started to break the changes into = sections to have a commit patch against them yet. > I have pushed the changes as a single diff into my IPFire repo. https://git.ipfire.org/?p=3Dpeople/bonnietwin/ipfire-2.x.git;a=3Dcommit;h=3D4= fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035 At the moment it is still a single set of all changes as that way I could und= erstand the whole picture and the bits that I was changing. I still need to a= dd the LZO stuff plus other changes based on our email discussion in the last= few days. When that is all done and we are generally agreed on the approach then I will= split all the changes into separate chunks to go in separate patches of a pa= tch set. With the diff in my git repo you can apply that and see the changes and simpl= ifications that I have made so far before our email discussions. Regards, Adolf. >> >>> My first attempt to try and be able to understand the changes from each p= atch 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 ch= anges based on previous discussions with Michael. >>> >>> So I have removed the b2sum options that were present for the Data and Ch= annel Authentication. >>> >>> I also moved all the cryptographic options from an additional advanced cr= yptographic options button into the Advanced Server options button. >>> >>> 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. >>> >>> 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 negotia= tion option which ended up with a data-ciphers line. That also worked in maki= ng 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 conne= cted with a tunnel with no problems. >>> >>> I then tried downgrading my laptop to openvpn-2.3.14 but to make this wor= k I would have had to downgrade the laptop to openssl-1.0.0 which I was not w= illing 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 n= early 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 supp= ort clients that are probably vulnerable to many things=E2=80=A6 If we need t= o drop 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 b= e changed in order to keep working with newer clients, because that would req= uire that admins update every single configuration file if the client softwar= e 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 = need for any client configuration to be done as an immediate consequence of t= he changes I am working on. > > If the users are using openvpn-2.4 up then the negotiation from the openvpn= server will work even if the client has BF-CBC specified as a cipher. I have= 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. > > The users will however need to take the opportunity of the migration approa= ch with this openvpn work to update the clients from BF-CBC on a one by one b= asis. This needs to be done for when the change to openvpn-2.7 occurs because= that 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 cg= i code the users will be able to update each client as they have time. This s= et of changes provides the migration opportunity for a one by one client upda= te and still maintaining the non-updated client connections. >> >> Being on the topic of compatibility, I do believe that it is acceptable th= at 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 = 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 con= nections. 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 cli= ent anyway so that restriction should not create a problem. >> >>> 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 conne= ction 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 speci= fied on the server. Old profiles that just use the cipher option also work fi= ne. Therefore my plan is to only use the negotiation option and not make it s= electable for older clients. The data-ciphers-fallback option in the server s= eems to be doing its job. >>> >>> The negotiation option on the server was able to connect to a 2.4.0 clien= t on my laptop. >>> >>> According to the OpenVPN wiki on cipher negotiation the data-ciphers-fall= back 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 n= othing further back. >>> >>> Overall, I am very happy with what I have succeeded in doing so far. I ac= hieved things much quicker than I had expected. >>> >>> 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 do= wngraded to openvpn-2.4.0 >>> >>> I already know that if the laptop is at openvpn-2.6.6 then it will not ac= cept a blowfish cipher (or another weak cipher such as DES) as that is someth= ing I tested in the past. >>> >>> 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 co= nsideration. >> >> Okay, just to sum this up for me, what will happen is this (in no particul= ar 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 ho= w 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 cl= ients to OpenVPN >=3D 2.4 (which should already have happened anyways) and th= ey should use NCP only (i.e. no data-cipher-fallback option in the server con= figuration file any more). This will also be the new default. > > No. The server will have both a data-cipher and a data-fallback-cipher opti= on line, selected from the WUI. > > However the server will try for a negotiation first using the ciphers liste= d in the data-ciphers list (can be more than one). If the server and client f= ind 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. Howe= ver it seems that openvpn-2.4.x versions onwards include the AEAD ciphers and= therefore all my testing even with a client of 2.4.0 resulted in a successfu= l negotiation of AES-GCM (256 bit) even when the config in the client had cip= her BF-CBC specified. > >> >> How do we do all this for N2N connections? Is is safe to just remove the c= ipher 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 pro= cess with RW tested out with old client versions and insecure ciphers. I an j= ust about at that point now so I will start to look at the N2N situation and = consequences for existing connections in early November. > >> >> * In the near future (2.7), the fallback option will have to be removed fo= r all, which will render clients that are OpenVPN <=3D 2.4 unusable. This is = probably acceptable at this point in time. > > 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 upda= te the clients from cipher 64_bit_insecure to data-cipher secure as mentioned= earlier. > >> >> * We will have to deprecate LZO as well. Do your patches include anything = about that? > > No not yet. The cgi update being worked on also works with openvpn-2.5.9, t= he current version. We could do the cgi release with the current version of o= penvpn 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= cgi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the sa= me way for all three versions. > > For the LZO situation, the migration path to allow users with compression t= o 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 (whi= ch I understand would also be undesirable) then we would need to issue the cg= i 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 aft= er 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. > > > Regards, > Adolf. > >> >>> That will probably end up later in November as I will be busy with person= al things at the end of October / beginning of November. >>> >>> >>> Regards, >>> >>> Adolf. >>> >> >> -Michael >> --===============6790651298917142827==--