From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Thu, 19 Oct 2023 10:07:43 +0200 Message-ID: <9619ba035a382f7d02f0475b956746dc53a5e46f.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7301808345730146660==" List-Id: --===============7301808345730146660== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, Am Mittwoch, dem 18.10.2023 um 19:48 +0100 schrieb Michael Tremer: > Hello, >=20 > > 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/= ovpnmain.cgi;h=3Deb89c5095569ccd691772a4fb9f314ecd3fd1257;hb=3Drefs/heads/nex= t#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=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. >=20 > Ah okay, I think I overlooked the aspect here that the default comes > even for the client. >=20 > It is potentially a bad design choice then that the protocol cannot > rekey without reauthentication. >=20 > We could try to push this from the server side maybe? That would at > least indicate some SHOULD value. If the client does not honour it, > we cannot do anything about that. >=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=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=C2=A0. 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 > >=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/ > > . >=20 > That is a correct statement. >=20 > >=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= -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? We tried to debug this from community side since a lot of users reported problems to configure 2FA for their systems whereby for some others it worked. You can find in here --> https://community.ipfire.org/t/two-openvpn-problems-2fa-support-and-perfect-f= orward-security-disabled/9502/17 a community conversation but a bugzilla entry is also available -->=20 https://bugzilla.ipfire.org/show_bug.cgi?id=3D13097 >=20 > > >=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 -- > > > =C2=A0 > > > https://openvpn.net/community-resources/reference-manual-for-openv > > > pn-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#Po= licy:Migrateawayfromdeprecatedciphers.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=C2=A0 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=3D= commit;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 --===============7301808345730146660==--