As far as I can tell, this is more like Goog gathering their own eggs in their own basket. They are becoming more and more self-sufficient, but don't really seem that interested in taking over the whole market. As long as it stays that way, I don't mind much.

Ponder the meaning of the words in the title: The foundation of a more secure web. There's a clear implication of using market power to exercise universal control, and (as we've seen with email & browsers) this is not a new behaviour for Google.

They have the most popular browser, mobile OS, search engine. They operate popular public DNS servers too.

They add this cert and they control a vast chunk of the internet.

But there's no real lock-in effect. It's very easy to switch search engines, but rarely anyone does it because Google's simply better than Bing. If someone else comes up with better algorithms I'm sure that people would start switching. But very few people switch just to avoid the monopolist.

Same for Google Chrome. Switching to another browser is a matter of a few minutes (including taking the data with you). But as long as Chrome is at least as good as the others, there's no reason to do so.

I think it's important to recognize the differences between monopolists with lock-in (e.g. Microsoft with Windows and Office) and those without lock-in. Even though I'm also concerned about the amount of data that Google has, I'm sure they'll at some point end up like Yahoo or AOL. The question only is how long it takes.

IMO Microsoft is only around because they could generate revenues from lock-in effects during years where their new products were really bad. They've caught up now and did a lot right in the last years (and already benefit from it financially). But if they'd only had a portfolio like Google, I'm not sure they would still play a role.

> If someone else comes up with better algorithms I'm sure that people would start switching.

DDG has yielded results far superior to google years (IMHO, this is a bit subjective), but I don't see people moving over because google is simply "what they know".

A better alternative won't make people move, they need further motivation.

This is different from all the things you mentioned by the virtue of not offering CA services to anyone (except themselves). So they are not really entering/disrupting any new market with this move.

They control a popular public dns server, a CA, a global local cache, and control over the most popular browser and phone. They have all the pieces to do almost seamless MITM.

"We see you haven't signed up yet for AMP, so we've done the work for you"

Yes, I get they wouldn't do this, but the fact that they could is a little scary.

whats even more scary, is Google being able to tell what site is valid/secure. Imagine the implications if they limited who could get CA's or decided the information on your site was harmful

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

> 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?

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

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.

I guess I'm not the only one who's noticed the steady stream of "Do x with google" on the frontpage. This is what's unsettling me, they seem to want to seep into every last crack of our lives, starting with all things web.

Edit: At least it felt like a slow stream to me. Search isn't being very cooperative towards my cause right now... The only item matching my memory is https://news.ycombinator.com/item?id=13013494 , but I'll be damned if there weren't others.

On the other hand, they still lag behind Microsoft and Amazon when it comes to cloud efforts. Yes, they clearly dominate search and ads, but the topics discussed here are mostly cloud-services related. And there, most is done via AWS and increasingly also via Azure (esp. enterprises). Google Cloud doesn't dominate that in any way.

Let's hope they stick to publishing all certificates into the certificate transparency list (Merkle tree).

They should be - they're making certificate transparency logs mandatory in 2017 [1].

[1] https://casecurity.org/2016/11/08/google-certificate-transpa...

If they use their browser dominance to gain the upper hand in the certificate issuance market that seems like a violation of anti-trust law.

If they use their data centers to imprison detractors, that also sounds illegal. It doesn't make data centers sketchy on their own, though.