Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge <ummeegge@ipfire.org>]

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

Hello Adolf,

Am Montag, den 23.11.2020, 23:38 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> 
> On 23/11/2020 20:49, ummeegge wrote:
> > Hi Michael,
> > 
> > Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer:
> > > Hello everyone,
> > > 
> > > Good to see that we are moving forward on making OpenVPN on
> > > IPFire
> > > better.
> > Bigger hurdles at this time ;-).
> > 
> > > 
> > > To avoid that the conversation is getting stuck again, can we
> > > split
> > > the problems into many smaller ones instead of having one massive
> > > thread again? I think I suggested that some time before and it
> > > would
> > > really help us to stay on track with things and ideally merge
> > > everything that is done already so that we do not end up with one
> > > massive patchset that is getting really difficult to work with
> > > later
> > > on.
> > Might it be an idea to go for the initial post, with the update to
> > 2.5.0 new crypto for N2N, nothing changed for RW. In the same or
> > may
> > the next core update a "Advanced Cyrpto Section" delivers data-
> > cipher,
> > data-cipher-fallback, can but must not be tls-cipher, tls-
> > ciphersuite -
> > -> both are new ?
> > 
> 
> All of my experience to date is with RW. If you will use N2N
> initially I will have to see if I am able to set an N2N system up in
> my Virtual test bed. I will only be able to test out any OpenVPN
> changes in N2N if I am successful in setting that up. I will give it
> a go.
Great thanks for that. If i get responds from Michael i will start over
with this. I can neverthless push also the RW code changes to my Git
repo if you want to go for some testings also in there.

> 
> > > 
> > > > On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
> > > > 
> > > > Hi all,
> > > > i am currently in the update process of the already realeased
> > > > OpenVPN-
> > > > 2.5.0 --> https://openvpn.net/community-downloads-2/ . The
> > > > update
> > > > has
> > > > been tested and worked so far also with the old default client
> > > > configuration (tested with 2.4.9 client). There are two
> > > > warnings
> > > > -->
> > > 
> > > Which clients to we want to support?
> > > 
> > > Is it possible and do we want to support OpenVPN 2.3, too?
> > Yes it is posible to support <= 2.3.x . Every client needs to be
> > aware
> > of the Galois-Counte-Mode otherwise we would need --> '--data-
> > ciper-
> > fallback' which is equal to the current --cipher directive in 2.5.0
> > ...
> > Try to sort it in that way...
> > 
> > > 
> > > Depending on when the last release has been, it might not be
> > > worth
> > > it.
> > It´s possible but also practical to deliver the chance to migrate
> > via -
> > -data-cipher-fallback (only one cipher, taken the already existing
> > 'DCIPHER' in that case).
> > 
> > > 
> > > > 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
> > > > negotiation
> > > > is a deprecated debug feature that will be removed in OpenVPN
> > > > 2.6
> > > 
> > > I think we have a good way to migrate cryptography.
> > Me too, question is how.
> > 
> > > 
> > > > 2) WARNING: --topology net30 support for server configs with
> > > > IPv4
> > > > pools
> > > > will be removed in a future release. Please migrate to --
> > > > topology
> > > > subnet as soon as possible.
> > > 
> > > This seems to be much trickier.
> > Haven´t been there more than one hour ;-) but there seems to be
> > more
> > time with that (no 2.6 hint to change it)...
> > 
> > > 
> > > > in the server log but it nevertheless works flawlessly.
> > > > 
> > > > Am working currently on an "Advanced Encryption Settings" page
> > > > which
> > > > includes currently four new directives --data-ciphers (data
> > > > channel
> > > > encryption), --data-ciphers-fallback (data-channel encryption
> > > > for
> > > > clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
> > > > only)
> > > > and --tls-ciphersuites (control channel >= TLSv3) all options
> > > > are
> > > > explained in here -->
> > > > https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> > > > , which works here currently and looks like this:
> > > > 
> > > > Button to belong to this page:
> > > > 
> > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> > > > 
> > > > And the page itself:
> > > > 
> > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
> > > 
> > > In order to keep things like this archived for later, you can
> > > simply
> > > attach them to the email that you send to the list :)
> > Ohh didn´t see that :D hope i do not forget it until the next
> > time...
> > Best is i deliver the code and more people can go for a checkout ?
> > 
> > > 
> > > Then I have some questions:
> > > 
> > > 1) Does this need to be an extra page? Why didn’t you put this on
> > > the
> > > advanced server options page?
> > Simply too much, i thought the IPSec workflow is the best one i
> > could
> > choose.
> > 
> > > 
> > > 2) What is the use-case for choosing different things for the
> > > data/control channel?
> > More possibilites equal to IPSec but also more flexibility to the
> > existing infrastructure/features. Nevertheless a default can be
> > existant like it is in IPsec advanced crypto page. Should we
> > enable/disable/delete the control channel crypto section ?
> > 
> > > 
> > > I am asking this because I find this really confusing. Why does
> > > OpenVPN need different things selected for TLSv1.3 and <=TLSv1.2?
> > > Should we not hide this from the user, because otherwise editing
> > > the
> > > configuration file is easier?
> > Yeah this is confusing. TLSv3 for the control channel is another
> > dierctive (--tls-ciphersuites), the channel control with TLSv2 uses
> > the
> > --tls-cipher directive. May also not that bad, fututre sound of
> > music,
> > TLSv2 will sooner or later go and there is than --tls-ciphersuites
> > ?!
> > 
> > > 
> > > I assume that clients <= version 2.3 cannot use cipher
> > > negotiation?
> > > How is it possible to select multiple options here and this still
> > > works?
> > That´s true. 2.3 have no plan how to use the
> > NegotiationCipherProtocol
> > . In that case the new directive '--data-ciphers-fallback algo'
> > which
> > is simply '--cipher alg' , as we know it, handles this.
> > 
> > > 
> > > > You can see also the default settings, were i need also your
> > > > ideas
> > > > and
> > > > comments for may better defaults.
> > > 
> > > I am sure we have talked about this somewhere and we even came up
> > > with a decision…
> > Yes i know it too but we didn´t go into depth in there ;-) .
> > 
> > > 
> > > It must be here on the list somewhere...
> > 1000% :-) .
> > 
> > > 
> > > > On the page itself is also more planned but to not overload
> > > > this
> > > > here
> > > > now, i wanted to go now a two step procedure with this update.
> > > > 
> > > > 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
> > > > regukar
> > > > global settings for RW and N2N. A overview of the new crypto
> > > > can be
> > > > found in here -->
> > > > https://community.ipfire.org/t/openvpn-2-5-development-version/2173
> > .
> > > > 2) I would push the "Advanced Encryption settings" development
> > > > as
> > > > seen
> > > > above then as one patch <-- this would also eliminate the first
> > > > warning
> > > > causing --ncp-disable since we can delete this option then.
> > > 
> > > I do not understand how we can split this into two steps because
> > > I
> > > thought OpenVPN 2.5 won’t work with the current settings?!
> > For RW are only two warnings (NCP, topology) but it works here,
> > which
> > is for N2N not that hard since N2N do not understands
> > 'push|SENT_CONTROL' and it works also not with --topology net30. I
> > would give N2N all that new stuff for ciphers and HMACs but the RW
> > runs
> > for the first without modifications. This could be the second patch
> > ?!
> > Ater that let´s check the warnings, one is here already more or
> > less
> > for me comfortably solved :D .
> > 
> > > 
> > > -Michael
> > 
> > Great feedback thanks Michael...
> > 
> > > 
> > > > Everything else would come detached from this.
> > > > 
> > > > Some feedback might be nice.
> > > > 
> > > > Best,
> > > > 
> > > > Erik
> > > > 
> > > 
> > 
> >