From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: OpenVPN-2.5.0 update procedure and idea collector Date: Wed, 25 Nov 2020 18:10:20 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6254956039058286203==" List-Id: --===============6254956039058286203== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, Am Montag, den 23.11.2020, 23:38 +0100 schrieb Adolf Belka: > Hi Erik, >=20 >=20 > On 23/11/2020 20:49, ummeegge wrote: > > Hi Michael, > >=20 > > Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer: > > > Hello everyone, > > >=20 > > > Good to see that we are moving forward on making OpenVPN on > > > IPFire > > > better. > > Bigger hurdles at this time ;-). > >=20 > > >=20 > > > 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 ? > >=20 >=20 > 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. >=20 > > >=20 > > > > On 22 Nov 2020, at 16:30, ummeegge wrote: > > > >=20 > > > > Hi all, > > > > i am currently in the update process of the already realeased > > > > OpenVPN- > > > > 2.5.0 --> https://openvpn.net/community-downloads-2/=C2=A0. 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 > > > > --> > > >=20 > > > Which clients to we want to support? > > >=20 > > > Is it possible and do we want to support OpenVPN 2.3, too? > > Yes it is posible to support <=3D 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... > >=20 > > >=20 > > > Depending on when the last release has been, it might not be > > > worth > > > it. > > It=C2=B4s 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). > >=20 > > >=20 > > > > 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher > > > > negotiation > > > > is a deprecated debug feature that will be removed in OpenVPN > > > > 2.6 > > >=20 > > > I think we have a good way to migrate cryptography. > > Me too, question is how. > >=20 > > >=20 > > > > 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. > > >=20 > > > This seems to be much trickier. > > Haven=C2=B4t been there more than one hour ;-) but there seems to be > > more > > time with that (no 2.6 hint to change it)... > >=20 > > >=20 > > > > in the server log but it nevertheless works flawlessly. > > > >=20 > > > > 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 <=3D OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 > > > > only) > > > > and --tls-ciphersuites (control channel >=3D 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: > > > >=20 > > > > Button to belong to this page: > > > >=20 > > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanc= ed_encryption_button.png > > > >=20 > > > > And the page itself: > > > >=20 > > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanc= ed_encryption.png > > >=20 > > > 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=C2=B4t 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 ? > >=20 > > >=20 > > > Then I have some questions: > > >=20 > > > 1) Does this need to be an extra page? Why didn=E2=80=99t you put this = on > > > the > > > advanced server options page? > > Simply too much, i thought the IPSec workflow is the best one i > > could > > choose. > >=20 > > >=20 > > > 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 ? > >=20 > > >=20 > > > I am asking this because I find this really confusing. Why does > > > OpenVPN need different things selected for TLSv1.3 and <=3DTLSv1.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 > > ?! > >=20 > > >=20 > > > I assume that clients <=3D version 2.3 cannot use cipher > > > negotiation? > > > How is it possible to select multiple options here and this still > > > works? > > That=C2=B4s 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. > >=20 > > >=20 > > > > You can see also the default settings, were i need also your > > > > ideas > > > > and > > > > comments for may better defaults. > > >=20 > > > I am sure we have talked about this somewhere and we even came up > > > with a decision=E2=80=A6 > > Yes i know it too but we didn=C2=B4t go into depth in there ;-) . > >=20 > > >=20 > > > It must be here on the list somewhere... > > 1000% :-) . > >=20 > > >=20 > > > > 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. > > > >=20 > > > > 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. > > >=20 > > > I do not understand how we can split this into two steps because > > > I > > > thought OpenVPN 2.5 won=E2=80=99t 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=C2=B4s check the warnings, one is here already more or > > less > > for me comfortably solved :D . > >=20 > > >=20 > > > -Michael > >=20 > > Great feedback thanks Michael... > >=20 > > >=20 > > > > Everything else would come detached from this. > > > >=20 > > > > Some feedback might be nice. > > > >=20 > > > > Best, > > > >=20 > > > > Erik > > > >=20 > > >=20 > >=20 > >=20 --===============6254956039058286203==--