Hi Michael,
On 14/10/2023 14:20, Michael Tremer wrote:
Oh it looks you had the same idea that I had :) Very nice :)
I will submit a separate patch on the reneg-sec item as it is independent of the other openvpn work.
Regards,
Adolf.
On 13 Oct 2023, at 13:52, Adolf Belka adolf.belka@ipfire.org wrote:
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.
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.
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.
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.
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.
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.
Regards, Adolf.
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. >>>>
-- Sent from my laptop