Re: Status update on openvpn work

[ummeegge <ummeegge@ipfire.org>]

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

Hi all,

Am Mittwoch, dem 18.10.2023 um 19:48 +0100 schrieb Michael Tremer:
> Hello,
> 
> > On 18 Oct 2023, at 10:05, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi all,
> > 
> > Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka:
> > > Hi Erik,
> > > 
> > > On 12/10/2023 13:30, ummeegge 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.
> > > The problem with making it configurable from the WUI is that
> > > there is
> > > only one value that the server can have so users that have client
> > > connections with and without OTP would have to make a choice
> > > between
> > > one 
> > > or the other.
> > Client and server can have different '--reneg-sec' values but it
> > makes
> > no sense to configure it in such way since the earlier value
> > triggers
> > the renegotiation of the session key and will never reach the later
> > one
> > cause it starts then again with 0.
> 
> Ah okay, I think I overlooked the aspect here that the default comes
> even for the client.
> 
> It is potentially a bad design choice then that the protocol cannot
> rekey without reauthentication.
> 
> We could try to push this from the server side maybe? That would at
> least indicate some SHOULD value. If the client does not honour it,
> we cannot do anything about that.
> 
> > > I have looked through the OpenVPN info on reneg-sec and found
> > > that it
> > > can be specified on both the server but also on each client and
> > > for a
> > > specific client the timer that will time out first is the lower
> > > value
> > > of 
> > > the one in both ends.
> > Yes, and the counter starts then from the beginning.
> > 
> > > 
> > > I have tested this out on my laptop with a direct openvpn cli
> > > connection 
> > > and via the network manager openvpn plugin and also on my android
> > > phone 
> > > via the OpenVPN for Android app.
> > > 
> > > In all three cases I added reneg-sec 30 to the .ovpn profile and
> > > then
> > > installed it.
> > > 
> > > I then was able to successfully make a connection and every 30
> > > secs I
> > > saw in the logs that the connection was renegotiated in all three
> > > cases.
> > It can also be used with pkts [n] and bytes [n] which OpenVPN is
> > using
> > if 64 bit block ciphers are configured and renegotiates after 64 MB
> > of
> > transfered data. This was the consequences after the SWEET32
> > birthday
> > attacks --> https://sweet32.info . But if '--reneg-*' has been
> > configured the internal OpenVPN defaults won´t be used.
> 
> I am not aware that anyone has ever reported that they need to re-
> enter the OTP after hitting a certain amount of data.
> 
> If so, we need to disable this for OTP-enabled clients. The rationale
> would be that because we have stronger authentication, we can afford
> to have fewer rekeys - which I personally disagree with.
> 
> > 
> > > 
> > > So the current server value can be left as it is and for clients
> > > with
> > > the OTP option checked they can have the same reneg-sec as
> > > currently
> > > in 
> > > the server and for clients without the OTP checked they can have
> > > a 
> > > reneg-sec value of one hour, which will trigger before the server
> > > value.
> > I think this won´t work since whichever (server or client) uses the
> > lower value will be the one who triggers the renegotiation and the
> > counter starts then by 0 again. So this is a kind of a global
> > setting
> > and can not be triggered ealier for some and ater for others in my
> > opinion -->
> > https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/
> > .
> 
> That is a correct statement.
> 
> > 
> > > 
> > > It could already be that in some cases this is happening anyway
> > > as
> > > the 
> > > default value for reneg-sec if not specified is 3600 so it
> > > depends
> > > what 
> > > the clients are doing with that default value. I would need to
> > > run a 
> > > test with the three above options where I leave the systems
> > > connected
> > > via OpenVPN and see what happens after one hour (the default
> > > value
> > > for 
> > > reneg-sec) but I am not sure when I will have time for that.
> > Adolf, i would test also the '--auth-(gen-)token' directive -->
> > https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md#auth-token-usage
> > (very old discussion!) may this can be a solution to bypass the
> > whole
> > reneg-sec discussion around 2FA and leave the server to 3600 sec´s
> > or
> > make it even configuerable cause 2FA users uses it, i think, for
> > mostly
> > clients.
> > I can not test this sinec 2FA on IPFire never works for me!
> 
> Why not?
We tried to debug this from community side since a lot of users
reported problems to configure 2FA for their systems whereby for some
others it worked. You can find in here -->
https://community.ipfire.org/t/two-openvpn-problems-2fa-support-and-perfect-forward-security-disabled/9502/17
a community conversation but a bugzilla entry is also available --> 
https://bugzilla.ipfire.org/show_bug.cgi?id=13097

> 
> > > 
> > > I think it will be good to explicitly specify the reneg-sec on
> > > both
> > > OTP 
> > > and non-OTP clients so that the default value doesn't cause
> > > unexpected 
> > > consequences.
> > Please check also the OpenVPN manpage --
> > >  
> > > https://openvpn.net/community-resources/reference-manual-for-openv
> > > pn-2-6/
> > in section "Data Channel Renegotiation" according the above
> > questions
> > and potential testing scenarios.
> > 
> > > 
> > > Regards,
> > > Adolf.
> > > > 
> > > > Best,
> > > > 
> > > > Erik
> > 
> > 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.
> 
>