Hacker News Reader

Comment by algesten | Hacker News Reader

I guess if NSA/FBI forces google to hand over the CA keys, they kan orchestrate undetectable MITM-attacks.

I wonder why browser won't automatically store the fingerprint for every HTTPS-certificate it encounters and throw up a fuzz to the user if a certificate changes without any good reason?

View on HN

Why aren't new certificates for the same domain signed by the old (perhaps expired) certificate (recursively) in addition to the whole CA model?

This proves that whoever has the new cert used to have the old cert. A browser would save a copy of a certificate the first time it visits a site, then when it visits again later it could request the chain of certs back to the first one it ever encountered. Past certs verify new certs; this check wouldn't even involve a CA.

This basically overlays trust-on-first-use security model on top of the CA security model and would make it much more difficult to perform a MITM on sites that the user regularly visits (which are probably the most valuable targets).

You'd need a backup plan for sites that have transferred ownership, or for sites that needed to revoke the old key due to compromise. And once you have that backup plan, how would you decide whether to care if that additional signature exists?

But ownership change and compromise should be communicated to the user. Maybe an "Unverified Identity" shows up for a while and triggers stronger checks in the browser for CT and revocation lists.

Such a MITM attack could only happen once (per CA); doing so would burn a CA, as browsers would then stop trusting it. Certificate Transparency (which many CAs already do and which will become mandatory for all CAs in 2017) ensures that browsers only trust certificates whose issuance gets publicly logged.

It's risky for browsers to do it automatically since it's not something that sites are excepting. Some might be using different certificates on different servers for same domain for example.

It's possible for sites to instruct browsers to do it though, but that's opt-in. https://en.wikipedia.org/w/index.php?title=HTTP_Public_Key_P...

It's opt-in by the site, but that's what public key pinning is: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

That's a bit different though, because you must pin an issuing key, not the actual cert.

Because the browser (or the user) has no way of knowing if the certificate changed for a good reason. Certificate pinning tries to tackle this at the CA level but it's not perfect (in a nutshell, browsers know that google.com can be signed only by a certain small subset of CAs).

The effort to prove a certificate is being changed for a good reason should be with the site owner, so I perhaps the standard could build in some sort of sign-by-previous-cert combined with mandatory information fields.

The certificate pinning of CA is not that useful.

So google rotate a lot of certs, but I bet 95% of the internet use one cert for one server until it expires. Google could fall in in line.

Perspectives for Firefox does this. But Google rotates their certs, this effectively disabling the approach and forcing most users to trust anything 'Google'.

Reply on news.ycombinator.com