From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Thu, 19 Oct 2023 12:37:26 +0200 Message-ID: <3365a581-b449-4372-ac12-108e5f43d017@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1928686103063664129==" List-Id: --===============1928686103063664129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 16/10/2023 12:02, Michael Tremer wrote: > Hello, >=20 >> On 15 Oct 2023, at 13:43, Adolf Belka wrote: >> >> Hi Michael, >> >> On 15/10/2023 12:44, Michael Tremer wrote: >>> Hello Adolf, >>>> On 14 Oct 2023, at 15:12, Adolf Belka 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 serv= er 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=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D7dec36= 0355f0eb5bb9bc61b32a08e733aa070b40 >>>>> 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 c= onf 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 th= is. If the cipher is able to be enabled then a new connection could be create= d 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 req= uired. >>> Correct me if I didn=E2=80=99t understand this correctly, but I thought t= he 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=E2=80=99s 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 cip= her and a couple of other ones for NCP. Wouldn=E2=80=99t that require the leg= acy setting for OpenSSL allowing us to use BF? >>> The client configuration should no longer have the BF (and therefore lega= cy) setting because we are creating it for modern clients. Older clients that= have imported an old configuration might still be using the =E2=80=9Ccipher= =E2=80=9D 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 examp= le is explicitly in the client connection. openvpn-2.4 onwards can still nego= tiate a more modern cipher and the ones that can be used in openvpn-2.4 are i= n the data-ciphers section of the new cgi. Basically the strongest common cip= her 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 tha= t 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 mess= age 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 open= ssl-1.0.1x on their clients then we would need to make the 64 bit ciphers sel= ectable 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 versi= on released in 2016 and is no longer supported. >=20 > Yes, this is what I have assumed as well. There might be one extra case whe= re people with OpenVPN >=3D 2.4 have manually disabled the cipher negotiation= . We don=E2=80=99t ship that in our client configuration, but it might have b= een manually enabled by the user. So therefore I think that we should support= all currently supported ciphers as a fallback cipher and then deprecate the = whole thing to get people upgraded to NCP as soon as possible. But when peopl= e install the Core Update, existing setups have to remain working without any= thing, because otherwise we break people=E2=80=99s setups. And that is sad. >=20 >> If the user has clients with openvpn-2.2 then the openvpn page has written= "All bets are off - Upgrade now!" >=20 > Yes, even 2.3 is something that we shouldn=E2=80=99t really support any mor= e as it is so old. But there will be a few poor souls who still have to run s= ome Windows XP somewhere because their company is using this really old softw= are for this really big and expensive machine and the vendor doesn=E2=80=99t = give a shit about software support and you know the rest of those stories... >=20 >>>> 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 sin= s 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 suppo= rt back to clients with openvpn-2.4 but if we now say that we also support ba= ck to clients with openvpn-2.3 then yes we will need to allow the selection o= f the 64 bit ciphers in the server for data-cipher-fallback and have provider= s 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 cro= ssed that no one creates new client connections with those old ciphers. >=20 > I would like to support as many client versions that we can. Because why no= t? But if things become complicated and we have to invest a lot of work into = something that only a very small fraction of our users are using, then it is = not worth our time. That being said, I think that it wouldn=E2=80=99t hurt us= to have a drop down with all ciphers that we put into the configuration file= as a fallback cipher. That is all we need as far as I understand to support = those clients (2.3 and 2.4 without NCP). >=20 > This allows us to spend more time on the next step. Step one would be to ro= ll out NCP and make it configurable. We don=E2=80=99t have that yet. For all = clients to remain working we need the fallback cipher option. And to not make= that all too complicated we should just support all ciphers that we can - in= cluding lecacy ones. If people rely on this, the clock has started for them t= o upgrade anyways=E2=80=A6 >=20 > Step two would then be to remove the whole fallback thing again so that eve= ryone is on NCP. There might also be more things like LZO and others that are= more or less independent... The LZO command change is independent in terms of the commands involved=20 but it can't be independent from the NCP change because after the=20 compression migration has been put in place in ovpnmain.cgi then the=20 users will need to update their clients before compression is completely=20 removed from openvpn. We don't want users having to update all their clients for the weak=20 ciphers and then at a later time having to do it again to remove=20 compression. It seems to make sense to me to combine the NCP weak ciphers migration=20 and compression migration into the same change so we ask users to update=20 clients that need to be with both changes in one go. >=20 >> 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 config= s with a newer cipher and updated their openvpn client versions then we will = reach a decision point. >=20 > Yes, so let=E2=80=99s remove the fallback option with the upgrade to 2.7 at= the latest. >=20 > I suppose the bigger fish to fry here is the networking/routing changes. >=20 >> We either move to openvpn-2.7 and those users who have not updated their c= lients, 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 >=20 > But before that happens they will have several months. The faster we are no= w with getting step one done, the longer this timeframe is going to be. >=20 >> or we stay for ever at version 2.6.x >=20 > That isn=E2=80=99t an option long term. We do not have to go to 2.7 on its = release day, but we cannot ship 2.6 after it has become EOL. >=20 >>>> The only reason for having the ciphers in the data fallback section is a= s Erik mentioned that this tells the user that they have a client(s) that nee= d 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 o= f the users won't look in the logs. >>> Yes, but we don=E2=80=99t quite know what that number is. I agree that it= is *very* small, because clients have been using NCP for a long time, even w= ith IPFire. But it is quite likely not zero, as there might be clients that a= re too old to support NCP, yet. >>> So what do we do to make the path smoother? Introduce the new options, de= precate 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 sim= ply 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 cip= hers in the data fallback table but they are still visible there. >>> I wouldn=E2=80=99t insist, but I feel that it might be easier to just mak= e them all available for a couple of months and then remove the whole thing e= ntirely. But I am happy to be shown another way :) >> >> To protect that very small (but maybe not zero), number of users with clie= nts 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 ar= e 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 t= he use of the 64 bit data-cipher-fallback. >=20 > They will have to figure this out themselves I would say :) We cannot do th= e entire job for them. >=20 > It would be kind of cool if we could capture the client version when they c= onnect to tell the admin which client versions are being used, but that is pr= obably too complicated and not worth it with such a low expected number of to= tal clients. And in practical terms, it is possible for an admin out there to= fix a few clients after an update, but it simply doesn=E2=80=99t work if the= y would have to fix hundreds on the same Monday morning. >=20 >>>> 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 ins= ecure ciphers specified in the client config. >>>> >>>> Maybe that user has inherited a set of client connections that were crea= ted 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 in= secure cipher except for the log messages. Those might have a problem then wh= en openvpn is updated to 2.7 because they might not have updated their client= s because they didn't know about the insecure ciphers being used. >>> My working assumption is, that most clients are at least on >=3D 2.4, and= therefore don=E2=80=99t 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 c= urrent status as we have the ncp-disable option in our server config currentl= y with openvpn-2.5.9 >=20 > What? Shit, I was looking for that and couldn't find it. My memory told me = as well that we had this somewhere. Well this changes things slightly, but no= t a lot. >=20 >> 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 su= persede it. >=20 > Maybe then I misunderstood you slightly, because with NCP, I would not want= to make any legacy ciphers available. This should be a list of ciphers that = is current as of today. The fallback cipher list should include the legacy on= es. Just in case I wasn=E2=80=99t able to bring this difference across :) >=20 > -Michael >=20 >> >> Regards, >> Adolf. >> >>> -Michael >>>> >>>> Regards, >>>> Adolf. >>>> >>>>> -Michael >>>>>> On 9 Oct 2023, at 18:26, Adolf Belka wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> I thought it was too good to be true. >>>>>> >>>>>> Before creating a client connection with something like BlowFish I tho= ught I would just test the server settings with selecting BF in the data-ciph= ers-fallback selection box. >>>>>> >>>>>> Then pressed Start OpenVPN Server and nothing happened. Checked the lo= gs 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 lik= e 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 Er= ik's previous patches as my starting point. >>>>>>> >>>>>>> My first attempt to try and be able to understand the changes from ea= ch patch to figure out what I needed to do proved difficult for me to work wi= th. >>>>>>> >>>>>>> What I then did was take the current ovpnmain.cgi and apply all of Er= ik's patches to it. >>>>>>> >>>>>>> Then I have gone through that new version of ovpnmain.cgi and made th= e changes based on previous discussions with Michael. >>>>>>> >>>>>>> So I have removed the b2sum options that were present for the Data an= d Channel Authentication. >>>>>>> >>>>>>> I also moved all the cryptographic options from an additional advance= d 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 neg= otiation 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 openv= pn-1.1.1 to make that work. >>>>>>> >>>>>>> With that client version on my laptop both the old and new profiles c= onnected 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 n= ot 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 c= onnection 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 optio= n on the laptop for making the openvpn tunnel connections. >>>>>>> >>>>>>> As far as I can tell everything is working fine when negotiation is s= pecified on the server. Old profiles that just use the cipher option also wor= k 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 serv= er seems to be doing its job. >>>>>>> >>>>>>> The negotiation option on the server was able to connect to a 2.4.0 c= lient 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 b= ut 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 sys= tem that uses one of the old insecure ciphers such as Blow Fish and restore t= hat into my evaluation vm and see how that works with my laptop when I have i= t downgraded to openvpn-2.4.0 >>>>>>> >>>>>>> I already know that if the laptop is at openvpn-2.6.6 then it will no= t accept a blowfish cipher (or another weak cipher such as DES) as that is so= mething 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 fo= r consideration. >>>>>>> >>>>>>> That will probably end up later in November as I will be busy with pe= rsonal things at the end of October / beginning of November. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Adolf. >=20 >=20 --=20 Sent from my laptop --===============1928686103063664129==--