This isn't in strict enforcement now, but in a couple of years when browsers have placed enough pressure on CAs, this could be workable and addresses most of the paranoia mentioned in the article.
What I'm proposing is:
Website A wants only SecurCA to issue certs. SecurCA uses Certificate Transparency (CT) and OCSP.
Website A uses Certificate Authority Authorization (CAA) to declare SecurCA as the only CA for that website and the Expect-CT header for enforcing Certificate Transparency checks.
We're assuming another mechanism to secure DNS here (DNSSEC? DoH? DoT? &c) -- more on that later.
----
- Government forces state-issued certificate on all computers.
If government MITMs all access, this is hard to detect except by shipping pre-pinned certificates with the OS (Microsoft). In that case, I'm not sure how to proceed. However, if the government only selectively MITMs, the CA not matching the site's CAA pinning would probably violate it.
- Government forces third-party CA to MITM.
The CA likely wouldn't add this to the CT logs. Expect-CT + strict browser CT checks would prevent the site from loading. If the CA does add it to the CT logs, the website owner can detect that the CA issued a bad cert on its behalf and this CA would be publicly shamed and removed from browser trust stores, (unless they revoked it via OCSP). And, with CAA, the CA the government would have to go to would have to be the same as the one in the CAA authorization records. Other CA's wouldn't work.
- A stolen certificate MITM.
This is the harder case. You have to trust that the website owner doesn't release their certificate. That's a harder problem that isn't currently solved. I'd argue it is nearly impossible. Things like HSMs help mitigate the risk to the highest profile targets but that leaves the wide middle at risk. There's no solution that will work for every website. That's not a TLS/PKI design flaw, but likely a fundamental cryptographic limitation.
But if the website operator did know that it was leaked, they could use OCSP to revoke it quickly.
---
All of TLS/PKI/... relies on DNS. Trust on first use + OS certificate stores is probably the best we can reasonably do when coupled with DNSSEC's questionable security and DoH/DoT. That, IMO, is a bigger problem than any HTTPS flaws.
Note that most of what you've argued in the blog post would happen to any protocol: when a great enough percentage X of traffic goes over it, either it'll be blocked (VPN/SSH/...) or there'll be mechanisms in place to enable Enterprises/... to access this data (TLS).
I think where we're getting to is a lot more secure than it was even 7 years ago when Snowden made his leaks.
"An agile, distributed, and secure strategy for replacing Certificate Authorities."
in his website(https://moxie.org/software.html). I don't remember how it worked but maybe we can develop something like that.
