Hi Michael,
On 15/10/2023 12:44, Michael Tremer wrote:
Hello Adolf,
On 14 Oct 2023, at 15:12, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 14/10/2023 14:08, Michael Tremer wrote:
Hello Adolf, We should already have the legacy option enabled by default on the server and client side in some cases. Potentially, we need to add a list of ciphers that require it and then add the same flag again. https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=7dec360355f0eb5bb9bc... Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy() one and then check both?!
I did add in some code to add providers legacy default into the server conf file if one of the insecure ciphers was selected, ie enabling the server to be started with an insecure cipher.
From feedback from Erik and further thinking myself, I reverted from this. If the cipher is able to be enabled then a new connection could be created with that old insecure cipher specified in the data-fallback option. I don't think this is a good approach and also, from my testing, not required.
Correct me if I didn’t understand this correctly, but I thought the there might be some corner cases where we would run into this:
Don't worry. It has taken me a while reading the openvpn reference manual on some of these options and some feedback from Erik to get to a point where I think I am starting to understand what is happening.
Let’s assume that someone has been using BF-CBC (a legacy cipher) and we now upgrade to the new way. Then we would have BF-CBC as fallback cipher and a couple of other ones for NCP. Wouldn’t that require the legacy setting for OpenSSL allowing us to use BF?
The client configuration should no longer have the BF (and therefore legacy) setting because we are creating it for modern clients. Older clients that have imported an old configuration might still be using the “cipher” setting and we want to support those for a little bit longer.
The corner case is if the user has clients with openvpn-2.3 or older. With openvpn-2.4 onwards cipher negotiation is available.
When a connection is made from an old cipher, the first approach from the server will be to do a negotiation. That can occur even if BF-CBC as an example is explicitly in the client connection. openvpn-2.4 onwards can still negotiate a more modern cipher and the ones that can be used in openvpn-2.4 are in the data-ciphers section of the new cgi. Basically the strongest common cipher will be taken and in all my tests that ended up being AES-GCM.
If the user has client with openvpn-2.3 then negotiation will fail and that is when the server will then use the data-cipher-fallback. To be using openvpn-2.3 as a client then the user would also have to have openssl-1.0.x installed because I tried to test openvpn-2.3.14 I got the message that it was looking for a specific library version libssl.so.1.0.0 which I believe comes with openssl-1.0.1x
So if we also want to still support users using openvpn-2.3 and using openssl-1.0.1x on their clients then we would need to make the 64 bit ciphers selectable in the data-ciphers-fallback table by adding providers legacy default into the server config file - but only for those 64 bit insecure ciphers. Then we would need to hope that there are not people who would then create new connections using the 64 bit ciphers but who knows what people can do if they have clients still running with openssl-1.0.1x which had the last version released in 2016 and is no longer supported.
If the user has clients with openvpn-2.2 then the openvpn page has written "All bets are off - Upgrade now!"
My preference would have been to remove completely the insecure ciphers from the data-fallback option as the negotiation works with openvpn-2.4.0 and a client with a BF-CBC cipher specified.
It does, but in my example from above we need it to support all those sins from the past and give people some time and technical options to move away from them...
In an earlier email you said that you were happy to say that we only support back to clients with openvpn-2.4 but if we now say that we also support back to clients with openvpn-2.3 then yes we will need to allow the selection of the 64 bit ciphers in the server for data-cipher-fallback and have providers legacy default added to the server config file if one of the 64 bit ciphers has been selected for the data-cipher-fallback and then keep our fingers crossed that no one creates new client connections with those old ciphers.
The big crunch will come when opoenvpn-2.7 comes because there will be no fallback option from then on so if users have not updated their client configs with a newer cipher and updated their openvpn client versions then we will reach a decision point.
We either move to openvpn-2.7 and those users who have not updated their clients, in the time between now and when we decide to go to 2.7, will not be able to update IPFire without breaking their connections
or we stay for ever at version 2.6.x
The only reason for having the ciphers in the data fallback section is as Erik mentioned that this tells the user that they have a client(s) that need to have their connection profiles progressively updated to a modern cipher. The same message would be seen in the logs but as Erik mentioned, too many of the users won't look in the logs.
Yes, but we don’t quite know what that number is. I agree that it is *very* small, because clients have been using NCP for a long time, even with IPFire. But it is quite likely not zero, as there might be clients that are too old to support NCP, yet.
So what do we do to make the path smoother? Introduce the new options, deprecate the old ones, let people know about the deprecation, and then finally phase it out. In our case, people might be able to do this themselves by simply removing the fallback cipher, so they know for certain that they are out of the woods with all of this.
So in the end my cgi changes have not re-enabled any of the insecure ciphers in the data fallback table but they are still visible there.
I wouldn’t insist, but I feel that it might be easier to just make them all available for a couple of months and then remove the whole thing entirely. But I am happy to be shown another way :)
To protect that very small (but maybe not zero), number of users with clients on openvpn-2.3 that does not support NCP then we would need to make them available. We will just then have to think about how we decide that things are better after the couple of months to make the change. I am not sure we will know if those few users without NCP actually exist or not without stopping the use of the 64 bit data-cipher-fallback.
The only problem situation I could see is a user who does not know that their client(s) have insecure ciphers and selects or accepts the default data-fallback option of AES-CBC but the client has BF-CBC or one of the other insecure ciphers specified in the client config.
Maybe that user has inherited a set of client connections that were created by someone else and as long as they work they don't look any further.
In that case that user will get no warning that their clients have an insecure cipher except for the log messages. Those might have a problem then when openvpn is updated to 2.7 because they might not have updated their clients because they didn't know about the insecure ciphers being used.
My working assumption is, that most clients are at least on >= 2.4, and therefore don’t use the cipher setting any more - even though it is there. That means that we are dealing with a very small fraction of clients. Let me know if you disagree with this assumption.
That is also my assumption. The cipher setting will have been used up to current status as we have the ncp-disable option in our server config currently with openvpn-2.5.9 With this cgi change to using NCP then the cipher option will no longer be used, even though it is in the client config because the negotiation will supersede it.
Regards, Adolf.
-Michael
Regards, Adolf.
-Michael
On 9 Oct 2023, at 18:26, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
I thought it was too good to be true.
Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.
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.
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.