From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Mon, 16 Oct 2023 11:02:11 +0100 Message-ID: In-Reply-To: <2b133a12-6899-40a6-b5c1-a6469207aade@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5676680313945487276==" List-Id: --===============5676680313945487276== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 15 Oct 2023, at 13:43, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 15/10/2023 12:44, Michael Tremer wrote: >> Hello Adolf, >>> On 14 Oct 2023, at 15:12, Adolf Belka wrote: >>>=20 >>> Hi Michael, >>>=20 >>>=20 >>> On 14/10/2023 14:08, Michael Tremer wrote: >>>> Hello Adolf, >>>> We should already have the legacy option enabled by default on the serve= r and client side in some cases. >>>> Potentially, we need to add a list of ciphers that require it and then a= dd the same flag again. >>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D7dec3603= 55f0eb5bb9bc61b32a08e733aa070b40 >>>> Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy()= one and then check both?! >>>=20 >>> I did add in some code to add providers legacy default into the server co= nf file if one of the insecure ciphers was selected, ie enabling the server t= o be started with an insecure cipher. >>>=20 >>> 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 requ= ired. >> Correct me if I didn=E2=80=99t understand this correctly, but I thought th= e there might be some corner cases where we would run into this: >=20 > Don't worry. It has taken me a while reading the openvpn reference manual o= n 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. >=20 >> 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 ciph= er and a couple of other ones for NCP. Wouldn=E2=80=99t that require the lega= cy setting for OpenSSL allowing us to use BF? >> The client configuration should no longer have the BF (and therefore legac= y) 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. >=20 > The corner case is if the user has clients with openvpn-2.3 or older. With = openvpn-2.4 onwards cipher negotiation is available. >=20 > When a connection is made from an old cipher, the first approach from the s= erver will be to do a negotiation. That can occur even if BF-CBC as an exampl= e is explicitly in the client connection. openvpn-2.4 onwards can still negot= iate 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 ciph= er will be taken and in all my tests that ended up being AES-GCM. >=20 > 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 o= penssl-1.0.x installed because I tried to test openvpn-2.3.14 I got the messa= ge that it was looking for a specific library version libssl.so.1.0.0 which I= believe comes with openssl-1.0.1x >=20 > So if we also want to still support users using openvpn-2.3 and using opens= sl-1.0.1x on their clients then we would need to make the 64 bit ciphers sele= ctable 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 versio= n released in 2016 and is no longer supported. Yes, this is what I have assumed as well. There might be one extra case where= 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 bee= n manually enabled by the user. So therefore I think that we should support a= ll currently supported ciphers as a fallback cipher and then deprecate the wh= ole thing to get people upgraded to NCP as soon as possible. But when people = install the Core Update, existing setups have to remain working without anyth= ing, because otherwise we break people=E2=80=99s setups. And that is sad. > If the user has clients with openvpn-2.2 then the openvpn page has written = "All bets are off - Upgrade now!" Yes, even 2.3 is something that we shouldn=E2=80=99t really support any more = as it is so old. But there will be a few poor souls who still have to run som= e Windows XP somewhere because their company is using this really old softwar= e for this really big and expensive machine and the vendor doesn=E2=80=99t gi= ve a shit about software support and you know the rest of those stories... >>> My preference would have been to remove completely the insecure ciphers f= rom 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 f= rom them... >=20 > In an earlier email you said that you were happy to say that we only suppor= t back to clients with openvpn-2.4 but if we now say that we also support bac= k 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 cros= sed that no one creates new client connections with those old ciphers. I would like to support as many client versions that we can. Because why not?= But if things become complicated and we have to invest a lot of work into so= mething that only a very small fraction of our users are using, then it is no= t worth our time. That being said, I think that it wouldn=E2=80=99t hurt us t= o have a drop down with all ciphers that we put into the configuration file a= s a fallback cipher. That is all we need as far as I understand to support th= ose clients (2.3 and 2.4 without NCP). This allows us to spend more time on the next step. Step one would be to roll= out NCP and make it configurable. We don=E2=80=99t have that yet. For all cl= ients to remain working we need the fallback cipher option. And to not make t= hat all too complicated we should just support all ciphers that we can - incl= uding lecacy ones. If people rely on this, the clock has started for them to = upgrade anyways=E2=80=A6 Step two would then be to remove the whole fallback thing again so that every= one is on NCP. There might also be more things like LZO and others that are m= ore or less independent... > The big crunch will come when opoenvpn-2.7 comes because there will be no f= allback 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 r= each a decision point. Yes, so let=E2=80=99s remove the fallback option with the upgrade to 2.7 at t= he latest. I suppose the bigger fish to fry here is the networking/routing changes. > We either move to openvpn-2.7 and those users who have not updated their cl= ients, in the time between now and when we decide to go to 2.7, will not be a= ble to update IPFire without breaking their connections But before that happens they will have several months. The faster we are now = with getting step one done, the longer this timeframe is going to be. > or we stay for ever at version 2.6.x That isn=E2=80=99t an option long term. We do not have to go to 2.7 on its re= lease day, but we cannot ship 2.6 after it has become EOL. >>> 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=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 wi= th IPFire. But it is quite likely not zero, as there might be clients that ar= e too old to support NCP, yet. >> So what do we do to make the path smoother? Introduce the new options, dep= recate 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 simp= ly removing the fallback cipher, so they know for certain that they are out o= f the woods with all of this. >>> So in the end my cgi changes have not re-enabled any of the insecure ciph= ers 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 make= them all available for a couple of months and then remove the whole thing en= tirely. But I am happy to be shown another way :) >=20 > To protect that very small (but maybe not zero), number of users with clien= ts on openvpn-2.3 that does not support NCP then we would need to make them a= vailable. 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 th= e use of the 64 bit data-cipher-fallback. They will have to figure this out themselves I would say :) We cannot do the = entire job for them. It would be kind of cool if we could capture the client version when they con= nect to tell the admin which client versions are being used, but that is prob= ably too complicated and not worth it with such a low expected number of tota= l clients. And in practical terms, it is possible for an admin out there to f= ix a few clients after an update, but it simply doesn=E2=80=99t work if they = would have to fix hundreds on the same Monday morning. >>> The only problem situation I could see is a user who does not know that t= heir 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 inse= cure ciphers specified in the client config. >>>=20 >>> Maybe that user has inherited a set of client connections that were creat= ed by someone else and as long as they work they don't look any further. >>>=20 >>> In that case that user will get no warning that their clients have an ins= ecure cipher except for the log messages. Those might have a problem then whe= n 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 >=3D 2.4, and = therefore don=E2=80=99t use the cipher setting any more - even though it is t= here. That means that we are dealing with a very small fraction of clients. L= et me know if you disagree with this assumption. >=20 > That is also my assumption. The cipher setting will have been used up to cu= rrent status as we have the ncp-disable option in our server config currently= with openvpn-2.5.9 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 not = a lot. > 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 sup= ersede it. Maybe then I misunderstood you slightly, because with NCP, I would not want t= o 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 ones= . Just in case I wasn=E2=80=99t able to bring this difference across :) -Michael >=20 > Regards, > Adolf. >=20 >> -Michael >>>=20 >>> Regards, >>> Adolf. >>>=20 >>>> -Michael >>>>> On 9 Oct 2023, at 18:26, Adolf Belka wrote: >>>>>=20 >>>>> Hi All, >>>>>=20 >>>>> I thought it was too good to be true. >>>>>=20 >>>>> Before creating a client connection with something like BlowFish I thou= ght I would just test the server settings with selecting BF in the data-ciphe= rs-fallback selection box. >>>>>=20 >>>>> Then pressed Start OpenVPN Server and nothing happened. Checked the log= s and there is the openssl error >>>>>=20 >>>>> OpenSSL: error:0308010C:digital envelope routines::unsupported >>>>>=20 >>>>> 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 >>>>>=20 >>>>> providers legacy default >>>>>=20 >>>>> to be included, rather than the client conf file. >>>>>=20 >>>>> Still it does feel like two steps forward and one backwards so overall = still making progress. >>>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adolf. >>>>>=20 >>>>>=20 >>>>> On 09/10/2023 14:05, Adolf Belka wrote: >>>>>> Hi All, >>>>>>=20 >>>>>>=20 >>>>>> Over the last week I have been working on the openvpn update using Eri= k's previous patches as my starting point. >>>>>>=20 >>>>>> My first attempt to try and be able to understand the changes from eac= h patch to figure out what I needed to do proved difficult for me to work wit= h. >>>>>>=20 >>>>>> What I then did was take the current ovpnmain.cgi and apply all of Eri= k's patches to it. >>>>>>=20 >>>>>> Then I have gone through that new version of ovpnmain.cgi and made the= changes based on previous discussions with Michael. >>>>>>=20 >>>>>> So I have removed the b2sum options that were present for the Data and= Channel Authentication. >>>>>>=20 >>>>>> I also moved all the cryptographic options from an additional advanced= cryptographic options button into the Advanced Server options button. >>>>>>=20 >>>>>> I was successful in doing all the above and then tested the ovpnmain.c= gi out with a vm using the existing openvpn-2.5.9 version for openvpn. >>>>>>=20 >>>>>> My old profile for my laptop which had a ciphers entry worked without = any problem. My laptop was working withy openvpn-2.6.6 >>>>>>=20 >>>>>> I then created a new profile using the new ovpnmain.cgi using the nego= tiation option which ended up with a data-ciphers line. That also worked in m= aking a successful openvpn tunnel with my laptop without any issues. >>>>>>=20 >>>>>> I then downgraded my laptop to openvpn-2.4.8 and had to install openvp= n-1.1.1 to make that work. >>>>>>=20 >>>>>> With that client version on my laptop both the old and new profiles co= nnected with a tunnel with no problems. >>>>>>=20 >>>>>> 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 no= t willing to do as that is very old and very insecure. >>>>>>=20 >>>>>> The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which i= s nearly 7 years old. >>>>>>=20 >>>>>> That version also worked with both the old and new laptop profiles. >>>>>>=20 >>>>>> I then tested out the openvpn server on my IPFire vm with a 2.6.0 and = 2.6.6 version of openvpn. >>>>>>=20 >>>>>> Both these openvpn versions worked with both the old and new laptop co= nnection profiles with my laptop on version 2.4.0 and on 2.6.6 >>>>>>=20 >>>>>> All the above was using network manager with its openvpn plugin option= on the laptop for making the openvpn tunnel connections. >>>>>>=20 >>>>>> As far as I can tell everything is working fine when negotiation is sp= ecified 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 i= t selectable for older clients. The data-ciphers-fallback option in the serve= r seems to be doing its job. >>>>>>=20 >>>>>> The negotiation option on the server was able to connect to a 2.4.0 cl= ient on my laptop. >>>>>>=20 >>>>>> According to the OpenVPN wiki on cipher negotiation the data-ciphers-f= allback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients n= eed to be using openssl-1.0.0 then I think if those clients work then fine bu= t nothing further back. >>>>>>=20 >>>>>> Overall, I am very happy with what I have succeeded in doing so far. I= achieved things much quicker than I had expected. >>>>>>=20 >>>>>> I will now try and see about creating a profile on a CU 179 based syst= em that uses one of the old insecure ciphers such as Blow Fish and restore th= at into my evaluation vm and see how that works with my laptop when I have it= downgraded to openvpn-2.4.0 >>>>>>=20 >>>>>> 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 som= ething I tested in the past. >>>>>>=20 >>>>>> If that also works then my plan will be to take the updated ovpnmain.c= gi and split the changes into a new range of patches and then submit them for= consideration. >>>>>>=20 >>>>>> That will probably end up later in November as I will be busy with per= sonal things at the end of October / beginning of November. >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. --===============5676680313945487276==--