Re: Status update on openvpn work

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

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


Hi Erik,

On 18/10/2023 12:26, ummeegge wrote:
> Hello Adolf,
> 
> Am Mittwoch, dem 18.10.2023 um 11:55 +0200 schrieb Adolf Belka:
>> Hi Erik,
>>
>> On 18/10/2023 11:29, ummeegge wrote:
>>> Hi Adolf,
>>>
>>> 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…
>>>>>>
>>>>>>> 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=people/bonnietwin/ipfire-2.x.git;a=commit;h=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
>>>
>>> As far as i can see, isn´t 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´s) or have i overlooked something ?
>>
>> Yes, the start basis was your patches. I made that clear at the start
>> of
>> this email communication on the status.
>>
>> I don't have the capability to start anew and that definitely didn't
>> seem sensible when you had already done the work initially.
> True and good to see that you go this way.
> 
>>
>> I removed the BLAKE options and the tls-crypt v2 as these seemed to
>> give
>> too many options to people to start with. The tls-crypt gives an
>> improved option for people creating new connections.
>>
>> We can always add these in later on but the options here seemed to be
>> less the critical item as compared to the move to ncp and preparing
>> for
>> total removal of 64 bit ciphers in openvpn-2.7
> Totally agree with.
> 
>>
>> I also removed all the options for the ciphers for the control
>> channel.
>> There were no defaults and in that case openvpn makes the choice and
>> seems to choose the best capable option. In my case a tls-1.3 was
>> always
>> 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
>> improve the security of your VPN connection. But it is also easy to
>> unwittingly use them to carefully align a gun with your foot, or just
>> break your connection. Use with care!
>> "
>>
>> This indicates that experts can use them well but for non-experts
>> they
>> could be dangerous. Therefore I removed them as options and experts
>> can
>> always add them in as options into their client specific config
>> additions.
> This makes the WUI also more readable with a better overview in my
> opinion but even if more options would by time come in there might be
> ways to bring on a better overview but this is future sound...
> 
>>
>> This way openvpn will choose the best option for people and that
>> seemed
>> a good situation to be in.
>>
>> I also moved all the advanced encryption into the advanced server
>> section. This was something that Michael preferred and it also seems
>> sensible to me as then by default a user can just set the global
>> settings and everything else could run with the default settings
>> which
>> would give a good secure system, also good for the future.
> Sound is good and i did it also in the same way in the Gitlab repo
> where i sended you a link at that time may you remember. Have also
> reopened it since there are some other stuff meanwhile in but also not
> updated in the last time. The Gitlab repo does includes also a wiki
> (which was the reason to open it up for this topic) for explaining all
> the commits. If you want to go over it to get may some more infos, you
> can find it here -->
> https://gitlab.com/ummeegge/openvpn-2.5.x/-/wikis/Explanation-of-the-OpenVPN-transition-from-2.5.x-to-2.6.x-patches
> 
>>
>> I did make some formatting changes but I intend to revert those as in
>> 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
>> additions for the compression migration path for those users who have
>> selected LZO in the past.
> OK, are you planning to use the '--compress migrate' option ?

Yes, that was my plan. Not tested yet but will do so when I get some time.

Adolf.

> 
>>
>> Also the whole diff will then need to be split up into separate
>> patches.
>> I didn't stay with you patch subdivision because I had difficulty
>> trying
>> to follow all the separate changes and understand how to make the
>> changes I was planning. Therefore I applied your whole change set and
>> then have been editing that version with my changes I was able to
>> more
>> easily understand and follow the file with all changes applied to it.
>> That was just my capability limitations.
> Great. The above linked wiki includes also links to the patches,
> screenshots and further explanations, some of them are already merged
> in IPFire e.g. the 'Finite_field_DH-parameter'. Even the ovpnmain.cgi
> in there is outdated, it might be may useful.
> 
>>
>> Regards,
>> Adolf.
> 
> Best,
> 
> Erik
> 
>>
>>>>
>>>> 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.
>>>
>>> Best,
>>>
>>> Erik
>>>
>>>>
>>>>>>
>>>>>>> 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… 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 >= 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
>>>>>> “data-
>>>>>> ciphers” very similarly to how to select a cipher for IPsec
>>>>>> * There will be a deprecation warning for people who use an
>>>>>> older
>>>>>> (64 bit) “CIPHER” and they will be encouraged to upgrade all
>>>>>> their clients to OpenVPN >= 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
>>>>>> <=
>>>>>> 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
>>>>>>
>>>
>>
> 

-- 
Sent from my laptop