From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: OpenVPN no more --client-(dis)connect scripts can be executed Date: Mon, 12 Oct 2020 11:45:22 +0100 Message-ID: In-Reply-To: <97937943677431d377d5d17e87faefb5ebaa754f.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5318432950756566030==" List-Id: --===============5318432950756566030== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 11 Oct 2020, at 15:16, ummeegge wrote: >=20 > Hi all, > sorry for the late replay but things are going to be a little chaotic > this days :-) . >=20 > Am Donnerstag, den 08.10.2020, 19:18 +0200 schrieb Adolf Belka: >> Hi Michael, >>=20 >> I suspect you are right about my optimism but that is my nature :) > That=C2=B4s great :-) , would you like to step into some more testing round= s :D -->=20 > https://community.ipfire.org/t/openvpn-2-5-development-version/2173 > ? Can we not keep development stuff on the development list please? community.ipfire.org is a support portal and loads of people download all sor= ts of things and crash their systems with it, or never update them. I am all = for having people involved in testing, but only after we have reached some so= rt of standard that is good enough for a larger group of testers. >=20 >>=20 >> Regards, >> Adolf. >>=20 >>=20 >> On 08/10/2020 16:26, Michael Tremer wrote: >>> Hello boys, >>>=20 >>> Great conversation here, but unfortunately this is going to be >>> messy... >>>=20 >>>> On 8 Oct 2020, at 14:23, Adolf Belka >>>> wrote: >>>>=20 >>>> Hi Erik, >>>>=20 >>>> On 08/10/2020 10:11, ummeegge wrote: >>>>> Good morning Michael, >>>>>=20 >>>>> Am Mittwoch, den 07.10.2020, 13:38 +0100 schrieb Michael >>>>> Tremer: >>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> That reads awful. >>>>>>=20 >>>>>=20 >>>>> yes indeed it also feels exactly like this if there is the need >>>>> to >>>>> handle it for the community in a good proper way. >>>>> I really can not understand why directives like --cipher needs >>>>> to be >>>>> changed to --data-ciphers, from the OpenVPN perspective it >>>>> might be a >>>>> better understanding if there is a difference between control >>>>> channel >>>>> and data channel encryption but from the users point of view >>>>> with >>>>> several hundreds clients it is overkill since every client >>>>> config needs >>>>> then to be changed. >>>>>=20 >>>>=20 >>>> I am not sure that this is as major an issue as you indicate, >>>> although I could very easily be wrong, so I thought it was >>>> worthwhile to give my input. >>>>=20 >>>> Firstly, the --cipher option has been indicated that it will be >>>> deprecated ( >>>> https://community.openvpn.net/openvpn/wiki/CipherNegotiation) but >>>> without any date. It does not show up yet in the Deprecated >>>> options page ( >>>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions) >>>> This states "we will try to keep an up-to-date list of all >>>> options we have deprecated, when they will be removed, the >>>> new alternative approach and the reasoning behind removing the >>>> option". >>>=20 >>> So, I suppose we will have to re-implement the whole cipher >>> selection on our side then. We will have to remove --ncp-disable >>> and =E2=80=94cipher and start adding =E2=80=94data-ciphers. A select box = where >>> multiple algorithms can be chosen (like in IPsec) is probably the >>> best option, and we can select AES-{256,128}-{GCM,CBC} and >>> potentially BF if we find a user that is still on it. We would have >>> to deprecate the latter already though. >>>=20 >>> We should then be able to support a maximum of clients according to >>> this=20 >>> https://community.openvpn.net/openvpn/wiki/CipherNegotiation#Serverversio= n2.5 >=20 > As far as i can see now with the testing results from RC2, we can run > the old configurations like before which includes a lot of deprecation > warnings in the logs but it should nevertheless work... The rest, like > Michael mentioned it, should be done better earlier than later. > But besides of that i am really really not sure what happens with the > actual version on Smartphones since i do not uses such. I do not think that too many people use OpenVPN on mobile devices because it = does not provide a native client and all clients that I have tried were a lit= tle fiddly. I think we should start dropping old crypto now. This is an easy change and w= e can get people on AES. That will be with us for the foreseeable future. I am happy to either show a warning for about 6 months and to encourage peopl= e to move away from BF, DES, SEED, etc. And then remove these in around March= -April time for good. We have already marked those ciphers as weak and I woul= d propose to remove all of them. >>>=20 >>> Under no circumstances is it feasible that we require the client to >>> change. We have users out there with hundreds and hundreds of >>> connections. It simply is not possible for them to change them. It >>> will take years. OpenVPN simply seems to be forgetting this. >>>=20 >>>> I think that means that it will likely not be removed till >>>> OpenVPN v2.7 at earliest. > It was a fast way from 2.3 to 2.4 and am sure the way to 2.7 will be > done faster and there are indeed a lot of configurations out there > which uses --ns-cert-type even there are warnings findable in the WUI. >=20 > Apart from that according to the log messages i think we have also some > stuff to solve until 2.6 like the --ncp-disable deprecation --> > https://community.ipfire.org/t/openvpn-2-5-development-version/2173/2 > ? Yes, let=E2=80=99s start with the ciphers/NCP ones first, because that will b= e released earlier. Changing ns-cert-type on the server side should still allow clients to connec= t that use an older version, am I right? >=20 >>>=20 >>> Potentially, but we need to prepare ourselves and our users before >>> that. Whenever we release 2.7, it will simply be too late, because >>> then the deprecated options have already gone. We need to act now, >>> and make sure that a client with a modern configuration can connect >>> to a server - now and in the future. >>>=20 >>> I find it brilliant that OpenVPN has a whole page to describe the >>> deprecation of one option. Although I agree with the cipher >>> negotiation, there has to be a migration path. > Yes, me too.. >=20 >>>=20 >>>> Secondly=20 >>>> https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-n= egotiation.rst >>>> states "OpenVPN 2.5 will only allow the ciphers specified in -- >>>> data-ciphers. To ensure backwards compatibility also if a >>>> cipher is specified using the --cipher option it is automatically >>>> added to this list. If both options are unset the default is AES- >>>> 256-GCM:AES-128-GCM." > Like above explained, The last tests here (RC2) did not have problems > with the --cipher directive even the log fires the warning that it is > deprecated... but am not sure how the 2.5.0 release behavior is since > the beta releases do have noticable changes to the RC ones and again i > have no experiences with Smartphones and the new version... >=20 >>>>=20 >>>> In my OpenVPN for Android client this is what happens. --cipher >>>> has AES-256-GCM from my client config that I transferred from >>>> IPFire but also has --data-ciphers with AES-256-GCM:AES-128- >>>> GCM:AES-256-GCM, so the contents of my --cipher have been copied >>>> across to the end of --data-ciphers. > That might be interessting if the server do not reflects this ? My > testings involves only PCs/laptops which uses the config files without > own interactions/enhancements... That is not a big problem. Just make clear what you tested and what you could= not test when posting patches. Then, somebody else can fill in the gaps. >=20 >>>>=20 >>>> If users are using a strong encryption, such as AES-256-GCM then >>>> this is the default anyway. If people have a weaker encryption in >>>> --cipher such as BF-CBC, CAST or RC2, then currently that will >>>> also be copied across to --data-ciphers but from OpenVPN v2.6 >>>> those encryptions will not be copied across as they have been >>>> deprecated as too weak for some time. The other encryptions will >>>> still be copied across from --cipher to --data-cipher. > If someone uses those algorithms they do not care really about > security, IPFire lined that out as "(weak)" but in fact they are > broken, but the differences between Smartphones and regular clients are > may important to focus on... >=20 >>>>=20 >>>> Eventually, when --cipher is removed (timing still to be defined) >>>> then users may need to ensure that --data-ciphers contains the >>>> encryptions they want to use if they are not using the default of >>>> AES-256-GCM and AES-128-GCM on the IPFire OpenVPN server. > There is meanwhile more, 2.5 offers also CHACHA20-POLY1305 for the data > channel but also BLAKE2 and SHA3 for the controll channel which are > potential candiates for a future default ?! To be honest, I do not care about them. AES has the advantage of hardware acc= eleration on all platforms and it is probably too early to roll out SHA3 as d= efault. We can add them after we got rid of the legacy ones and finished the NCP migr= ation. Tackle one problem at a time. If we change too many things, we won=E2= =80=99t be able to test things easily. >>>>=20 >>>> Having a blog post about the removal of BF-CBC and CAST5-CBC with >>>> OpenVPN v2.6 and the need for anyone using those ciphers would be >>>> a good idea because anyone concerned about their VPN security >>>> would not want to be using those ciphers any more. > May a good idea even this has been meanwhile longer time ago announced > but also outlined in the WUI. >=20 >>>>=20 >>>> So, yes the deprecation of --cipher will eventually give a need >>>> to update client configs if the default strong ciphers are not >>>> being used but the timing is not yet critical. We need to keep an >>>> eye on the Deprecated Options page on the OpenVPN Wiki. >>>=20 >>> Not critical, but clients are normally not being updated. And if, >>> very very slowly. > Exactly! Or in other words, who read the documentation/blog_posts and > acts like recommended ?! Some people do, but it isn=E2=80=99t always possible. In this case: You canno= t simply change the cipher unless you can update all your clients at the same= time. People=E2=80=99s hands are tied. >=20 >>>>=20 >>>> Please let me have your feedback, especially if I have made an >>>> error in my analysis and interpretation. >>>=20 >>> No, I think you are just a little bit more optimistic than I am :) >>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>=20 >>>>=20 >>>>> Also, if --topology net30 will be dropped by OpenVPN we need to >>>>> modify >>>>> every CCD configuration which uses --ifconfig-push out there >>>>> otherwise >>>>> we get an >>>>>=20 >>>>> Wed Oct 7 17:14:29 2020 /sbin/ip addr add dev tun0 10.18.5.2/- >>>>> 1 broadcast 255.255.255.254 >>>>> Error: any valid prefix is expected rather than "10.18.5.2/-1". >>>>> Wed Oct 7 17:14:29 2020 Linux ip addr add failed: external >>>>> program exited with error status: 1 >>>>> Wed Oct 7 17:14:29 2020 Exiting due to fatal error >>>>>=20 >>>>> , which logic should we use to distribute the IPs?! Did some >>>>> tests with >>>>> new CCD configs and topology subnet but run in other currently >>>>> not >>>>> identifiable problems like: >>>>>=20 >>>>> Wed Oct 7 17:19:44 2020 /sbin/ip route add 192.168.5.0/24 via >>>>> 10.25.18.1 >>>>> Error: Nexthop has invalid gateway. >>>>> Wed Oct 7 17:19:44 2020 ERROR: Linux route add command failed: >>>>> external program exited with error status: 2 >>>>> Wed Oct 7 17:19:44 2020 Initialization Sequence Completed >>>=20 >>> This seems to be broken. >>>=20 >>> If we change to =E2=80=9Csubnet=E2=80=9D, we would simply lease one IP ad= dress from >>> the allocated subnet to this client and that is it. >>>=20 >>> I could not find anything that tells us that =E2=80=9Cifconfig-push=E2=80= =9D won=E2=80=99t >>> work any more. However, it currently looks like this for a client: >>>=20 >>> ifconfig-push 10.191.0.2 10.191.0.1 >>>=20 >>> The first IP address is the one that the user has selected for the >>> client and the second one is the one that is getting assigned to >>> the server. > I think there is more but we should deliver that one may to bugzilla > then and may it is possibly also a good idea to wait until the release > and check for potential changes ? We should start now on what we can do now. Why wait? >=20 >>>=20 >>> The documentation says that the second part has to be replaced by >>> the subnet mask. >>>=20 >>> So that means we will have to migrate all those files manually when >>> the update is being applied. This can all be done on the server and >>> therefore won=E2=80=99t break the client configuration. Phew. >>>=20 >>>>>=20 >>>>> which seems to be a kernel or an iproute problem on the client >>>>> system >>>>> --> >>>>> https://community.openvpn.net/openvpn/ticket/1086 >>>>>=20 >>>>> even it connects. >>>>>=20 >>>>> There is a little time for the most stuff left cause this will >>>>> be >>>>> initially a problem with OpenVPN version 2.6 , also, the tested >>>>> 2.5 >>>>> versions are RCs and so may some changes can happen too but >>>>> there is >>>>> currently not much to say from my side except arrgh . >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Can we please create individual tickets for the individual >>>>>> problems >>>>>> and assign someone to work on those (I assume that would be >>>>>> you Erik >>>>>> :D). >>>>>>=20 >>>>>=20 >>>>> Will go for it but as far as i can see we would need possibly >>>>> some more >>>>> help, may Alexander is around for the CCD section ? >>>=20 >>> Yes, it is a good idea to reach out to him as soon as we have a >>> plan. >>>=20 >>>>>> We need to coordinate this and future-proof OpenVPN as best >>>>>> as we >>>>>> can, but it looks like we will break client configuration - >>>>>> again. >>>>>>=20 >>>>>=20 >>>>> As far as i can see it now, yes we will break client >>>>> configurations >>>>> finally with OpenVPN version 2.6 . >>>=20 >>> We probably won=E2=80=99t be able to support it all the way back to Core >>> Update 1. But I suppose we need to try and prepare the currently >>> issued configuration files so that clients will work when they >>> update soon. > 2.5 was working with RC2 also with the conventional configs as far as i > can see but i haven=C2=B4t tested Smartphones since i do not use them... >=20 >>>=20 >>>>>> If we have to do that and there is no way to avoid it, we >>>>>> need to >>>>>> make our users aware of that of course and give the enough >>>>>> time to >>>>>> prepare for this. >>>>>>=20 >>>>>=20 >>>>> Yes, we did that before and i hate it to say but probably we >>>>> need to >>>>> make this again if the OpenVPN update politics go this way. But >>>>> may >>>>> someone here have another idea or i haven=C2=B4t interpret the >>>>> upcoming >>>>> changes incorrectly since there is already no manpage/wiki for >>>>> OpenVPN >>>>> 2.5 around... >>>=20 >>> Questions from me: >>>=20 >>> How do we migrate ns-cert-type? > Create a new PKI with the approrpiate openssl.cnf entries. > But there was also an idea to manually repair the PKI -->=20 >=20 > https://community.ipfire.org/t/solved-manual-repair-pki-on-openvpn-rfc3280-= issue/2326 > which i haven=C2=B4t test and i am also not a friend of it since it mostly > includes also the old values of keylengths 1024 bit host and 2048 bit > for the root certificate --> shouldn=C2=B4t we expand the actual values > 2048/4096 may too ? Oh. This is bad. We need to script the changes then. Otherwise we won=E2=80= =99t be able to encourage users to update. Having shorter key lengths is a compromise that we have to make in my opinion. >=20 >>>=20 >>> How do we migrate comp-lzo/compress? > Should we really do this ? Since Voracle OpenVPN disables compression by de= fault --> > https://community.openvpn.net/openvpn/wiki/VORACLE?__cf_chl_jschl_tk__=3Dc2= 69b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhh= lE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJv= usnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaL= O9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4gh= Qutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q We cannot change this, because it is not being negotiated between the client = and server. So we have to keep it enabled for users where it is currently ena= bled. Again, we have no choice. >=20 >>>=20 >>> We should be fine for the rest. > :-)=20 >=20 >>>=20 >>> How do we get rid of this ugly certificate warning? > Which one you mean ? The RFC something one at the top. >=20 >>>=20 >>> Before we start hacking the CGI, should we try to clean up some >>> code? For example does the whole page not take the /24 format for >>> subnets. That is a bit annoying. > Pretty much, am happy if someone comes around with some help with this sinc= e there has been also some work been made, same with the RRD stuff... > Have also for example outsorted the functions in ovpnmain.cgi and gave them= a own openvpn-functions.pl like it was done with ids-functions.pl, this clea= ned up the cgi also a little and is already available... >>>=20 >=20 >=20 >=20 >>>>>=20 >>>>>=20 >>>>>> I cannot even say how annoying this is - again. But we must >>>>>> try our >>>>>> best. >>>>>>=20 >>>>>=20 >>>>> I feel you very good am not sure how to handle this without >>>>> hassle the >>>>> users around... sad to say but this is not a glorious job. >>>=20 >>> Together we will get it done :) > Great :-) . >>>=20 >>> -Michael >>>=20 >>>>>> -Michael >>>>>>=20 >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Erik >>>>>=20 >>>>>=20 >>>>>>> On 7 Oct 2020, at 11:37, ummeegge >>>>>>> wrote: >>>>>>>=20 >>>>>>> Am Mittwoch, den 07.10.2020, 10:22 +0100 schrieb Michael >>>>>>> Tremer: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 7 Oct 2020, at 10:21, ummeegge >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Hi Michael, >>>>>>>>>=20 >>>>>>>>> Am Mittwoch, den 07.10.2020, 09:20 +0100 schrieb >>>>>>>>> Michael >>>>>>>>> Tremer: >>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> Oh so this is a custom thing? >>>>>>>>>>=20 >>>>>>>>>> Obviously most users won=E2=80=99t use this. If you care much >>>>>>>>>> about >>>>>>>>>> your >>>>>>>>>> custom script, you can write a script that searches a >>>>>>>>>> directory >>>>>>>>>> and >>>>>>>>>> calls all scripts in it (like >>>>>>>>>> /etc/init.d/networking/red.up/ >>>>>>>>>> and >>>>>>>>>> /etc/init.d/networking/red.down/). >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> OK, will give it a try. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Another great example how OpenVPN breaks running >>>>>>>>>> installations. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Yes, and there are comming some exiting new examples >>>>>>>>> with the >>>>>>>>> upcoming >>>>>>>>> releases 8-| ... >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Like what? >>>>>>>>=20 >>>>>>>=20 >>>>>>> e.g. this >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 > https://community.ipfire.org/t/openvpn-2-5-development-version/2173/2 >>>>>>> or >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 > https://community.ipfire.org/t/openvpn-2-5-development-version/2173/8 >>>>>>> checkout the deprecated options :-\ >>>>>>>=20 >>>>>>>> -Michael >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> -Michael >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 6 Oct 2020, at 14:26, ummeegge < >>>>>>>>>>> ummeegge(a)ipfire.org> >>>>>>>>>>>=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Am Dienstag, den 06.10.2020, 12:58 +0100 schrieb >>>>>>>>>>> Michael >>>>>>>>>>> Tremer: >>>>>>>>>>>=20 >>>>>>>>>>>> Why do you have more than one client- >>>>>>>>>>>> connnect/disconnect >>>>>>>>>>>> script >>>>>>>>>>>> in >>>>>>>>>>>> your configuration? >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> In this case it is a email which will be fired if >>>>>>>>>>> someone >>>>>>>>>>> is >>>>>>>>>>> (dis)connected but there are plenty of potential >>>>>>>>>>> possibilities. >>>>>>>>>>> This >>>>>>>>>>> one is not specified for my use case but may for >>>>>>>>>>> the >>>>>>>>>>> OpenVPN >>>>>>>>>>> scripting >>>>>>>>>>> architecture in IPFire in general. >>>>>>>>>>>=20 >>>>>>>>>>> Best, >>>>>>>>>>>=20 >>>>>>>>>>> Erik >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> -Michael >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 5 Oct 2020, at 16:59, ummeegge < >>>>>>>>>>>>> ummeegge(a)ipfire.org> >>>>>>>>>>>>>=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> am currently in testing scenario with the new >>>>>>>>>>>>> OpenVPN- >>>>>>>>>>>>> 2.5_rc2 >>>>>>>>>>>>> and a >>>>>>>>>>>>> additional --client-connect/--client-disconnect=20 >>>>>>>>>>>>> script. >>>>>>>>>>>>> Since >>>>>>>>>>>>> the >>>>>>>>>>>>> release of OpenVPN metrics --> >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>=20 >>>>>=20 > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D708f2b7368cc8fbd5= 4a06ca66337ebdcc26b58b4 >>>>>>>>>>>>> the new OpenVPN version lined out that only one >>>>>>>>>>>>> script >>>>>>>>>>>>> will >>>>>>>>>>>>> be >>>>>>>>>>>>> executed. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> openvpnserver[15373]: Multiple --client-connect=20 >>>>>>>>>>>>> scripts >>>>>>>>>>>>> defined. The >>>>>>>>>>>>> previously configured script is overridden. >>>>>>>>>>>>> openvpnserver[15373]: Multiple --client- >>>>>>>>>>>>> disconnect >>>>>>>>>>>>> scripts >>>>>>>>>>>>> defined. The previously configured script is >>>>>>>>>>>>> overridden. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> so a question arises (beneath a lot=C2=B4s others >>>>>>>>>>>>> which are >>>>>>>>>>>>> here >>>>>>>>>>>>> OT), >>>>>>>>>>>>> should >>>>>>>>>>>>> we make it possible to execute more then one -- >>>>>>>>>>>>> (dis)connect >>>>>>>>>>>>> script >>>>>>>>>>>>> ? If >>>>>>>>>>>>> so, are there may some ideas for this ? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Best, >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Erik --===============5318432950756566030==--