OSI-Auflauf

This can be boiled down to half a page. Why put in the chatgpt manure to.inflate it.

Ugh so much inflated text and self congratulation to something that in the end boils down to trusting you as authority again.

Don't waste your time with dns adblocking.

If you are serious about network side blocking do tls interception (lmao) but that is a lot of maintenance, adds other attack surface and the average openwrt device isn't beefy enough for such things.

Firefox and Ublock Origin against ads.

There is cooler stuff for Openwrt. Mesh nets between friends, to share internal services. Just tinkering with and learning about network stuff. Adding ipv6 to tunnel if isp doesn't support. Having Wifi whose autochannel doesn't suck.

Dual Antennas -> Sword fighting. Only fun with multiple devices and dabbling with mesh mode or throughput maxing. In ax dual channel 40mhz +160mhz bandwidth the throughput is faster than some cables.

I use wg-quick via the parameterized systemd unit ([email protected]) all the time and never had selinux blocks. Which fedora are you on?

Seen devices with IPMI that had by design unauthenticated admin login to the IPMI from the host side that was not removable. They also could flash IPMI firmware from the host. So if your server with such an IPMI is infected you can't trust reimaging it via IPMI because that can be hijacked as well.

Shoutout to Heads for even attempting to make this. But even that is far from complete. At least the UX is a little better than standard.

Lennart is technically doing good work. While his tools are less complicated than the current hilariously convoluted standard boot process, they are still too complicated to use well.

He also misses the point with the attack scenarios. If you luks encrypt your data and choose a good passphrase, the brunt is done against theft. Protecting against bad passwords is futile in the long run. (Will elaborate if requested.) That someone images your drive for offline bruteforce or manipulates your boot binaries is rare. The true benefit of signed boot chain is to have security patches work reteoactively, "compromise recovery". Automated attacks and malware from the internet side are way more common.

Imagine one of your daemons is compromised. As long as it does not escalate privileges, it can only gain persistence via corruptable data files or config accessible to itself. Now a patch comes along that closes the hole that reinfects the daemon. The malware will not start on daemon restart.

With signed booting you can bring that to the kernel and root.

Signed booting with rollback protection into a known good state. As long as the malware is not part of that system it won't run on launch.

But who signs my stuff, especially my own scripts and automation? Me of course, if I had good tooling.

If that became normal malware would just steal the key.

A TPM or other keybearer device lets you conditionally unlock a signing key.

So to sign, you can boot your system into a runlevel / target / ... that does not run auxiliary scripts from writable locations. If that state is measured by the TPM, you can sign.

With good enough tooling this is workable.

If implemented well, this even helps maintenance of the system.

In the state of things now, its a horrible convoluted mess that doesnt give extra security but 10 more points at which you can break your boot.

+ UEFI itself is again a complexity monster full of holes on very many machines. The whole x86 preboot stack amd or intel is a horrible complexity monster.

Many surface brand devices had a toggle in the bios for something like "security level" for years. Which is a switch between Windows signing CA only and Windows signing CA + 3rd party CA. The latter allows shim distros to boot. You can still set your own keys on them.

If firmware not buggy: If Secureboot is set up to use keys which never signed any bootloader that lets you modify the system pre-login.: Then it kind of matters.

If you have a gaming board: Firmware integrity checks are mostly easy bypassable.

If you use a distro's default bootloader scheme: You can compromise the OS pre-login.

The CA that signed the shim, the Microsoft 3rd party CA, sogned all kinds of crap that lets you run whatever you want from that.

The whole shim thing is not about security but having stuff boot smoothly without screwing with bios settings.

If you want it to give you integrity, then you need to roll your own keys and make sure the firmware has no signature check bugs letting one bypass signature checks.

All this is orthogonal to self sovereign systems.

On Intel thats gone. You can't have a secure and sovereign firmware game without extreme extra effort.

The whole secureboot roll your own keys is the next best thing of harm reduction.

If we had some way of making the system actually static and separate from userdata. And a way to boot that prevents any persistent executable code from the userdata part from running. So as to have a clean state. From that on we could bind that state to unlock signing keys to sign the next version of the booted stuff. Then we could have nice security properties minus whatever is bad in the Intel TCB.

Compromise to root would actually be nicely reversible.

Immutable distros exist. But they are not there yet in terms of conditional readonly-ness.

Thats interesting. Are you ok for a 1on1 talk about this topic?

Both do that.

You compare apples with oranges. Because if you'd compare the apples , you'd notice one of them has no usable E2E.

Yes oranges umm phone numbers is a problem. They have that both. Only one can additionally read the contents.

Thats for now the price for a normie interface.

First goalposts first.

Irs super complicated to use. And you need an existing Telegram account to actually handle that cryptocurrency to buy these pseudo-numbers outside of the telephone namespace. Guess what you need to register those. An actual working phone number.

That repo is not fully open.

Release lag -> Telegram foss needs to wrangle the release every time. Fdroid CI takes its time.

Yes and thats why users spend sometimes months on old builds.

Also which distro packages Telegram?

Fedora doesn't. Debian does but at times it was so old the client crashed from receiving server comms because it wasn't fully compatible. It actually crashed as in segfault.

You need a phone number to sign up for Telegram as well.

And you can correlate username to phone number not that hard in most standard setting cases.

Telegram Foss clients exist only because of unpaid volunteers that take Telegrams messy mix of open and closed parts and rip closed parts out and replace them. The Telegram organisation is notoriously late to release the source code to their current release. If they do, its a giant squashed commit without proper changelog. These releases must then be first wrangled by volunteers to be well buildable.

The Telegram Org itself gives no support to volunteers at all.

You can't register with Foss builds. Only official binaries. Nowadays a lot of features are premium only. You can only get premium with official binaries. That part is closed.

Because theirs was particularly bad. They xored a server provided nonce in their modified DH scheme making their side able to mitm the key exchanges.

Signal has got Usernames now.

You can block number discovery.

You can't resolve username to number.

Your main account ID internally is not your number anymore.

If 2 users add you using 2 different links or usernames. Its now harder to confirm its the same account.

On Signal vs Telegram:

Telegrams Encryption is off most of the time. They have serverside access to messages. The optional E2E is annoying to use and isnt even available on every platform. For example Tdesktop afaik still has no E2E support. (And has a very brittle software architecture.) You can't register Telegram accounts with the open source client anymore. This should be a non-Discussion.

MG implying that just because other messengers like Whatsapp use Signals encryption scheme does not make them more more trustworthy.

Yes you can verify in a binary if the stuff is implemented well. But if a vendor has control over the update channel or beta rollout features its kinda easy to hide targeted features. Wasn't Whatsapp caught exfiltrating chats in ways that don't involve the normal channel bypassing E2E?

Btw there is no Signal in Fdroid but nowadays there is an accepted by upstream third party implementation. You could separate software and infra vendor. Look at Molly.im

Better to bring non tech folk to Signal than to other messengers that do the same but less protected.

Matrix? Lol!

> p2p, signing, local first, yadda yadda

curl | bash is the recommended way to install.

When does this come from a not user hostile company?

What use is that when the policy is defined by the same person?

It seems the Cloudflare extended challenge page. At least it requires turning on JIT in hardened chromium builds which loosely correlates to usage of webassembly.