Hello, > On 12 Oct 2023, at 06:56, ummeegge wrote: > > Good morning Adolf, > > Am Mittwoch, dem 11.10.2023 um 17:53 +0200 schrieb Adolf Belka: >> Hi Erik, >> >> >> On 11/10/2023 16:20, ummeegge wrote: >>> 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 >> Thanks for the feedback and the link to our conversation at the >> beginning of this year. >> >> So even if the user has BF-CBC set in the client.ovpn, with the >> server >> having server negotiation in this update then the client will end up >> getting connected with an available cipher from the data-ciphers >> list. >> I will do a test of that then on my system >> >> If my understanding is correct, then why do we need to still leave >> the >> weak ciphers in the data-fallback list. Those could also be removed, >> they are blocked anyway. > As mentioned, have removed all 64-Bit block Ciphers and left the 128- > Bit CBC ones in the 'Data-Channel fallback' list to prevent warnings > from the OpenVPN logs. You can find in the same above linked topic a > respective message which points out to this configuration by using the > 'data-cipher fallback' directive. So even if Blowfish, the variations > of DES and CAST5 are out of the list, AES-CBC is still there and can > therefor prevent warnings in the logs via '--data-ciphers-fallback' if > AES-CBC is used on client.ovpn. > >> >> OpenVPN plan to remove those weak ciphers completely in version 2.7 >> If a user at that time still had a client with say BF-CBC would the >> negotiation still work then or would it fail because OpenVPN no >> longer >> recognises the old weak cipher? > This is true according to the OpenVPN 'Deprecated Option' wiki --> > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migrateawayfromdeprecatedciphers.Status:Inprogress > that´s causes, beneath the OpenSSL-3.x decision, to leave the > deprecated ciphers out of the Roadwarrior list (N2N is another thing > since it do no understands cipher negotiation) but pushed at that time > an idea to bring on some warnings for the users before the IPFire > decision to leave the broken ciphers out of any list since the server > can not see what client configuration is in place. > This patch can be found in here --> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f42776f1b60660f4e862d6e847e746b9411b This patch looks good to me. We just need to tame down the warning message a little bit :) > >> >> Regards, >> >> Adolf. > > Best, > > Erik > >>>> 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.