basilikum

The article says "The target virtual machines ran a stock desktop operating system". Are the vulns in the kernel specifically or does this include software running as root?

Hardware security used to be a joke. Now verified boot, encrypted RAM, key storage in hardware security models and hardware and OS attestation are getting somewhere.

But if you're important enough of a target to a state actor they will magically have some workaround. For your average raid on your home they might actually work depending on the specific setup.

For really high threat models you want zero trust models with E2EE as well as staying anonymous so no one knows where the hardware (and the people which might be much more vulnerable) are located. Tor exists for a reason.

bookworm-security has the fix

aHR0cHM6Ly/wn4WC8J2WjfCdkKTigpvhtZbwnZKTLuKTnPCdlaDwnZKD8J2Tsi/wn4aG8J+Gg/CfhbU=

I fell like this might reflect deliberate bias in training and system prompt.

If not I suggest PHenomenalPhail.

The site content is authenticated with the symmetric key.

The symmetric key is authenticed with the private key.

That led me to jump to the conclusion that the content is transitively authenticated with the private key. But the security model of symmetric and asymmetric authentication schemes is of course very different. The server's private key is never disclosed so you cannot use it to forge the key exchange. But the symmetric key is of course shared and only defines a single level of trust: You either have it, meaning you can both verify messages but also sign arbitrary messages. For the purpose of transport security that is perfectly fine as both parties have full trust in each other for this purpose (the whole point is to guard the connection against anyone else), but for public authentication you need an asymmetric structure that allows verifying without the ability to sign. Symmetric cryptography by design does not enable this.

It is irrelevant that the symmetric key is authenticated with the server's private key because the presupposition that the symmetric authentication works is flawed. Verification by the untrusted public is a different scenario from verification by the two trusted parties of the communication and the presuppositions do not carry over.

When you're using a modern browser that browser will require any certificate to have a certificate transparency log stamp. Certificate Transparency logs are public append only logs of issued certificates.

So you access example.org. Your ISP uses the compromised CA certificate to create and sign a rogue certificate for example.org. It now has to submit this certificate to a public certificate transparency log and gets back a proof for that. Now it can use that rogue certificate and the proof that it's in a CT log to impersonate example.org and MITM your traffic.

CT does not prevent compromise, but it makes it far easier to detect. If the people behind example.org have a look at the CT logs they will see the rogue certificate there that they did not request. This makes rogue certificates and by extension CA compromise detectable. So your ISP cannot just do this forever in secret.