From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Core Update 161 (testing) report Date: Fri, 12 Nov 2021 17:32:22 +0000 Message-ID: <69138e61-1f34-c4e0-88bb-fb68c81b9cd0@ipfire.org> In-Reply-To: <25E7086E-51A6-4C73-96F2-5C6012348D28@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1050521819132551832==" List-Id: --===============1050521819132551832== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, thanks for your mail. Please excuse my tardy reply - I currently have a lot o= f other things on my plate, and 24 hours per day are not sufficient to get them done. [Insert personal load average graph here] > Hello, >=20 >> On 2 Nov 2021, at 08:01, Peter M=C3=BCller wr= ote: >> >> Hello *, >> >> Core Update 161 (testing; no release announcement or changelog has been pu= blished, yet) >> is running here for about 12 hours by now without any major issues known s= o far. >=20 > Yay \o/ >=20 >> During the upgrade, I noticed the Pakfire CGI still does not display log m= essages as it >> used to do, but at least there is now a spinning loading icon displaying t= he message that >> an operation is currently in progress. From a UX perspective, this is okay= I guess. >=20 > What is different about it? The older CGI used to print a "tail -f"-like output of Pakfire's log, reloadi= ng the page every few seconds so the user could see the actual process of the ongoing ope= ration. Nowadays, it only gives a spinning GIF image and a text note - better than no= thing, but the user has no idea what is going on behind the scenes and how long it will = take to be completed. >=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 h= ad to do this >> manually. >=20 > Normally people don=E2=80=99t download packages over a VPN. So I can live w= ith this. >=20 >> To my surprise, some IPsec N2N connections did not reconnect automatically= , even after >> rebooting the testing machine. After manually clicking on one of the "rest= art" buttons >> on the IPsec CGI, they came back instantly, and have been stable ever sinc= e. >=20 > Anything in the logs? It should come back automatically. Unfortunately, I did not yet have time to look at this. >=20 >> This affected N2N connections not being in the "on-demand" mode only. Whil= e it is not >> really a show-stopper if someone is sitting in front of his/her/its IPFire= machine, remote >> upgrades might be tricky. >=20 > Indeed. Could you please investigate further whether this is or is not a re= gression introduced in this update? Will do. >=20 >> Apart from that, this update looks quite good to me. The IPS changes are r= eally noticeable, >> and bring a throughput I think I never experienced with IPFire and the IPS= turned on. :-) >> This is certainly worth mentioning, as it finally makes the IPS suitable f= or everyone, >> hence massively increasing security without worrying too much of performan= ce impacts. >> >> (For the sake of completeness: Unfortunately I did not yet have time do co= nduct a penetration >> test against this. Personally, I can imagine the IPS changes permitting so= me attacks >> after Suricata decided it cannot analyse a connection further. Switching p= rotocols might >> be an issue, starting with TLS, while using something completely different= afterwards. >=20 > I expected you to bring this up a lot earlier and it is indeed a concern. A= lthough I think it is a theoretical one: >=20 > * You cannot really change back from a TLS connection on any application th= at I am aware of > * Suricata only does this if it is very very certain that the connection ca= n be bypassed and just hope the guys over there know what they are doing. Yes. Again, things are quite packet on my end - sorry. Indeed, it is a rather theoretical setup: If an attacker already got a TLS co= nnection established so far that Suricata cannot look into it anymore, why not use that connection= to conduct the malicious activities? There is no need to do protocol obfuscation anymore. Thanks, and best regards, Peter M=C3=BCller >=20 >> While I do not really consider this to be a critical attack surface, I wan= ted to look deeper >> into this as soon as I have some spare time to do so.) >> >> 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) >> >> I am looking forward to the release of Core Update 161. >> >> Thanks, and best regards, >> Peter M=C3=BCller >=20 > -Michael >=20 --===============1050521819132551832==--