Hi Michael,

Am Freitag, dem 16.09.2022 um 15:19 +0200 schrieb Michael Tremer:
> Hello Erik,
> 
> > On 16 Sep 2022, at 15:17, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi all,
> > am currently working with the current OpenVPN-2.6_dev version and
> > have
> > had three questions in mind.
> > 
> > 1) Is a OpenSSL update to 3.x currently in plan ? As far as i can
> > see
> > all needed updates for related software are meanwhile ready.
> 
> Yes. Peter is pretty much done with that, but the monitoring plugins
> are the only blocker that is left.
Is it the nagios_nrpe monitoring plugin ? If so, there should be
meanwhile with version 4.1.0 a solution -->
https://github.com/NagiosEnterprises/nrpe/commit/f09162880017d8e84bfd64b874d160798efd26f8

> 
> > 2) The current *.p12 archiv format on IPFire´s OpenVPN uses for
> > PKCS7
> > encryption 'pbeWithSHA1And40BitRC2' which can only be used with the
> > "-
> > provider legacy" option otherwise RC2-40-CBC won´t be accepted.
> > On my both machines -->
> > 
> > No LSB modules are available.
> > Distributor ID: Kali
> > Description:    Kali GNU/Linux Rolling
> > Release:        2022.3
> > Codename:       kali-rolling
> > OpenSSL 3.0.4 21 Jun 2022 (Library: OpenSSL 3.0.4 21 Jun 2022)
> > 
> > 
> > LSB Version:    :core-4.1-amd64:core-4.1-noarch
> > Distributor ID: Fedora
> > Description:    Fedora release 36 (Thirty Six)
> > Release:        36
> > Codename:       ThirtySix
> > OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
> > 
> > OpenSSL-3.x is menwhile in usage and by decrypting the *.p12 files
> > the
> > in here described errors -->
> > https://community.ipfire.org/t/ovpn-cert-creation-algo/7911
> > appear. Without any further interventions, the regular
> > authentication
> > (PWD) process won´t work.
> 
> Meaning? Can we replace this format by anything else and keep the
> password protection?
Yes this should be possible also without OpenSSL-3.x . We tried it with
this patch -->
https://community.ipfire.org/t/ovpn-cert-creation-algo/7911/4
and got a better encryption with AES-256-CBC but only with SHA1 which
was a problem to configure via '-macalg digest' . OpenSSL-3.0 did that
per default but also with SHA256 as MAC --> 
https://community.ipfire.org/t/ovpn-cert-creation-algo/7911/13

> 
> > 3) Before OpenSSL 3.x will be updated in IPFire, makes it sense to
> > bring up some warnings if BF, CAST and DES* (may also SHA1) are in
> > usage ? Otherwise, the OpenSSL update can also be a show stopper
> > for
> > OpenVPN connections on systems which uses the above mentioned
> > ciphers
> > or should the ‘-provider legacy’ flag handle this ?
> 
> I suppose we will need to enable this since we have too many
> installations on the old settings out there.
Might that -->
https://gitlab.com/ummeegge/openvpn-2.5.x/-/commit/52e49c8bef040d5ca21a23c80d0f5b07d562d996
be OK ?

> 
> We still don’t have cipher negotiation.
Have started from the beginning with the meanwhile available OpenVPN-
2.6_dev version without the current IPFire server.conf. The only error
on server side was '--ncp-disable' so the cipher negotiation was indeed
needed. Have used this patch -->
https://gitlab.com/ummeegge/openvpn-2.5.x/-/commit/920f91806293a927a1e88e2cd68bb00fbd0b1f8a
and beneath a lot of deprecation warnings OpenVPN started again with
OpenVPN-2.6_dev . This patch can be made may tighter (no jQuery) and
may there are some other ideas around but at that time i went some more
steps further in the "Advanced server" section. Some explanations,
ideas and screenshot can be found in here -->
https://gitlab.com/ummeegge/openvpn-2.5.x/-/wikis/Explanation-of-the-OpenVPN-transition-from-2.5.x-to-2.6.x-patches

The release date for 2.6 is Dezember at this time as far as i know.

> 
> -Michael
> 
> > 
> > Best,
> > 
> > Erik
>