From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Status update on openvpn work
Date: Wed, 18 Oct 2023 11:55:55 +0200
Message-ID: <57c1fe08-40b9-4e37-9d96-31e0cea3afac@ipfire.org>
In-Reply-To: <56b577107574a7987daa832e8665fd4fc9e403f6.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7963642572197472059=="
List-Id: <development.lists.ipfire.org>

--===============7963642572197472059==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Erik,

On 18/10/2023 11:29, ummeegge wrote:
> Hi Adolf,
>=20
> Am Sonntag, dem 15.10.2023 um 15:43 +0200 schrieb Adolf Belka:
>> Hi Michael,
>>
>> On 14/10/2023 15:57, Adolf Belka wrote:
>>> Hi Michael,
>>>
>>> On 14/10/2023 14:05, Michael Tremer wrote:
>>>> Hello everyone,
>>>>
>>>> Apologies for my late response on this. The last week had a
>>>> couple of urgent things that were tying me in, but I was happy to
>>>> see that we are finally making some progress on OpenVPN=E2=80=A6
>>>>
>>>>> On 9 Oct 2023, at 13:05, Adolf Belka <adolf.belka(a)ipfire.org>
>>>>> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>>
>>>>> Over the last week I have been working on the openvpn update
>>>>> using Erik's previous patches as my starting point.
>>>>
>>>> Could you please push those changes to a Git repository for
>>>> review? Or did that happen already and I just was too blind to
>>>> find them...
>>>
>>> No, I have been working on them on my vm on my desktop system as
>>> there has been a lot of coming and going as I worked on
>>> understanding various things. What I have now is different from
>>> what I started with.
>>>
>>> I will try and push the changes to my git repository but currently
>>> it is just a single set of changes. I have not yet started to break
>>> the changes into sections to have a commit patch against them yet.
>>>
>> I have pushed the changes as a single diff into my IPFire repo.
>>
>> https://git.ipfire.org/?p=3Dpeople/bonnietwin/ipfire-2.x.git;a=3Dcommit;h=
=3D4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
>=20
> As far as i can see, isn=C2=B4t this not the old code from my previouse
> patches ? The BLAKE algorithm for the HMACs has been reverted and some
> plausibility checks and some configuration logic has been reformated
> (tabs instead of dot=C2=B4s) or have i overlooked something ?

Yes, the start basis was your patches. I made that clear at the start of=20
this email communication on the status.

I don't have the capability to start anew and that definitely didn't=20
seem sensible when you had already done the work initially.

I removed the BLAKE options and the tls-crypt v2 as these seemed to give=20
too many options to people to start with. The tls-crypt gives an=20
improved option for people creating new connections.

We can always add these in later on but the options here seemed to be=20
less the critical item as compared to the move to ncp and preparing for=20
total removal of 64 bit ciphers in openvpn-2.7

I also removed all the options for the ciphers for the control channel.=20
There were no defaults and in that case openvpn makes the choice and=20
seems to choose the best capable option. In my case a tls-1.3 was always=20
chosen.

The openvpn ref manual says the following about those ciphers

"
WARNING: --tls-ciphers, --tls-ciphersuites and tls-groups
     These options are expert features, which - if used correctly - can=20
improve the security of your VPN connection. But it is also easy to=20
unwittingly use them to carefully align a gun with your foot, or just=20
break your connection. Use with care!
"

This indicates that experts can use them well but for non-experts they=20
could be dangerous. Therefore I removed them as options and experts can=20
always add them in as options into their client specific config additions.

This way openvpn will choose the best option for people and that seemed=20
a good situation to be in.

I also moved all the advanced encryption into the advanced server=20
section. This was something that Michael preferred and it also seems=20
sensible to me as then by default a user can just set the global=20
settings and everything else could run with the default settings which=20
would give a good secure system, also good for the future.

I did make some formatting changes but I intend to revert those as in=20
the diff they don't appear to have given the result I was expecting.

The diff is not completed yet but a work in progress and still needs=20
additions for the compression migration path for those users who have=20
selected LZO in the past.

Also the whole diff will then need to be split up into separate patches.=20
I didn't stay with you patch subdivision because I had difficulty trying=20
to follow all the separate changes and understand how to make the=20
changes I was planning. Therefore I applied your whole change set and=20
then have been editing that version with my changes I was able to more=20
easily understand and follow the file with all changes applied to it.=20
That was just my capability limitations.

Regards,
Adolf.

>>
>> At the moment it is still a single set of all changes as that way I
>> could understand the whole picture and the bits that I was changing.
>> I still need to add the LZO stuff plus other changes based on our
>> email discussion in the last few days.
>>
>> When that is all done and we are generally agreed on the approach
>> then I will split all the changes into separate chunks to go in
>> separate patches of a patch set.
>>
>> With the diff in my git repo you can apply that and see the changes
>> and simplifications that I have made so far before our email
>> discussions.
>>
>>
>> Regards,
>>
>> Adolf.
>=20
> Best,
>=20
> Erik
>=20
>>
>>>>
>>>>> 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.
>>>>
>>>> I think that it is an acceptable baseline to only support OpenVPN
>>>> 2.4 and up. That is already a lot more than we actually need to
>>>> do, and we would support clients that are probably vulnerable to
>>>> many things=E2=80=A6 If we need to drop support for OpenVPN 2.4 in this
>>>> process, that might also be acceptable.
>>>>
>>>> What is *not* so acceptable is that the client configuration file
>>>> has to be changed in order to keep working with newer clients,
>>>> because that would require that admins update every single
>>>> configuration file if the client software is being updated. And
>>>> that can be a nightmare with hundreds of connections.
>>>
>>>  From Erik's input and my understanding and my experiments there
>>> will be no need for any client configuration to be done as an
>>> immediate consequence of the changes I am working on.
>>>
>>> If the users are using openvpn-2.4 up then the negotiation from the
>>> openvpn server will work even if the client has BF-CBC specified as
>>> a cipher. I have proven this with openvpn-2.4.0 on my laptop with a
>>> connection profile using BF-CBC and the connection was made with
>>> AES-GCM.
>>>
>>> The users will however need to take the opportunity of the
>>> migration approach with this openvpn work to update the clients
>>> from BF-CBC on a one by one basis. This needs to be done for when
>>> the change to openvpn-2.7 occurs because that version branch will
>>> no longer recognise those old 64 bit ciphers at all.
>>>
>>> I can understand the concern if all client connections had to be
>>> updated in a big bang situation but with the changes being worked
>>> on in this openvpn cgi code the users will be able to update each
>>> client as they have time. This set of changes provides the
>>> migration opportunity for a one by one client update and still
>>> maintaining the non-updated client connections.
>>>>
>>>> Being on the topic of compatibility, I do believe that it is
>>>> acceptable that connections that are generated today are only
>>>> working with clients OpenVPN >=3D 2.6 if we have to do it.
>>>
>>> I don't think there is any restriction like that, that will occur.
>>> However any new client connection that is created will be made with
>>> the data-ciphers option and older insecure ciphers will not be able
>>> to be selected for new connections. If a new connection is being
>>> created then there will be a new .p12 certificate as well so the
>>> package set will need to be transferred to the client anyway so
>>> that restriction should not create a problem.
>>>>
>>>>> 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.
>>>>
>>>> Okay, just to sum this up for me, what will happen is this (in no
>>>> particular order):
>>>>
>>>> * The cipher option in the configuration file will be removed and
>>>> changed to data-cipher-fallback. That way, we will continue to
>>>> support older clients and new ones will use NCP.> * There will be
>>>> a new UI element where people can select ciphers to use in =E2=80=9Cdata-
>>>> ciphers=E2=80=9D very similarly to how to select a cipher for IPsec
>>>> * There will be a deprecation warning for people who use an older
>>>> (64 bit) =E2=80=9CCIPHER=E2=80=9D and they will be encouraged to upgrade=
 all
>>>> their clients to OpenVPN >=3D 2.4 (which should already have
>>>> happened anyways) and they should use NCP only (i.e. no data-
>>>> cipher-fallback option in the server configuration file any
>>>> more). This will also be the new default.
>>>
>>> No. The server will have both a data-cipher and a data-fallback-
>>> cipher option line, selected from the WUI.
>>>
>>> However the server will try for a negotiation first using the
>>> ciphers listed in the data-ciphers list (can be more than one). If
>>> the server and client find a cipher that they both have in their
>>> list then they will agree on that. Only if nothing can be agreed
>>> will the server go to the fallback option. However it seems that
>>> openvpn-2.4.x versions onwards include the AEAD ciphers and
>>> therefore all my testing even with a client of 2.4.0 resulted in a
>>> successful negotiation of AES-GCM (256 bit) even when the config in
>>> the client had cipher BF-CBC specified.
>>>
>>>>
>>>> How do we do all this for N2N connections? Is is safe to just
>>>> remove the cipher option entirely because we assume that all
>>>> clients perform NCP anyways?
>>>
>>> I haven't started looking at that yet. I was trying to get to a
>>> working process with RW tested out with old client versions and
>>> insecure ciphers. I an just about at that point now so I will start
>>> to look at the N2N situation and consequences for existing
>>> connections in early November.
>>>
>>>>
>>>> * In the near future (2.7), the fallback option will have to be
>>>> removed for all, which will render clients that are OpenVPN <=3D
>>>> 2.4 unusable. This is probably acceptable at this point in time.
>>>
>>> That is true, but it will also render clients unusable that have
>>> not taken the opportunity from this openvpn cgi update that is
>>> being discussed, to update the clients from cipher 64_bit_insecure
>>> to data-cipher secure as mentioned earlier.
>>>
>>>>
>>>> * We will have to deprecate LZO as well. Do your patches include
>>>> anything about that?
>>>
>>> No not yet. The cgi update being worked on also works with openvpn-
>>> 2.5.9, the current version. We could do the cgi release with the
>>> current version of openvpn and after any debugging that is flagged
>>> up we could then do an update to openvpn-2.6.x where x could be
>>> anywhere between 0 and 6. I have tested the cgi changes with
>>> openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same way
>>> for all three versions.
>>>
>>> For the LZO situation, the migration path to allow users with
>>> compression to be update on a one by one basis is only available
>>> from version 2.6.0
>>>
>>> To prevent asking users to make multiple updates of client
>>> connections (which I understand would also be undesirable) then we
>>> would need to issue the cgi update together with an update to at
>>> least 2.6.0 and with the LZO changes.
>>>
>>> I have not yet had the chance to work on those. They will probably
>>> come after the N2N checks and evaluation with the changes have been
>>> completed.
>>> I will also need to do testing of any changes of the LZO with my
>>> setup and that is not something I have evaluated to date.
>>>
>>>
>>> Regards,
>>> Adolf.
>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> -Michael
>>>>
>=20

--=20
Sent from my laptop

--===============7963642572197472059==--