tls – How is HTTPS protected against MITM attacks by other countries?

The Certificate Transparency standard requires that when a certificate is issued, it should also be submitted to one or more Certificate Logs. These are simple network services that maintain cryptographically assured, publicly auditable, append-only records of certificates. Once a certificate has been added to a Certificate Log, an independent monitor can check the log to ensure that no fraudulent certificate has been issued. These days browsers require all certificates to have a Signed Certificate Timestamp (SCT) either in a TLS extension or through OSCP stapling, which is used to establish that the certificate has been added to a Certificate Log. Most browsers require the certificate to be present in more than one log (chrome requires atleast two). If the SCT is missing, the certificate is rejected. This ensures that whenever any root/intermediate CA starts issuing fraudulent certificates, the monitors will notice and raise a red flag. Then either the CA revokes the certificates, or browsers stop trusting that particular CA.

In the past, HTTP Public Key Pinning was used. This involved the browser saving the public key(s) of a site the first time it was visited, and if the keys suddenly changed, the browser would refuse to connect. Dynamic pinning, which allows any site to be pinned at the first visit, has now been deprecated. However, static pinning, in which browsers ship with hardcoded public keys for popular domains like google.com and facebook.com, is still used. This can also be used to detect MITMs with fraudulently issued certificates, if the MITM targets any of these popular domains.