From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Status update on openvpn work
Date: Thu, 12 Oct 2023 08:06:10 +0200 [thread overview]
Message-ID: <3af89cd55d28e489b235d6035e5620ec8868485e.camel@ipfire.org> (raw)
In-Reply-To: <2644967c0221013d4a450bd98a0f4178c07d6f32.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 7382 bytes --]
Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:
> >
> > OpenVPN plan to remove those weak ciphers completely in version 2.7
> > If a user at that time still had a client with say BF-CBC would the
> > negotiation still work then or would it fail because OpenVPN no
> > longer
> > recognises the old weak cipher?
> This is true according to the OpenVPN 'Deprecated Option' wiki -->
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migrateawayfromdeprecatedciphers.Status:Inprogress
> that´s causes, beneath the OpenSSL-3.x decision, to leave the
> deprecated ciphers out of the Roadwarrior list (N2N is another thing
> since it do no understands cipher negotiation) but pushed at that
> time
> an idea to bring on some warnings for the users before the IPFire
> decision to leave the broken ciphers out of any list since the server
> can not see what client configuration is in place.
To correct this statement, mostly users do not see/recognize such
warnings in the OpenVPN logs, the server does see it!
> This patch can be found in here -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f42776f1b60660f4e862d6e847e746b9411b
>
> >
> > Regards,
> >
> > Adolf.
>
> Best,
>
> Erik
>
> > > > Then pressed Start OpenVPN Server and nothing happened. Checked
> > > > the
> > > > logs and there is the openssl error
> > > >
> > > > OpenSSL: error:0308010C:digital envelope routines::unsupported
> > > >
> > > > which occurs because Openssl-3.x doesn't support the older
> > > > ciphers
> > > > like BF unless legacy is selected. In this case I think it is
> > > > the
> > > > OpenVPN server conf file that requires the
> > > >
> > > > providers legacy default
> > > >
> > > > to be included, rather than the client conf file.
> > > >
> > > > Still it does feel like two steps forward and one backwards so
> > > > overall still making progress.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Adolf.
> > > Best,
> > >
> > > Erik
> > > >
> > > > On 09/10/2023 14:05, Adolf Belka wrote:
> > > > > Hi All,
> > > > >
> > > > >
> > > > > Over the last week I have been working on the openvpn update
> > > > > using
> > > > > Erik's previous patches as my starting point.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> >
>
next prev parent reply other threads:[~2023-10-12 6:06 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 12:05 Adolf Belka
2023-10-09 17:26 ` Adolf Belka
2023-10-11 14:20 ` ummeegge
2023-10-11 15:53 ` Adolf Belka
2023-10-11 20:15 ` Adolf Belka
2023-10-12 5:56 ` ummeegge
2023-10-12 6:06 ` ummeegge [this message]
2023-10-12 9:36 ` Adolf Belka
2023-10-12 11:30 ` ummeegge
2023-10-13 12:52 ` Adolf Belka
2023-10-14 12:20 ` Michael Tremer
2023-10-14 13:15 ` Adolf Belka
2023-10-18 9:05 ` ummeegge
2023-10-18 18:48 ` Michael Tremer
2023-10-18 19:39 ` Adolf Belka
2023-10-19 8:02 ` ummeegge
2023-10-19 10:28 ` Adolf Belka
2023-11-17 8:25 ` ummeegge
2023-10-19 8:07 ` ummeegge
2023-10-14 12:19 ` Michael Tremer
2023-10-18 9:15 ` ummeegge
2023-10-14 12:13 ` Michael Tremer
2023-10-14 14:21 ` Adolf Belka
2023-10-14 12:12 ` Michael Tremer
2023-10-14 12:11 ` Michael Tremer
2023-10-14 14:17 ` Adolf Belka
2023-10-15 10:45 ` Michael Tremer
2023-10-14 12:10 ` Michael Tremer
2023-10-18 9:18 ` ummeegge
2023-10-14 12:08 ` Michael Tremer
2023-10-14 14:12 ` Adolf Belka
2023-10-15 10:44 ` Michael Tremer
2023-10-15 12:43 ` Adolf Belka
2023-10-16 10:02 ` Michael Tremer
2023-10-19 10:37 ` Adolf Belka
2023-10-14 12:05 ` Michael Tremer
2023-10-14 13:57 ` Adolf Belka
2023-10-15 13:43 ` Adolf Belka
2023-10-16 10:05 ` Michael Tremer
2023-10-18 9:29 ` ummeegge
2023-10-18 9:55 ` Adolf Belka
2023-10-18 10:26 ` ummeegge
2023-10-19 10:42 ` Adolf Belka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3af89cd55d28e489b235d6035e5620ec8868485e.camel@ipfire.org \
--to=ummeegge@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox