From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Wed, 11 Oct 2023 16:20:18 +0200 Message-ID: <38c71efa59af4c9e3fafa8d3862b145cd6458204.camel@ipfire.org> In-Reply-To: <6c851037-58d6-45c9-99a1-0ee5f6074aa8@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0006479147409980014==" List-Id: --===============0006479147409980014== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Adolf, Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka: > 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. Have disabled all the 64 bit block cipher in my previouse patches since the cipher negotiaton managed the whole thing. I think AEAD ciphers are since OpenSSL-1.0.1 available so if AES-GCM is available in --data- ciphers, the clients will use them even BF-CBC is set in client.ovpn . We have had a conversation about this also with some tests which you can find in here --> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3 > > 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 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. Best, Erik > > > 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.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 > > negotiation 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 > > openvpn-1.1.1 to make that work. > > > > With that client version on my laptop both the old and new profiles > > connected 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 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 > > connection 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 > > specified 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 > > client 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 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 > > 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 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 something 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 consideration. > > > > That will probably end up later in November as I will be busy with > > personal things at the end of October / beginning of November. > > > > > > Regards, > > > > Adolf. > > --===============0006479147409980014==--