From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Core Update 161 (testing) report Date: Thu, 04 Nov 2021 12:37:46 +0000 Message-ID: <5347116B-E586-4DEC-9C98-E871FFBA6ADA@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1663776868102812611==" List-Id: --===============1663776868102812611== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 2 Nov 2021, at 10:58, Bernhard Bitsch wrote: >=20 > Hello, >=20 > Am 02.11.2021 um 11:34 schrieb Michael Tremer: >> Hello, >>> On 2 Nov 2021, at 08:01, Peter M=C3=BCller w= rote: >>>=20 >>> Hello *, >>>=20 >>> Core Update 161 (testing; no release announcement or changelog has been p= ublished, yet) >>> is running here for about 12 hours by now without any major issues known = so far. >> Yay \o/ >>> During the upgrade, I noticed the Pakfire CGI still does not display log = messages as it >>> used to do, but at least there is now a spinning loading icon displaying = the message that >>> an operation is currently in progress. From a UX perspective, this is oka= y I guess. >> What is different about it? >=20 > I've implemented the changes also ( took them from the patches ). > I found this difference, too. The 'old' state is, that the messages of the = last pakfire call are displayed. The patch tries to show the actual update pr= ogress. But nothing of it is displayed. I still don=E2=80=99t quite understand. When you click the update button and confirm that you want to install somethi= ng, you should see a screen with a message that =E2=80=9CPakfire is busy=E2= =80=9D and an animated icon. At the bottom of the page, you might see some log lines from /var/log/message= s. If you have too much stuff being logged, you might not see much here. What do you get? The behaviour should be the same since the beginning of IPFire 2. >=20 >>> The reconnection necessary for upgrading pppd went smooth, albeit Pakfire= could not download >>> add-on upgrades afterwards since the VPN did not came back in time, so I = had to do this >>> manually. >> Normally people don=E2=80=99t download packages over a VPN. So I can live = with this. >>> To my surprise, some IPsec N2N connections did not reconnect automaticall= y, even after >>> rebooting the testing machine. After manually clicking on one of the "res= tart" buttons >>> on the IPsec CGI, they came back instantly, and have been stable ever sin= ce. >> Anything in the logs? It should come back automatically. >>> This affected N2N connections not being in the "on-demand" mode only. Whi= le it is not >>> really a show-stopper if someone is sitting in front of his/her/its IPFir= e machine, remote >>> upgrades might be tricky. >> Indeed. Could you please investigate further whether this is or is not a r= egression introduced in this update? >>> Apart from that, this update looks quite good to me. The IPS changes are = really noticeable, >>> and bring a throughput I think I never experienced with IPFire and the IP= S turned on. :-) >>> This is certainly worth mentioning, as it finally makes the IPS suitable = for everyone, >>> hence massively increasing security without worrying too much of performa= nce impacts. >>>=20 >>> (For the sake of completeness: Unfortunately I did not yet have time do c= onduct a penetration >>> test against this. Personally, I can imagine the IPS changes permitting s= ome attacks >>> after Suricata decided it cannot analyse a connection further. Switching = protocols might >>> be an issue, starting with TLS, while using something completely differen= t afterwards. >> I expected you to bring this up a lot earlier and it is indeed a concern. = Although I think it is a theoretical one: >> * You cannot really change back from a TLS connection on any application t= hat I am aware of >> * Suricata only does this if it is very very certain that the connection c= an be bypassed and just hope the guys over there know what they are doing. >>> While I do not really consider this to be a critical attack surface, I wa= nted to look deeper >>> into this as soon as I have some spare time to do so.) >>>=20 >>> Tested IPFire functionalities in detail: >>> - PPPoE dial-up via a DSL connection >>> - IPsec (N2N connections only) >>> - Squid (authentication enabled, using an upstream proxy) >>> - OpenVPN (RW connections only) >>> - IPS/Suricata (with Emerging Threats community ruleset enabled) >>> - Guardian >>> - Quality of Service >>> - DNS (using DNS over TLS and strict QNAME minimisation) >>> - Dynamic DNS >>> - Tor (relay mode) >>>=20 >>> I am looking forward to the release of Core Update 161. >>>=20 >>> Thanks, and best regards, >>> Peter M=C3=BCller >> -Michael >=20 > - Bernhard --===============1663776868102812611==--