Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

> this feels wrong, though I can't quite pin point why.

It's unusual for a root CA to be run by a service that otherwise has nothing to do with CA issuance, for the primary purpose of issuing certificates for that service's first-party sites, and not for third-party sites. I can't think of a single other example of a single-purpose root CA like this.

(The announcement mentions that they might use this to operate as a CA for third-party sites as well, but right now it exists to certify first-party sites.)

View on HN

> I can't think of a single other example of a single-purpose CA like this.

Department of Defense: http://www.disa.mil/enterprise-services/identity-and-access-...

There are numerous, Microsoft has its own subordinate CA that they operate for their own certificates. Amazon has its own root CA https://www.amazontrust.com/repository/. There are more as well.

Amazon is using their CA for issuing customer ELB/Cloudfront certificates, not just their own stuff, and not even all of it: the cert I see at https://amazon.com's is Symantec-issued.

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?

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.

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.

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'.

This is not in fact all that unusual at all.

I've seen many examples of non-root CAs for such purposes, but it seems unusual (though not completely unheard-of) among root CAs. I dug through Mozilla's standard certificate bundle, and found very few such certificates. Amazon has one, but they also use that to issue certificates through AWS. Someone elsewhere in the thread mentioned a DoD root CA. The certificate store has some certificates from companies like Dell; no idea what they use those for. Who else has a root CA used exclusively for first-party certification?

In any case, I was only trying to suggest why this seemed odd, based in part on the availability heuristic: whether this is a common practice or not, it doesn't seem like something people (even people who regularly read about changes or events in the CA landscape) would see regularly.

It's actually quite common, another example is Amazon who operates its own root for its SSL certificate needs. Additionally, there is minimal risk profile differences to an unconstrained subordinate CA (like GIAG2 or the equivalent Microsoft subordinate) and a root. One could argue the risk is in fact reduced for a large issuer to be independent because of fewer entities can negativly impact operations.

Reply on news.ycombinator.com