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: Sun, 15 Oct 2023 11:45:12 +0100 Message-ID: <05165F55-966E-43F8-8D64-AC831F583B07@ipfire.org> In-Reply-To: <40021d48-0f18-4f26-adbd-fbeb3da6c814@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5212112803506908997==" List-Id: --===============5212112803506908997== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 14 Oct 2023, at 15:17, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 14/10/2023 14:11, Michael Tremer wrote: >> Hello, >>=20 >>> On 12 Oct 2023, at 06:56, ummeegge wrote: >>>=20 >>> Good morning Adolf, >>>=20 >>> Am Mittwoch, dem 11.10.2023 um 17:53 +0200 schrieb Adolf Belka: >>>> Hi Erik, >>>>=20 >>>>=20 >>>> On 11/10/2023 16:20, ummeegge wrote: >>>>> Hi Adolf, >>>>>=20 >>>>> Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka: >>>>>> 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-fallback selection box. >>>>> Have disabled all the 64 bit block cipher in my previouse patches >>>>> since >>>>> the cipher negotiaton managed the whole thing. I think AEAD ciphers >>>>> are >>>>> since OpenSSL-1.0.1 available so if AES-GCM is available in --data- >>>>> ciphers, the clients will use them even BF-CBC is set in >>>>> client.ovpn . >>>>> We have had a conversation about this also with some tests which >>>>> you >>>>> can find in here --> >>>>> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3 >>>> Thanks for the feedback and the link to our conversation at the >>>> beginning of this year. >>>>=20 >>>> So even if the user has BF-CBC set in the client.ovpn, with the >>>> server >>>> having server negotiation in this update then the client will end up >>>> getting connected with an available cipher from the data-ciphers >>>> list. >>>> I will do a test of that then on my system >>>>=20 >>>> If my understanding is correct, then why do we need to still leave >>>> the >>>> weak ciphers in the data-fallback list. Those could also be removed, >>>> they are blocked anyway. >>> As mentioned, have removed all 64-Bit block Ciphers and left the 128- >>> Bit CBC ones in the 'Data-Channel fallback' list to prevent warnings >>> from the OpenVPN logs. You can find in the same above linked topic a >>> respective message which points out to this configuration by using the >>> 'data-cipher fallback' directive. So even if Blowfish, the variations >>> of DES and CAST5 are out of the list, AES-CBC is still there and can >>> therefor prevent warnings in the logs via '--data-ciphers-fallback' if >>> AES-CBC is used on client.ovpn. >>>=20 >>>> OpenVPN plan to remove those weak ciphers completely in version 2.7 >>>> If a user at that time still had a client with say BF-CBC would the >>>> negotiation still work then or would it fail because OpenVPN no >>>> longer >>>> recognises the old weak cipher? >>> This is true according to the OpenVPN 'Deprecated Option' wiki --> >>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migra= teawayfromdeprecatedciphers.Status:Inprogress >>> that=C2=B4s causes, beneath the OpenSSL-3.x decision, to leave the >>> deprecated ciphers out of the Roadwarrior list (N2N is another thing >>> since it do no understands cipher negotiation) but pushed at that time >>> an idea to bring on some warnings for the users before the IPFire >>> decision to leave the broken ciphers out of any list since the server >>> can not see what client configuration is in place. >>> This patch can be found in here --> >>> https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;h= =3Ddd11f42776f1b60660f4e862d6e847e746b9411b >> This patch looks good to me. >>=20 >> We just need to tame down the warning message a little bit :) >=20 > This message is in my changes and it also needs to make more clear that eve= n though the OpenVPN server can't be started with that cipher selected for th= e fallback, the client with one of those ciphers can still be connected via n= egotiation. Or we add the legacy provider :) > I still need to think how to word that in a concise way that doesn't take h= alf the screen up. It might not be the shortest, but we need to account for some space anyways b= ecause the German version will never ever be short :) -Michael >=20 > Regards, >=20 > Adolf. >=20 >=20 >>>> Regards, >>>>=20 >>>> Adolf. >>> Best, >>>=20 >>> Erik >>>=20 >>>>>> Then pressed Start OpenVPN Server and nothing happened. Checked >>>>>> the >>>>>> logs and 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 still making progress. >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>> Best, >>>>>=20 >>>>> Erik >>>>>> 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 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 >>>>>>> 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 >>>>>>> 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. --===============5212112803506908997==--