public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Status update on openvpn work
Date: Wed, 18 Oct 2023 11:15:58 +0200	[thread overview]
Message-ID: <0b17964e2364a5b1fdda5b323cd5bad14c49a105.camel@ipfire.org> (raw)
In-Reply-To: <4BCA2F43-E9B4-4EC2-BA4B-1EA004305317@ipfire.org>

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

Hello Michael,

Am Samstag, dem 14.10.2023 um 13:19 +0100 schrieb Michael Tremer:
> Hello,
> 
> Although not ideal, I think it is acceptable for a RW client to
> renegotiate once every 24 hours. It is simply not practical to do
> this more often than once a day when using OTP.
> 
> But we would potentially set the default back to 1hr, and check if we
> can set reneg-sec to 24h in the CCD for connections that have OTP
> enabled?!
I think this is not possibl, refering to the reference manual from
OpenVPN
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/
CCD works only with --push, --push-reset, --push-remove, --iroute, --
ifconfig-push, --vlan-pvid and --config but misses --reneg-sec .

According to some topics e.g. -->
https://forums.openvpn.net/viewtopic.php?t=26132
'--auth-(gen-)token' might be a solutions for this but since 2FA never
worked for me i wasn´t able to test this.

> 
> -Michael

Best,

Erik

> 
> > On 12 Oct 2023, at 12:30, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Your welcome.
> > If you are in state of completing the blog post you can send it
> > again
> > to overread it so we all can speak about it, as an offer from me.
> > 
> > I would really also recommend to make the cipher renegotiation
> > configurable via WUI. Since the release of 2FA it has been
> > hardcoded 
> > -->
> > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;h=eb89c5095569ccd691772a4fb9f314ecd3fd1257;hb=refs/heads/next#l368
> > to 48 hours which in a practical way or in fact disables the PFS
> > also
> > for users which do not use 2FA whereby the OpenVPN default, also
> > with
> > potential secure ciphers, are configured to 1 hour to renegotiate a
> > new
> > session key.
> > 
> > Best,
> > 
> > Erik
> > 
> > Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:
> > > Hi Erik,
> > > 
> > > On 12/10/2023 08:06, ummeegge wrote:
> > > > 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
> > > I had seen that overall page before but obviously not read the
> > > details 
> > > well enough of that specific entry. The entry makes it clear that
> > > from 
> > > openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted
> > > even 
> > > as data-fallback ones.
> > > > > 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!
> > > I see what you are saying. The users tend not to look at their
> > > logs
> > > and 
> > > so will miss the message about the 64 bit BF-CBC etc being
> > > removed
> > > from 
> > > 2.7 onwards.
> > > 
> > > So having the 64 bit ciphers in the data-fallback table but not
> > > allowing 
> > > them to be used and instead giving a warning message about the
> > > cipher
> > > being removed in the future is a way to make the changes more
> > > visible
> > > that the user needs to do and the potential timing scenario.
> > > 
> > > I think I will also need to put together a supporting info blog
> > > post
> > > on 
> > > the openvpn changes that will come with the IPFire updates being
> > > worked 
> > > on and the future ones with openvpn-2.7
> > > > > This patch can be found in here -->
> > > > > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f42776f1b60660f4e862d6e847e746b9411b
> > > Thanks for the clarification.
> > > 
> > > Regards,
> > > Adolf.
> > > > > > 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.
> > > > > > > > > 
> > > 
> > 
> 


  reply	other threads:[~2023-10-18  9:15 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
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 [this message]
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=0b17964e2364a5b1fdda5b323cd5bad14c49a105.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