Hello everyone,
Apologies for my late response on this. The last week had a couple of urgent things that were tying me in, but I was happy to see that we are finally making some progress on OpenVPN…
On 9 Oct 2023, at 13:05, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.
Could you please push those changes to a Git repository for review? Or did that happen already and I just was too blind to find them...
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.
I think that it is an acceptable baseline to only support OpenVPN 2.4 and up. That is already a lot more than we actually need to do, and we would support clients that are probably vulnerable to many things… If we need to drop support for OpenVPN 2.4 in this process, that might also be acceptable.
What is *not* so acceptable is that the client configuration file has to be changed in order to keep working with newer clients, because that would require that admins update every single configuration file if the client software is being updated. And that can be a nightmare with hundreds of connections.
Being on the topic of compatibility, I do believe that it is acceptable that connections that are generated today are only working with clients OpenVPN >= 2.6 if we have to do it.
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.
Okay, just to sum this up for me, what will happen is this (in no particular order):
* The cipher option in the configuration file will be removed and changed to data-cipher-fallback. That way, we will continue to support older clients and new ones will use NCP. * There will be a new UI element where people can select ciphers to use in “data-ciphers” very similarly to how to select a cipher for IPsec * There will be a deprecation warning for people who use an older (64 bit) “CIPHER” and they will be encouraged to upgrade all their clients to OpenVPN >= 2.4 (which should already have happened anyways) and they should use NCP only (i.e. no data-cipher-fallback option in the server configuration file any more). This will also be the new default.
How do we do all this for N2N connections? Is is safe to just remove the cipher option entirely because we assume that all clients perform NCP anyways?
* In the near future (2.7), the fallback option will have to be removed for all, which will render clients that are OpenVPN <= 2.4 unusable. This is probably acceptable at this point in time.
* We will have to deprecate LZO as well. Do your patches include anything about that?
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.
-Michael