From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Wed, 18 Oct 2023 11:29:20 +0200 Message-ID: <56b577107574a7987daa832e8665fd4fc9e403f6.camel@ipfire.org> In-Reply-To: <60ba3189-d498-4064-b8d5-f4011ccd0cdf@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4527624013762660077==" List-Id: --===============4527624013762660077== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Adolf, Am Sonntag, dem 15.10.2023 um 15:43 +0200 schrieb Adolf Belka: > 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 urgent 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 did 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 just 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 As far as i can see, isn=C2=B4t this not the old code from my previouse patches ? The BLAKE algorithm for the HMACs has been reverted and some plausibility checks and some configuration logic has been reformated (tabs instead of dot=C2=B4s) or have i overlooked something ? >=20 > At the moment it is still a single set of all changes as that way I > could understand 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 last few days. >=20 > 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 patch set. >=20 > With the diff in my git repo you can apply that and see the changes > and simplifications that I have made so far before our email > discussions. >=20 >=20 > Regards, >=20 > Adolf. Best, Erik >=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 changes based on previous discussions with Michael. > > > >=20 > > > > So I have removed the b2sum options that were present for the > > > > Data and Channel Authentication. > > > >=20 > > > > I also moved all the cryptographic options from an additional > > > > advanced cryptographic 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 any problem. My laptop was working withy openvpn-2.6.6 > > > >=20 > > > > I then created a new profile using the new ovpnmain.cgi using > > > > the negotiation 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 connected 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 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 support 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 require that admins update every single > > > configuration file if the client software 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 > > 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. > >=20 > > 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 basis. 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. > >=20 > > 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 that connections that are generated today are only > > > working with clients OpenVPN >=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 connections. 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 client 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 connection 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 the laptop for making the openvpn tunnel connections. > > > >=20 > > > > As far as I can tell everything is working fine when > > > > negotiation is specified 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 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 client on my laptop. > > > >=20 > > > > According to the OpenVPN wiki on cipher negotiation the data- > > > > ciphers-fallback 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 nothing further back. > > > >=20 > > > > Overall, I am very happy with what I have succeeded in doing so > > > > far. I achieved 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 downgraded to openvpn- > > > > 2.4.0 > > > >=20 > > > > I already know that if the laptop is at openvpn-2.6.6 then it > > > > will not accept a blowfish cipher (or another weak cipher such > > > > as DES) as that is something 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 consideration. > > >=20 > > > Okay, just to sum this up for me, what will happen is this (in no > > > particular 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 can select ciphers to use in =E2=80=9Cdat= a- > > > 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 upgrad= e all > > > their clients to OpenVPN >=3D 2.4 (which should already have > > > happened anyways) and they should use NCP only (i.e. no data- > > > cipher-fallback option in the server configuration 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 option line, selected from the WUI. > >=20 > > 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 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. However 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 > > successful negotiation of AES-GCM (256 bit) even when the config in > > the client had cipher 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 process 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 for 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 update the clients from cipher 64_bit_insecure > > to data-cipher secure as mentioned 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 the cgi changes with > > openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same 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 (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. > >=20 > > 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 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 personal things at the end of October / beginning of > > > > November. > > > >=20 > > > >=20 > > > > Regards, > > > >=20 > > > > Adolf. > > > >=20 > > >=20 > > > -Michael > > >=20 --===============4527624013762660077==--