Re: Status update on openvpn work

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 8740 bytes --]

Hello,

> On 12 Oct 2023, at 06:56, ummeegge <ummeegge(a)ipfire.org> 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.