Re: Status update on openvpn work

[ummeegge <ummeegge@ipfire.org>]

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

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