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: Wed, 18 Oct 2023 19:48:10 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2307194220570557298==" List-Id: --===============2307194220570557298== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 18 Oct 2023, at 10:05, ummeegge wrote: >=20 > Hi all, >=20 > Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka: >> 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. >>>=20 >>> 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=20 >> connections with and without OTP would have to make a choice between >> one=20 >> or the other. > Client and server can have different '--reneg-sec' values but it makes > no sense to configure it in such way since the earlier value triggers > the renegotiation of the session key and will never reach the later one > cause it starts then again with 0. Ah okay, I think I overlooked the aspect here that the default comes even for= the client. It is potentially a bad design choice then that the protocol cannot rekey wit= hout reauthentication. We could try to push this from the server side maybe? That would at least ind= icate some SHOULD value. If the client does not honour it, we cannot do anyth= ing about that. >> 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 client the timer that will time out first is the lower value >> of=20 >> the one in both ends. > Yes, and the counter starts then from the beginning. >=20 >>=20 >> I have tested this out on my laptop with a direct openvpn cli >> connection=20 >> and via the network manager openvpn plugin and also on my android >> phone=20 >> via the OpenVPN for Android app. >>=20 >> In all three cases I added reneg-sec 30 to the .ovpn profile and then >> installed it. >>=20 >> 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. > It can also be used with pkts [n] and bytes [n] which OpenVPN is using > if 64 bit block ciphers are configured and renegotiates after 64 MB of > transfered data. This was the consequences after the SWEET32 birthday > attacks --> https://sweet32.info . But if '--reneg-*' has been > configured the internal OpenVPN defaults won=C2=B4t be used. I am not aware that anyone has ever reported that they need to re-enter the O= TP after hitting a certain amount of data. If so, we need to disable this for OTP-enabled clients. The rationale would b= e that because we have stronger authentication, we can afford to have fewer r= ekeys - which I personally disagree with. >=20 >>=20 >> 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=20 >> the server and for clients without the OTP checked they can have a=20 >> reneg-sec value of one hour, which will trigger before the server >> value. > I think this won=C2=B4t work since whichever (server or client) uses the > lower value will be the one who triggers the renegotiation and the > counter starts then by 0 again. So this is a kind of a global setting > and can not be triggered ealier for some and ater for others in my > opinion --> > https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ > . That is a correct statement. >=20 >>=20 >> It could already be that in some cases this is happening anyway as >> the=20 >> default value for reneg-sec if not specified is 3600 so it depends >> what=20 >> the clients are doing with that default value. I would need to run a=20 >> test with the three above options where I leave the systems connected >> via OpenVPN and see what happens after one hour (the default value >> for=20 >> reneg-sec) but I am not sure when I will have time for that. > Adolf, i would test also the '--auth-(gen-)token' directive --> > https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md#auth-token-u= sage > (very old discussion!) may this can be a solution to bypass the whole > reneg-sec discussion around 2FA and leave the server to 3600 sec=C2=B4s or > make it even configuerable cause 2FA users uses it, i think, for mostly > clients. > I can not test this sinec 2FA on IPFire never works for me! Why not? >>=20 >> I think it will be good to explicitly specify the reneg-sec on both >> OTP=20 >> and non-OTP clients so that the default value doesn't cause >> unexpected=20 >> consequences. > Please check also the OpenVPN manpage -- >> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ > in section "Data Channel Renegotiation" according the above questions > and potential testing scenarios. >=20 >>=20 >> Regards, >> Adolf. >>>=20 >>> Best, >>>=20 >>> Erik >=20 > Best, >=20 > Erik >=20 >>>=20 >>> 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: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. >>>>=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. --===============2307194220570557298==--