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: Wed, 18 Oct 2023 21:39:06 +0200 Message-ID: <4404942f-0308-4b48-b8b2-dac321d0dec4@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0286674192939192777==" List-Id: --===============0286674192939192777== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, On 18/10/2023 20:48, Michael Tremer wrote: > Hello, >=20 >> On 18 Oct 2023, at 10:05, ummeegge wrote: >> >> Hi all, >> >> Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka: >>> 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/ovp= nmain.cgi;h=3Deb89c5095569ccd691772a4fb9f314ecd3fd1257;hb=3Drefs/heads/next#l= 368 >>>> 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. >> 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. >=20 > Ah okay, I think I overlooked the aspect here that the default comes even f= or the client. >=20 > It is potentially a bad design choice then that the protocol cannot rekey w= ithout reauthentication. >=20 > We could try to push this from the server side maybe? That would at least i= ndicate some SHOULD value. If the client does not honour it, we cannot do any= thing about that. I disagree that this will not work as I have tested it and it worked. I had a standard system with the server set to 86400 secs. I then added into the client profile for my laptop reneg-sec 30. So server with 86400 client with 30 Result the server renegotiated every 30 secs. I had the reneg occur 5 times. This is what is wanted. Alternative would be another client with reneg-sec set to 86400 to be=20 used for OTP connection. So server with 86400 client set to 86400 This should result in renegotiation somewhere between 77760 secs (90%=20 86400 secs) and 86400 secs, randomly selected. I didn't test this as I didn't have a spare 48 hours to test and also I=20 have not found an openvpn client that I use that works with OTP. Regards, Adolf. >=20 >>> 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 >>> the one in both ends. >> Yes, and the counter starts then from the beginning. >> >>> >>> I have tested this out on my laptop with a direct openvpn cli >>> connection >>> and via the network manager openvpn plugin and also on my android >>> phone >>> via the OpenVPN for Android app. >>> >>> In all three cases I added reneg-sec 30 to the .ovpn profile and then >>> installed 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. >> 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. >=20 > I am not aware that anyone has ever reported that they need to re-enter the= OTP after hitting a certain amount of data. >=20 > If so, we need to disable this for OTP-enabled clients. The rationale would= be that because we have stronger authentication, we can afford to have fewer= rekeys - which I personally disagree with. >=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 >>> the server and for clients without the OTP checked they can have a >>> 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/ >> . >=20 > That is a correct statement. >=20 >> >>> >>> It could already be that in some cases this is happening anyway as >>> the >>> default value for reneg-sec if not specified is 3600 so it depends >>> what >>> the clients are doing with that default value. I would need to run a >>> 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 >>> 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-= usage >> (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! >=20 > Why not? >=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 >>> 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. >> >>> >>> Regards, >>> Adolf. >>>> >>>> Best, >>>> >>>> Erik >> >> 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:M= igrateawayfromdeprecatedciphers.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 >=20 --=20 Sent from my laptop --===============0286674192939192777==--