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: Sat, 14 Oct 2023 16:12:58 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0101630973872455748==" List-Id: --===============0101630973872455748== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 14/10/2023 14:08, Michael Tremer wrote: > Hello Adolf, >=20 > We should already have the legacy option enabled by default on the server a= nd client side in some cases. >=20 > Potentially, we need to add a list of ciphers that require it and then add = the same flag again. >=20 > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D7dec360355= f0eb5bb9bc61b32a08e733aa070b40 >=20 > Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy() on= e and then check both?! I did add in some code to add providers legacy default into the server conf f= ile 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. I= f the cipher is able to be enabled then a new connection could be created wit= h 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. 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 cl= ient with a BF-CBC cipher specified. The only reason for having the ciphers in the data fallback section is as Eri= k 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. 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. 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-fall= back 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 b= y 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 insecur= e cipher except for the log messages. Those might have a problem then when op= envpn is updated to 2.7 because they might not have updated their clients bec= ause they didn't know about the insecure ciphers being used. Regards, Adolf. >=20 > -Michael >=20 >> 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 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 a= nd 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 con= f 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 sti= ll 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 p= atch 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 ch= anges based on previous discussions with Michael. >>> >>> So I have removed the b2sum options that were present for the Data and Ch= annel Authentication. >>> >>> I also moved all the cryptographic options from an additional advanced cr= yptographic 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 negotia= tion option which ended up with a data-ciphers line. That also worked in maki= ng 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 conne= cted with a tunnel with no problems. >>> >>> I then tried downgrading my laptop to openvpn-2.3.14 but to make this wor= k I would have had to downgrade the laptop to openssl-1.0.0 which I was not w= illing 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 n= early 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 conne= ction 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 speci= fied on the server. Old profiles that just use the cipher option also work fi= ne. Therefore my plan is to only use the negotiation option and not make it s= electable for older clients. The data-ciphers-fallback option in the server s= eems to be doing its job. >>> >>> The negotiation option on the server was able to connect to a 2.4.0 clien= t on my laptop. >>> >>> According to the OpenVPN wiki on cipher negotiation the data-ciphers-fall= back 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 n= othing further back. >>> >>> Overall, I am very happy with what I have succeeded in doing so far. I ac= hieved 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 do= wngraded to openvpn-2.4.0 >>> >>> I already know that if the laptop is at openvpn-2.6.6 then it will not ac= cept a blowfish cipher (or another weak cipher such as DES) as that is someth= ing 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 co= nsideration. >>> >>> That will probably end up later in November as I will be busy with person= al things at the end of October / beginning of November. >>> >>> >>> Regards, >>> >>> Adolf. >>> >=20 --===============0101630973872455748==--