Re: Core Update 161 (testing) report

[Bernhard Bitsch <bbitsch@ipfire.org>]

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

Hi,

as far as I saw in the code, the new CGI tries the refreshing of the 
tail -f also. But it is never displayed.
I tried to search by test prints, but had no success, yet.
Because I didn't test the real CU 161, I'm not sure I've implemented all 
changes ( especially these new systemxxx functions). So I decided to 
stop this research.
I'll give a new try next days.

Regards,
Bernhard

Am 12.11.2021 um 19:54 schrieb Kienker, Fred:
> Peter - the behavior you describe also happens on all our testing 
> systems. It took us several tries to realize the systems hand not just
> locked up.
> 
> Michael - this is a regression from previous behavior.
> 
> There is never any indication to the user the update processing has been
> completed. The tailf of the update log provided an indication of when
> the processing is completed.
> 
> Best regards,
> Fred
> 
> Please note: Although we may sometimes respond to email, text and phone
> calls instantly at all hours of the day and night, our regular business
> hours are 9:00 AM - 6:00 PM ET, Monday thru Friday.
> 
> -----Original Message-----
> From: Peter Müller <peter.mueller(a)ipfire.org>
> Sent: Friday, November 12, 2021 12:32 PM
> To: Michael Tremer <michael.tremer(a)ipfire.org>
> Cc: IPFire: Development <development(a)lists.ipfire.org>
> Subject: Re: Core Update 161 (testing) report
> 
> Hello Michael,
> 
> thanks for your mail. Please excuse my tardy reply - I currently have a
> lot of other things on my plate, and 24 hours per day are not sufficient
> to get them done.
> 
> [Insert personal load average graph here]
> 
>> Hello,
>>
>>> On 2 Nov 2021, at 08:01, Peter Müller <peter.mueller(a)ipfire.org>
> wrote:
>>>
>>> Hello *,
>>>
>>> Core Update 161 (testing; no release announcement or changelog has
>>> been published, 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 okay I guess.
>>
>> What is different about it?
> The older CGI used to print a "tail -f"-like output of Pakfire's log,
> reloading the page every few seconds so the user could see the actual
> process of the ongoing operation.
> 
> Nowadays, it only gives a spinning GIF image and a text note - better
> than nothing, but the user has no idea what is going on behind the
> scenes and how long it will take to be completed.
> 
>>
>>> 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 dont download packages over a VPN. So I can live
> with this.
>>
>>> To my surprise, some IPsec N2N connections did not reconnect
>>> automatically, even after rebooting the testing machine. After
>>> manually clicking on one of the "restart" buttons on the IPsec CGI,
> they came back instantly, and have been stable ever since.
>>
>> Anything in the logs? It should come back automatically.
> Unfortunately, I did not yet have time to look at this.
> 
>>
>>> This affected N2N connections not being in the "on-demand" mode only.
> 
>>> While it is not really a show-stopper if someone is sitting in front
>>> of his/her/its IPFire machine, remote upgrades might be tricky.
>>
>> Indeed. Could you please investigate further whether this is or is not
> a regression introduced in this update?
> 
> Will do.
> 
>>
>>> 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 IPS 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
> performance impacts.
>>>
>>> (For the sake of completeness: Unfortunately I did not yet have time
>>> do conduct a penetration test against this. Personally, I can imagine
> 
>>> the IPS changes permitting some attacks after Suricata decided it
>>> cannot analyse a connection further. Switching protocols might be an
> issue, starting with TLS, while using something completely different
> 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 that I am aware of
>> * Suricata only does this if it is very very certain that the
> connection can 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 connection 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üller
> 
>>
>>> While I do not really consider this to be a critical attack surface,
>>> I wanted 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üller
>>
>> -Michael
>>
> 
>