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 15:15:17 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5478759137729072362==" List-Id: --===============5478759137729072362== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 14/10/2023 14:20, Michael Tremer wrote: > Oh it looks you had the same idea that I had :) Very nice :) I will submit a separate patch on the reneg-sec item as it is independent of = the other openvpn work. Regards, Adolf. >=20 >> On 13 Oct 2023, at 13:52, Adolf Belka wrote: >> >> Hi Erik, >> >> On 12/10/2023 13:30, ummeegge wrote: >>> Your welcome. >>> If you are in state of completing the blog post you can send it again >>> to overread it so we all can speak about it, as an offer from me. >>> I would really also recommend to make the cipher renegotiation >>> configurable via WUI. Since the release of 2FA it has been hardcoded >>> --> >>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dhtml/cgi-bin/ovpn= main.cgi;h=3Deb89c5095569ccd691772a4fb9f314ecd3fd1257;hb=3Drefs/heads/next#l3= 68 >>> to 48 hours which in a practical way or in fact disables the PFS also >>> for users which do not use 2FA whereby the OpenVPN default, also with >>> potential secure ciphers, are configured to 1 hour to renegotiate a new >>> session key. >> The problem with making it configurable from the WUI is that there is only= one value that the server can have so users that have client connections wit= h and without OTP would have to make a choice between one or the other. >> >> I have looked through the OpenVPN info on reneg-sec and found that it can = be specified on both the server but also on each client and for a specific cl= ient the timer that will time out first is the lower value of the one in both= ends. >> >> I have tested this out on my laptop with a direct openvpn cli connection a= nd via the network manager openvpn plugin and also on my android phone via th= e OpenVPN for Android app. >> >> In all three cases I added reneg-sec 30 to the .ovpn profile and then inst= alled it. >> >> I then was able to successfully make a connection and every 30 secs I saw = in the logs that the connection was renegotiated in all three cases. >> >> So the current server value can be left as it is and for clients with the = OTP option checked they can have the same reneg-sec as currently in the serve= r and for clients without the OTP checked they can have a reneg-sec value of = one hour, which will trigger before the server value. >> >> It could already be that in some cases this is happening anyway as the def= ault value for reneg-sec if not specified is 3600 so it depends what the clie= nts are doing with that default value. I would need to run a test with the th= ree above options where I leave the systems connected via OpenVPN and see wha= t happens after one hour (the default value for reneg-sec) but I am not sure = when I will have time for that. >> >> I think it will be good to explicitly specify the reneg-sec on both OTP an= d non-OTP clients so that the default value doesn't cause unexpected conseque= nces. >> >> Regards, >> Adolf. >>> Best, >>> Erik >>> Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka: >>>> Hi Erik, >>>> >>>> On 12/10/2023 08:06, ummeegge wrote: >>>>> Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge: >>>>>>> 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:Mi= grateawayfromdeprecatedciphers.Status:Inprogress >>>> I had seen that overall page before but obviously not read the >>>> details >>>> well enough of that specific entry. The entry makes it clear that >>>> from >>>> openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted >>>> even >>>> as data-fallback ones. >>>>>> 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. >>>>> To correct this statement, mostly users do not see/recognize such >>>>> warnings in the OpenVPN logs, the server does see it! >>>> I see what you are saying. The users tend not to look at their logs >>>> and >>>> so will miss the message about the 64 bit BF-CBC etc being removed >>>> from >>>> 2.7 onwards. >>>> >>>> So having the 64 bit ciphers in the data-fallback table but not >>>> allowing >>>> them to be used and instead giving a warning message about the cipher >>>> being removed in the future is a way to make the changes more visible >>>> that the user needs to do and the potential timing scenario. >>>> >>>> I think I will also need to put together a supporting info blog post >>>> on >>>> the openvpn changes that will come with the IPFire updates being >>>> worked >>>> on and the future ones with openvpn-2.7 >>>>>> This patch can be found in here --> >>>>>> https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;= h=3Ddd11f42776f1b60660f4e862d6e847e746b9411b >>>> Thanks for the clarification. >>>> >>>> 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. >>>>>>>>>> >>>> >> >> --=20 >> Sent from my laptop >=20 >=20 --===============5478759137729072362==--