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: Sun, 15 Oct 2023 11:44:00 +0100 Message-ID: <62C24BF8-BA2D-45D1-9710-408CB5A54AC2@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3304963990304808178==" List-Id: --===============3304963990304808178== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 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=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D7dec360355= f0eb5bb9bc61b32a08e733aa070b40 >> Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy() o= ne and then check both?! >=20 > 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. >=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 wi= th 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 requir= ed. Correct me if I didn=E2=80=99t understand this correctly, but I thought the t= here might be some corner cases where we would run into this: 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 cipher = and a couple of other ones for NCP. Wouldn=E2=80=99t 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 hav= e 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. > My preference would have been to remove completely the insecure ciphers fro= m 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 fr= om the past and give people some time and technical options to move away from= them... > The only reason for having the ciphers in the data fallback section is as E= rik mentioned that this tells the user that they have a client(s) that need t= o have their connection profiles progressively updated to a modern cipher. Th= e same message would be seen in the logs but as Erik mentioned, too many of t= he 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 with = IPFire. But it is quite likely not zero, as there might be clients that are t= oo old to support NCP, yet. So what do we do to make the path smoother? Introduce the new options, deprec= ate the old ones, let people know about the deprecation, and then finally pha= se 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 t= he woods with all of this. > So in the end my cgi changes have not re-enabled any of the insecure cipher= s 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 th= em all available for a couple of months and then remove the whole thing entir= ely. But I am happy to be shown another way :) > The only problem situation I could see is a user who does not know that the= ir client(s) have insecure ciphers and selects or accepts the default data-fa= llback option of AES-CBC but the client has BF-CBC or one of the other insecu= re ciphers specified in the client config. >=20 > 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. >=20 > In that case that user will get no warning that their clients have an insec= ure 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 b= ecause 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 the= refore don=E2=80=99t use the cipher setting any more - even though it is ther= e. That means that we are dealing with a very small fraction of clients. Let = me know if you disagree with this assumption. -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 though= t I would just test the server settings with selecting BF in the data-ciphers= -fallback selection box. >>>=20 >>> Then pressed Start OpenVPN Server and nothing happened. Checked the logs = 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 B= F unless legacy is selected. In this case I think it is the OpenVPN server co= nf 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 st= ill 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 Erik'= s previous patches as my starting point. >>>>=20 >>>> 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. >>>>=20 >>>> What I then did was take the current ovpnmain.cgi and apply all of Erik'= s patches to it. >>>>=20 >>>> Then I have gone through that new version of ovpnmain.cgi and made the c= hanges based on previous discussions with Michael. >>>>=20 >>>> So I have removed the b2sum options that were present for the Data and C= hannel Authentication. >>>>=20 >>>> I also moved all the cryptographic options from an additional advanced c= ryptographic options button into the Advanced Server options button. >>>>=20 >>>> 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. >>>>=20 >>>> My old profile for my laptop which had a ciphers entry worked without an= y problem. My laptop was working withy openvpn-2.6.6 >>>>=20 >>>> I then created a new profile using the new ovpnmain.cgi using the negoti= ation option which ended up with a data-ciphers line. That also worked in mak= ing 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 openvpn-= 1.1.1 to make that work. >>>>=20 >>>> With that client version on my laptop both the old and new profiles conn= ected with a tunnel with no problems. >>>>=20 >>>> I then tried downgrading my laptop to openvpn-2.3.14 but to make this wo= rk 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. >>>>=20 >>>> The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is = 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 conn= ection 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 o= n the laptop for making the openvpn tunnel connections. >>>>=20 >>>> As far as I can tell everything is working fine when negotiation is spec= ified on the server. Old profiles that just use the cipher option also work f= ine. 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. >>>>=20 >>>> The negotiation option on the server was able to connect to a 2.4.0 clie= nt on my laptop. >>>>=20 >>>> According to the OpenVPN wiki on cipher negotiation the data-ciphers-fal= lback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients nee= d to be using openssl-1.0.0 then I think if those clients work then fine but = nothing further back. >>>>=20 >>>> Overall, I am very happy with what I have succeeded in doing so far. I a= chieved things much quicker than I had expected. >>>>=20 >>>> 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 d= owngraded to openvpn-2.4.0 >>>>=20 >>>> I already know that if the laptop is at openvpn-2.6.6 then it will not a= ccept a blowfish cipher (or another weak cipher such as DES) as that is somet= hing I tested in the past. >>>>=20 >>>> 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 c= onsideration. >>>>=20 >>>> That will probably end up later in November as I will be busy with perso= nal things at the end of October / beginning of November. >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 --===============3304963990304808178==--