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:08:29 +0100 Message-ID: In-Reply-To: <6c851037-58d6-45c9-99a1-0ee5f6074aa8@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0937036786669384255==" List-Id: --===============0937036786669384255== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, We should already have the legacy option enabled by default on the server and= client side in some cases. Potentially, we need to add a list of ciphers that require it and then add th= e same flag again. https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D7dec360355f0e= b5bb9bc61b32a08e733aa070b40 Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy() one = and then check both?! -Michael > On 9 Oct 2023, at 18:26, Adolf Belka wrote: >=20 > Hi All, >=20 > I thought it was too good to be true. >=20 > Before creating a client connection with something like BlowFish I thought = I would just test the server settings with selecting BF in the data-ciphers-f= allback selection box. >=20 > Then pressed Start OpenVPN Server and nothing happened. Checked the logs an= d there is the openssl error >=20 > OpenSSL: error:0308010C:digital envelope routines::unsupported >=20 > which occurs because Openssl-3.x doesn't support the older ciphers like BF = unless legacy is selected. In this case I think it is the OpenVPN server conf= file that requires the >=20 > providers legacy default >=20 > to be included, rather than the client conf file. >=20 > Still it does feel like two steps forward and one backwards so overall stil= l making progress. >=20 >=20 > Regards, >=20 > Adolf. >=20 >=20 > On 09/10/2023 14:05, Adolf Belka wrote: >> 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 >> 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. >>=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 cha= nges based on previous discussions with Michael. >>=20 >> So I have removed the b2sum options that were present for the Data and Cha= nnel Authentication. >>=20 >> I also moved all the cryptographic options from an additional advanced cry= ptographic options button into the Advanced Server options button. >>=20 >> 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. >>=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 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. >>=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 connec= ted 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 wi= lling 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 ne= arly 7 years old. >>=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 connec= tion 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 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. >>=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-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. >>=20 >> Overall, I am very happy with what I have succeeded in doing so far. I ach= ieved things much quicker than I had expected. >>=20 >> 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 >>=20 >> 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. >>=20 >> 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 >> 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. >>=20 >>=20 >> Regards, >>=20 >> Adolf. >>=20 --===============0937036786669384255==--