Hello Adolf and all,
Am Donnerstag, dem 19.10.2023 um 12:28 +0200 schrieb Adolf Belka:
Hi,
On 19/10/2023 10:02, ummeegge wrote:
Hi all,
Am Mittwoch, dem 18.10.2023 um 21:39 +0200 schrieb Adolf Belka:
Hi all,
On 18/10/2023 20:48, Michael Tremer wrote:
Hello,
On 18 Oct 2023, at 10:05, ummeegge ummeegge@ipfire.org 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=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... > 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.
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 without reauthentication.
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.
I disagree that this will not work as I have tested it and it worked.
This statement above was according the server have not the capabilities to trigger different reneg-sec values via CCD or push option for different clients. If the server is e.g. configured with 'reneg-sec 0' (disabled) you can configure all clients with different values that´s no problem but i would say more then 90% of all IPFire Roadwarriors out there does not have a reneg-sec configuration in client.ovpn cause it was simply not given by the server before 2FA so they use the time values from the server. To change the client configuration afterwards are only possible from user side so we run in the same problems to communicate this but also stresses admins with several hundreds may thousands of clients.
Looking at the ref manual on the reneg-sec, I get the impression that if the client does not have reneg-sec defined then the default value is applied.
If this is the case then I would expect that the client would renegotiate first as the default reneg-sec value is 3600 secs, even if the server has 86400 secs set. Some clients look like they defined reneg-secs to 0 by default, such as network-manager with the openvpn plugin, so those would take the server value.
I haven't tested the above with a client with no reneg-sec defined and see if the renegotiation takes place at an hour or not. I will try and find some time to do this later.
You are right that users that have large numbers of clients won't want to go and change all their client settings, if they have reneg-sec defined already at 0 or if the client as standard turns off reneg-sec by setting at 0 but if their clients are working okay then there will be no requirement to make them change their client.
My suggestion for the change to reneg-sec was for all new connections made. All existing connections would continue running as they have been.
Adolf.
Have checked it here also an you are right. If client.ovpn does not have an reneg-sec entry but the server does have 'reneg-sec 86400', the negotiation will happen after 3600 seconds (OpenVPNs default from client side) so, it will never comes to the given key renogitation after 86400 seconds provided by the server which is equal to the current configuration in IPFire cause if 2FA has been choosen, only the server uses "print CONF "reneg-sec 86400\n";" but the client.ovpn does not so that´s why different users in the community gives advice to modify client.ovpn e.g. --> https://community.ipfire.org/t/otp-authentication/9992/6 .
But in general, i think we should take this problem (2FA) to a different mailinglist topic ? Since there are multiple problems according to 2FA as far as i can see whereby NCP integration is already comprehensive enough ?
Best,
Erik
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 used for OTP connection.
So server with 86400 client set to 86400 This should result in renegotiation somewhere between 77760 secs (90% 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 have not found an openvpn client that I use that works with OTP.
Regards,
Adolf.
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%C2%A0. But if '--reneg-*' has been configured the internal OpenVPN defaults won´t be used.
I am not aware that anyone has ever reported that they need to re- enter the OTP after hitting a certain amount of data.
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.
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´t 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.
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-us... (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´s 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?
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:Migratea... > > 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´s 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=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427... > > 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.