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:20:42 +0100 Message-ID: In-Reply-To: <415351cd-7f88-4722-b43d-c300a383d8ef@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3311384445974309183==" List-Id: --===============3311384445974309183== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Oh it looks you had the same idea that I had :) Very nice :) > On 13 Oct 2023, at 13:52, Adolf Belka wrote: >=20 > Hi Erik, >=20 > 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/ovpnm= ain.cgi;h=3Deb89c5095569ccd691772a4fb9f314ecd3fd1257;hb=3Drefs/heads/next#l368 >> 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 with= and without OTP would have to make a choice between one or the other. >=20 > I have looked through the OpenVPN info on reneg-sec and found that it can b= e specified on both the server but also on each client and for a specific cli= ent the timer that will time out first is the lower value of the one in both = ends. >=20 > I have tested this out on my laptop with a direct openvpn cli connection an= d via the network manager openvpn plugin and also on my android phone via the= OpenVPN for Android app. >=20 > In all three cases I added reneg-sec 30 to the .ovpn profile and then insta= lled it. >=20 > I then was able to successfully make a connection and every 30 secs I saw i= n the logs that the connection was renegotiated in all three cases. >=20 > So the current server value can be left as it is and for clients with the O= TP option checked they can have the same reneg-sec as currently in the server= and for clients without the OTP checked they can have a reneg-sec value of o= ne hour, which will trigger before the server value. >=20 > It could already be that in some cases this is happening anyway as the defa= ult value for reneg-sec if not specified is 3600 so it depends what the clien= ts are doing with that default value. I would need to run a test with the thr= ee above options where I leave the systems connected via OpenVPN and see what= happens after one hour (the default value for reneg-sec) but I am not sure w= hen I will have time for that. >=20 > I think it will be good to explicitly specify the reneg-sec on both OTP and= non-OTP clients so that the default value doesn't cause unexpected consequen= ces. >=20 > Regards, > Adolf. >> Best, >> Erik >> Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka: >>> Hi Erik, >>>=20 >>> 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 -- >>>>>>=20 >>>>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Mig= rateawayfromdeprecatedciphers.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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Regards, >>> Adolf. >>>>>> 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. >>>>>>>>>=20 >>>=20 >=20 > --=20 > Sent from my laptop --===============3311384445974309183==--