Re: Status update on openvpn work

[Adolf Belka <adolf.belka@ipfire.org>]

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

Hi Erik,

On 11/10/2023 17:53, Adolf Belka wrote:
> 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
>
Confirmed with my testing, as you predicted, that with a client 
connection profile having cipher set as BF-CBC running on a client with 
openvpn-4.0.0 resulted in the negotiation process ignoring the BF-CBC 
cipher and ending up with AES-GCM being used to successfully create an 
openvpn tunnel.

Regards,
Adolf.
> 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.
>
> 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?
>
> Regards,
>
> Adolf.
>
>>> 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.
>>>>
>

-- 
Sent from my laptop