Re: Status update on openvpn work

[ummeegge <ummeegge@ipfire.org>]

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

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 ?

> 
> 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
> > > > > 
> > 
>