There are semi-legitimate use cases. One is intranets where you might want to have HTTPS on non-public resources. More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic.
And: yes, adding this certificate should normally be a user-initiated action. There is no way of preventing applications from automating it however. E.g. Firefox doesn’t have an API to install root CAs, so these applications package up NSS Tools in their installer, search for Firefox profiles during installation and add their root CA to any certificate database they can find.
The news coverage is mixed. Some articles are positive about this and are asking about how to improve this sad state of affairs. Others are parroting statements from the affected companies: not actually bad, difficult to exploit, misunderstanding of the domestic market.
And as to politics, it’s too early to tell I think. This definitely generated much attention. Whether all this attention will actually lead somewhere is impossible to tell at this point.
How does this work with HSTS? There's a growing number of websites that will not load unless their legitimate certificate is present.
Edit: since that you might get confused on why HPKP can ransom a site, consider this case:
0. The owner of the website doesn't know about HPKP or decides against implementing HPKP due to its burden.
1. Either the web server, DNS service or BGP corresponding to the IP address of the server is hacked. The attacker can now control the site.
2. The attacker then issues a new certificate. Since that they control the keys, they can send an HPKP header that only locks the key that attackers controlled.
3. Unknowing users visit the site. The site can either be still active (web server hack) or proxied back to the legitimate site (DNS or BGP hijack). HPKP keys are remembered.
4. The owner now realises that their site is hacked and tries to restore it. Let's assume that they have revoked their old cert and issues a new and shiny one which is never in the HPKP header in the first place.
5. Users visit the supposedly now-restored site, but instead of succesfully connecting back it errors out with an HPKP error. The owner can't do anything but to migrate to a new domain name.
Can't they inform the HKPK list provider to revoke the old key after they regain control of the domain?
Also TLS traffic inspection and antivirus can be done at endpoints.
It’s not like I haven’t written about that before. Here is a particularly disastrous implementation: https://palant.info/2019/08/19/kaspersky-in-the-middle--what...
There's also this post https://www.securityweek.com/antivirus-software-has-negative...
Both are bad but network level is worse.
And, also, the crappy corporate monitoring MITM industry that desperately feels the need to spy on employees.
It is a complex mess, where platforms (android, iphone, windows, linux, etc), languages (python, java, node, etc), browsers, web servers, and other pieces all handle client and server certificates in completely different ways.
To be clear, the way these normally work is that they have their own root CA that devices participating on the network add to their trust stores voluntarily.
What alternative do you propose? The most common alternative is OS vendors, who don't always respect the CA/B guidelines (which, overall, have been a positive force for CA ecosystem change).
As far as points of failure/dependency go, Mozilla is not an unreasonable one.
Maybe intermediaries ("middlemen") are trustworthy, and using third party is not single point of failure. Maybe people love the convenience. Maybe it is just laziness. Who knows.
(I suspect the OS vendors may in some cases use the Mozilla bundle.)
Personally I find that many of the certificates in the Mozilla bundle or in browsers are ones I never use. I certainly do not need them all. Sometimes when experimenting with TLS I download root certificates from the companies that provide them. It's certainly possible to get them from their source instead of Mozilla.
At least with system certificates, the user can remove the ones she does not want. With certificates included in browsers, the user would have to edit the source code and re-compile. The so-called "modern" browsers are extremely cumbersome in that regard. Huge size and slow, resource-intensive compilation. And for some of the popular "modern" browsers modification and re-compilation is not even possible because the source code is unavailable.
You can't do this sustainably. We're talking about hundreds of certificates that get cross-signed and rotated on varying bases.
Nothing about this boils down to laziness: CA and bundle management is very difficult. Mozilla does a good job given the complexity, and arguably do a better job (including perceived conflicts of interest) than anybody else who could be tasked with the responsibility.
What does "You" refer to in this comment. And what does "sustainably" mean. Sustainable by who. And for what purpose. Every computer user is different and each may have different needs.
If you want to maintain your own CA bundle, absolutely nothing is stopping you from doing so. But it would not be reasonable of us to expect ordinary users, including people who just want to connect to their banks securely, to do so. And even if we were to make such an unreasonable imposition, it’s not clear that it actually improves their security posture in any way.
With respect to computers and the internet, there is substantial history of problems with third party intermediaries. Deliberately excluding, or even just failing to recognise, the option for a user to eliminate a third party intermediary is highly suspect given that history, IMHO.