The browser checks for validity by ensuring the website certificate is signed by a certificate that is shipped with the browser. These "root certificates" are usually owned by Certificate Authorities, such as Verisign or any other number of CAs. CAs ought to verify that the entity creating a new certificate is who they claim to be (the website owner) before signing a certificate. This way, you trust Verisign to tell you that you can trust the target website.
What Kazakhstan has done is create their own root certificate and asked people who live there to install it in their browsers. They are also intercepting any connection to facebook.com and giving your browser a Kazakhstan-created certificate, which is then verified against the Kazakhstan-owned root certificate. Since it will pass this check, the browser shows a happy green banner, even though the certificate is owned by Kazakhstan and not facebook.com. In other words, the data people in Kazakhstan send to facebook.com is now being intercepted and decrypted by Kazakhstan before being forwarded to facebook.com. Facebook is the example used in the linked bug, they can perform this with any other website, too.
How about comparing the IP address of the request with the IP address reported in requests to the FB server with the IP reported if you make an XHR call to a different domain endpoint that returns your IP? That would compare the physical browser's IP with the MITM 'requestors' IP?
If enough of the centralised sites and CDNs look out for this it would render it a lot less effective. This also turns a undetected user security/privacy problem into an in your face "firewall" from the user's point of view. Now the user asks their tech friend "why can't I see FB" and their tech friends sets them up on a VPN.
Apologies if this is hand wavey I'm not a network or security expert but I am curious about this.
The Verisign brand lives on, but it was acquired by Symantec back in 2010, Symantec then sold their CA business to DigiCert back in 2017. So although you may find certificates with "Verisign" branding on them, that has nothing to do with the company named Verisign.
Can we leverage signed DNS records to add another layer of control needed? Do we also need encrypted DNS where we can choose who to trust? Are we stuck with the CA trust model?
Certificate Transparency. Current browsers are moving to not trust any certificate whose issuance wasn't publicly logged. That doesn't prevent an attacker from issuing an MITM certificate, but doing so would permanently burn a CA. (At least, once the policies are in place and enforced.)
If Verisign deliver a certificate with the wrong domain, you'll be able to know that Verisign signed that certificate.
They could certainly say it was a mistake somewhere in the process, but that argument won't work for ever.
At one point sadly you need to trust someone. This model at least give you a way to prove that trust has been broken.
Site owners can monitor these logs for rogue certs issued for their own domains.
Is this voluntary? If I bring a device into the country without this certificate (or if the local removes it from their machine) do things go back to normal?