Comments URL: https://news.ycombinator.com/item?id=50319042

Points: 2

# Comments: 0

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.