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: Sat, 14 Oct 2023 16:17:10 +0200 Message-ID: <40021d48-0f18-4f26-adbd-fbeb3da6c814@ipfire.org> In-Reply-To: <9BE18A06-33F1-461F-97EE-44CF3DC66C88@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1508073209330897212==" List-Id: --===============1508073209330897212== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 14/10/2023 14:11, Michael Tremer wrote: > Hello, > >> On 12 Oct 2023, at 06:56, ummeegge wrote: >> >> Good morning Adolf, >> >> Am Mittwoch, dem 11.10.2023 um 17:53 +0200 schrieb Adolf Belka: >>> Hi Erik, >>> >>> >>> On 11/10/2023 16:20, ummeegge wrote: >>>> Hi Adolf, >>>> >>>> Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka: >>>>> Hi All, >>>>> >>>>> I thought it was too good to be true. >>>>> >>>>> 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. >>> >>> 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 >>> >>> 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. >> >>> 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:Migrat= eawayfromdeprecatedciphers.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=3D= dd11f42776f1b60660f4e862d6e847e746b9411b > This patch looks good to me. > > We just need to tame down the warning message a little bit :) This message is in my changes and it also needs to make more clear that even = though the OpenVPN server can't be started with that cipher selected for the = fallback, the client with one of those ciphers can still be connected via neg= otiation. I still need to think how to word that in a concise way that doesn't take hal= f the screen up. Regards, Adolf. >>> Regards, >>> >>> Adolf. >> Best, >> >> Erik >> >>>>> Then pressed Start OpenVPN Server and nothing happened. Checked >>>>> the >>>>> logs and there is the openssl error >>>>> >>>>> OpenSSL: error:0308010C:digital envelope routines::unsupported >>>>> >>>>> 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 >>>>> >>>>> providers legacy default >>>>> >>>>> to be included, rather than the client conf file. >>>>> >>>>> Still it does feel like two steps forward and one backwards so >>>>> overall still making progress. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>> Best, >>>> >>>> Erik >>>>> On 09/10/2023 14: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. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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 changes based on previous discussions with Michael. >>>>>> >>>>>> So I have removed the b2sum options that were present for the >>>>>> Data >>>>>> and Channel Authentication. >>>>>> >>>>>> I also moved all the cryptographic options from an additional >>>>>> advanced cryptographic 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 >>>>>> 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. >>>>>> >>>>>> 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 >>>>>> connected with a tunnel with no problems. >>>>>> >>>>>> 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. >>>>>> >>>>>> The oldest openvpn version working with openssl-1.1.1 is 2.4.0 >>>>>> which is nearly 7 years old. >>>>>> >>>>>> 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 >>>>>> connection 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 >>>>>> 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. >>>>>> >>>>>> The negotiation option on the server was able to connect to a >>>>>> 2.4.0 >>>>>> client on my laptop. >>>>>> >>>>>> 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. >>>>>> >>>>>> Overall, I am very happy with what I have succeeded in doing so >>>>>> far. I achieved 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 downgraded to openvpn-2.4.0 >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> That will probably end up later in November as I will be busy >>>>>> with >>>>>> personal things at the end of October / beginning of November. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Adolf. > --===============1508073209330897212==--