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: Sun, 15 Oct 2023 14:43:45 +0200 Message-ID: <2b133a12-6899-40a6-b5c1-a6469207aade@ipfire.org> In-Reply-To: <62C24BF8-BA2D-45D1-9710-408CB5A54AC2@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1667401317032571091==" List-Id: --===============1667401317032571091== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 15/10/2023 12:44, Michael Tremer wrote: > Hello Adolf, >=20 >> 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 server= and client side in some cases. >>> Potentially, we need to add a list of ciphers that require it and then ad= d 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?! >> >> I did add in some code to add providers legacy default into the server con= f 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 requi= red. >=20 > Correct me if I didn=E2=80=99t 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 t= hink I am starting to understand what is happening. >=20 > Let=E2=80=99s assume that someone has been using BF-CBC (a legacy cipher) a= nd we now upgrade to the new way. Then we would have BF-CBC as fallback ciphe= r and a couple of other ones for NCP. Wouldn=E2=80=99t that require the legac= y setting for OpenSSL allowing us to use BF? >=20 > The client configuration should no longer have the BF (and therefore legacy= ) setting because we are creating it for modern clients. Older clients that h= ave 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 op= envpn-2.4 onwards cipher negotiation is available. When a connection is made from an old cipher, the first approach from the ser= ver 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 negotia= te a more modern cipher and the ones that can be used in openvpn-2.4 are in t= he 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 i= s 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 ope= nssl-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 b= elieve 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 select= able in the data-ciphers-fallback table by adding providers legacy default in= to 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 ne= w connections using the 64 bit ciphers but who knows what people can do if th= ey 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 "A= ll bets are off - Upgrade now!" >=20 >> My preference would have been to remove completely the insecure ciphers fr= om the data-fallback option as the negotiation works with openvpn-2.4.0 and a= client with a BF-CBC cipher specified. >=20 > 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 fr= om 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 t= he 64 bit ciphers in the server for data-cipher-fallback and have providers l= egacy default added to the server config file if one of the 64 bit ciphers ha= s been selected for the data-cipher-fallback and then keep our fingers crosse= d 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 fal= lback option from then on so if users have not updated their client configs w= ith a newer cipher and updated their openvpn client versions then we will rea= ch a decision point. We either move to openvpn-2.7 and those users who have not updated their clie= nts, in the time between now and when we decide to go to 2.7, will not be abl= e to update IPFire without breaking their connections or we stay for ever at version 2.6.x >=20 >> 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. T= he same message would be seen in the logs but as Erik mentioned, too many of = the users won't look in the logs. >=20 > Yes, but we don=E2=80=99t quite know what that number is. I agree that it i= s *very* small, because clients have been using NCP for a long time, even wit= h IPFire. But it is quite likely not zero, as there might be clients that are= too old to support NCP, yet. >=20 > So what do we do to make the path smoother? Introduce the new options, depr= ecate the old ones, let people know about the deprecation, and then finally p= hase it out. In our case, people might be able to do this themselves by simpl= y removing the fallback cipher, so they know for certain that they are out of= the woods with all of this. >=20 >> So in the end my cgi changes have not re-enabled any of the insecure ciphe= rs in the data fallback table but they are still visible there. >=20 > 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 ent= irely. 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 ava= ilable. We will just then have to think about how we decide that things are b= etter after the couple of months to make the change. I am not sure we will kn= ow if those few users without NCP actually exist or not without stopping the = use of the 64 bit data-cipher-fallback. >=20 >> The only problem situation I could see is a user who does not know that th= eir client(s) have insecure ciphers and selects or accepts the default data-f= allback option of AES-CBC but the client has BF-CBC or one of the other insec= ure ciphers specified in the client config. >> >> Maybe that user has inherited a set of client connections that were create= d 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 inse= cure 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. >=20 > My working assumption is, that most clients are at least on >=3D 2.4, and t= herefore don=E2=80=99t use the cipher setting any more - even though it is th= ere. That means that we are dealing with a very small fraction of clients. Le= t me know if you disagree with this assumption. That is also my assumption. The cipher setting will have been used up to curr= ent status as we have the ncp-disable option in our server config currently w= ith openvpn-2.5.9 With this cgi change to using NCP then the cipher option will no longer be us= ed, even though it is in the client config because the negotiation will super= sede it. Regards, Adolf. >=20 > -Michael >=20 >> >> 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 thoug= ht I would just test the server settings with selecting BF in the data-cipher= s-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 c= onf 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 s= till 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.cg= i 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 a= ny problem. My laptop was working withy openvpn-2.6.6 >>>>> >>>>> I then created a new profile using the new ovpnmain.cgi using the negot= iation option which ended up with a data-ciphers line. That also worked in ma= king 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 con= nected with a tunnel with no problems. >>>>> >>>>> I then tried downgrading my laptop to openvpn-2.3.14 but to make this w= ork 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 con= nection 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 spe= cified 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 cli= ent on my laptop. >>>>> >>>>> According to the OpenVPN wiki on cipher negotiation the data-ciphers-fa= llback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients ne= ed 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 syste= m that uses one of the old insecure ciphers such as Blow Fish and restore tha= t 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 some= thing I tested in the past. >>>>> >>>>> If that also works then my plan will be to take the updated ovpnmain.cg= i 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 pers= onal things at the end of October / beginning of November. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >=20 --===============1667401317032571091==--