Hello Adolf,
Am Mittwoch, dem 18.10.2023 um 11:55 +0200 schrieb Adolf Belka:
Hi Erik,
On 18/10/2023 11:29, ummeegge wrote:
Hi Adolf,
Am Sonntag, dem 15.10.2023 um 15:43 +0200 schrieb Adolf Belka:
Hi Michael,
On 14/10/2023 15:57, Adolf Belka wrote:
Hi Michael,
On 14/10/2023 14:05, Michael Tremer wrote:
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...
No, I have been working on them on my vm on my desktop system as there has been a lot of coming and going as I worked on understanding various things. What I have now is different from what I started with.
I will try and push the changes to my git repository but currently it is just a single set of changes. I have not yet started to break the changes into sections to have a commit patch against them yet.
I have pushed the changes as a single diff into my IPFire repo.
https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=commit;h=4fbf17...
As far as i can see, isn´t this not the old code from my previouse patches ? The BLAKE algorithm for the HMACs has been reverted and some plausibility checks and some configuration logic has been reformated (tabs instead of dot´s) or have i overlooked something ?
Yes, the start basis was your patches. I made that clear at the start of this email communication on the status.
I don't have the capability to start anew and that definitely didn't seem sensible when you had already done the work initially.
True and good to see that you go this way.
I removed the BLAKE options and the tls-crypt v2 as these seemed to give too many options to people to start with. The tls-crypt gives an improved option for people creating new connections.
We can always add these in later on but the options here seemed to be less the critical item as compared to the move to ncp and preparing for total removal of 64 bit ciphers in openvpn-2.7
Totally agree with.
I also removed all the options for the ciphers for the control channel. There were no defaults and in that case openvpn makes the choice and seems to choose the best capable option. In my case a tls-1.3 was always chosen.
The openvpn ref manual says the following about those ciphers
" WARNING: --tls-ciphers, --tls-ciphersuites and tls-groups These options are expert features, which - if used correctly - can improve the security of your VPN connection. But it is also easy to unwittingly use them to carefully align a gun with your foot, or just break your connection. Use with care! "
This indicates that experts can use them well but for non-experts they could be dangerous. Therefore I removed them as options and experts can always add them in as options into their client specific config additions.
This makes the WUI also more readable with a better overview in my opinion but even if more options would by time come in there might be ways to bring on a better overview but this is future sound...
This way openvpn will choose the best option for people and that seemed a good situation to be in.
I also moved all the advanced encryption into the advanced server section. This was something that Michael preferred and it also seems sensible to me as then by default a user can just set the global settings and everything else could run with the default settings which would give a good secure system, also good for the future.
Sound is good and i did it also in the same way in the Gitlab repo where i sended you a link at that time may you remember. Have also reopened it since there are some other stuff meanwhile in but also not updated in the last time. The Gitlab repo does includes also a wiki (which was the reason to open it up for this topic) for explaining all the commits. If you want to go over it to get may some more infos, you can find it here --> https://gitlab.com/ummeegge/openvpn-2.5.x/-/wikis/Explanation-of-the-OpenVPN...
I did make some formatting changes but I intend to revert those as in the diff they don't appear to have given the result I was expecting.
The diff is not completed yet but a work in progress and still needs additions for the compression migration path for those users who have selected LZO in the past.
OK, are you planning to use the '--compress migrate' option ?
Also the whole diff will then need to be split up into separate patches. I didn't stay with you patch subdivision because I had difficulty trying to follow all the separate changes and understand how to make the changes I was planning. Therefore I applied your whole change set and then have been editing that version with my changes I was able to more easily understand and follow the file with all changes applied to it. That was just my capability limitations.
Great. The above linked wiki includes also links to the patches, screenshots and further explanations, some of them are already merged in IPFire e.g. the 'Finite_field_DH-parameter'. Even the ovpnmain.cgi in there is outdated, it might be may useful.
Regards, Adolf.
Best,
Erik
At the moment it is still a single set of all changes as that way I could understand the whole picture and the bits that I was changing. I still need to add the LZO stuff plus other changes based on our email discussion in the last few days.
When that is all done and we are generally agreed on the approach then I will split all the changes into separate chunks to go in separate patches of a patch set.
With the diff in my git repo you can apply that and see the changes and simplifications that I have made so far before our email discussions.
Regards,
Adolf.
Best,
Erik
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.
From Erik's input and my understanding and my experiments there will be no need for any client configuration to be done as an immediate consequence of the changes I am working on.
If the users are using openvpn-2.4 up then the negotiation from the openvpn server will work even if the client has BF-CBC specified as a cipher. I have proven this with openvpn-2.4.0 on my laptop with a connection profile using BF-CBC and the connection was made with AES-GCM.
The users will however need to take the opportunity of the migration approach with this openvpn work to update the clients from BF-CBC on a one by one basis. This needs to be done for when the change to openvpn-2.7 occurs because that version branch will no longer recognise those old 64 bit ciphers at all.
I can understand the concern if all client connections had to be updated in a big bang situation but with the changes being worked on in this openvpn cgi code the users will be able to update each client as they have time. This set of changes provides the migration opportunity for a one by one client update and still maintaining the non-updated client 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.
I don't think there is any restriction like that, that will occur. However any new client connection that is created will be made with the data-ciphers option and older insecure ciphers will not be able to be selected for new connections. If a new connection is being created then there will be a new .p12 certificate as well so the package set will need to be transferred to the client anyway so that restriction should not create a problem.
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.
No. The server will have both a data-cipher and a data- fallback- cipher option line, selected from the WUI.
However the server will try for a negotiation first using the ciphers listed in the data-ciphers list (can be more than one). If the server and client find a cipher that they both have in their list then they will agree on that. Only if nothing can be agreed will the server go to the fallback option. However it seems that openvpn-2.4.x versions onwards include the AEAD ciphers and therefore all my testing even with a client of 2.4.0 resulted in a successful negotiation of AES-GCM (256 bit) even when the config in the client had cipher BF-CBC specified.
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?
I haven't started looking at that yet. I was trying to get to a working process with RW tested out with old client versions and insecure ciphers. I an just about at that point now so I will start to look at the N2N situation and consequences for existing connections in early November.
- 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.
That is true, but it will also render clients unusable that have not taken the opportunity from this openvpn cgi update that is being discussed, to update the clients from cipher 64_bit_insecure to data-cipher secure as mentioned earlier.
- We will have to deprecate LZO as well. Do your patches
include anything about that?
No not yet. The cgi update being worked on also works with openvpn- 2.5.9, the current version. We could do the cgi release with the current version of openvpn and after any debugging that is flagged up we could then do an update to openvpn-2.6.x where x could be anywhere between 0 and 6. I have tested the cgi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same way for all three versions.
For the LZO situation, the migration path to allow users with compression to be update on a one by one basis is only available from version 2.6.0
To prevent asking users to make multiple updates of client connections (which I understand would also be undesirable) then we would need to issue the cgi update together with an update to at least 2.6.0 and with the LZO changes.
I have not yet had the chance to work on those. They will probably come after the N2N checks and evaluation with the changes have been completed. I will also need to do testing of any changes of the LZO with my setup and that is not something I have evaluated to date.
Regards, Adolf.
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