Is there a way to make sure my government does not swap out SSL certificates?

Question

I was recently wondering whether there exists a way to make sure my government is not swapping out SSL certificates in order to intercept the traffic.

I know almost all browsers are complaining in case of a self-signed certificate. But what prevents a government to issue their own keychain?

One can imagine compromising the repositories containing packages with CA certificates and then issuing their own certificate in order to decipher the traffic. All the traffic is going through government loyal tier 1 operator which also has monopoly rights on providing Internet access.

If that is not a possible case, what mechanism is preventing them from doing it?

Answer 1

If your adversary is a powerful nation-state threat actor, web PKI will not protect you.

Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:

• Government of France
• Government of Hong Kong (SAR), Hongkong Post
• Government of Japan, Ministry of Internal Affairs and Communications
• Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
• Government of Spain (CAV), Izenpe S.A.
• Government of The Netherlands, PKIoverheid
• Government of Taiwan, Government Root Certification Authority (GRCA)
• Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)

While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities, including the US FPKI. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.

While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.

Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.

A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.

Answer 2

Even if you have the original CA certificates the browser/OS might be modified to not properly check certificates. Or the browser/OS might be backdoored so that the plain data can be extracted directly from the application before encryption or after decryption. And such critical modifications or changes in the behavior might also be caused by the hardware you are using.

This means essentially you are asking how to make sure that the system you use (hardware, OS, software, configuration ...) has only the functionality you expect, i.e. has only the functionality intended by the vendor and developers (no backdoors or similar added later) and that this functionality does not include anything which can be used against you (no backdoors by vendor/developer but also no critical bugs which might be used as backdoor).

Unfortunately there is no mechanism to make fully sure that your system behaves like this. Ultimately it boils down how much you can trust the delivery chain both in terms of explicit backdoors but also regarding bugs (inadvertent backdoors). Delivery chain means how much you can trust the sources where you got your hardware and software from (vendors, downloads from the internet...) and also how the hardware and software got protected against tampering during transport from the source. And these sources usually use third party components too which means the question of how much the delivery chain can be trusted must be extended further.

There are a few ways which can help to trust the delivery chain but full trust is not possible. One way is to actually know your delivery chain in the first place and keep it small enough so that you can actually audit it. This also includes to have less complex systems since these allow for a smaller and more easy to audit delivery chain. While this might be possible for some governments or really large companies which have to fear targeted attacks, it is practically impossible for normal end users. These might try to reduce the risk by buying only from trusted vendors though (maybe abroad if you don't trust local vendors) and to minimize what is downloaded from the internet and to make sure it gets always loaded via a secure transport. One might also try to compare critical parts (like local CA certificates or the CA used for a specific connection) with others.

There are also mechanism like secure boot or certificate pinning which help to prevent or detect smaller modifications but might be simply bypassed by a more sophisticated attacker (government agencies) which might replace/disable the relevant checks if he controls enough of the delivery chain.

At the end an unsophisticated end user does not have much chance to distinguish between normal and abnormal system behavior since he does not have enough detail what a normal system behavior should look like in the first place. But assuming that attacks like replacing CA certificates or MITM using government controlled (and browser-trusted) CA will not target only such unsophisticated users but will be more widespread it is likely that some more paranoid and also knowledgeable user will be affected and will detect the attack and warn others.

It is also likely that the attacker will not control enough of the delivery chain, especially if more or less free access to the internet is possible (i.e. mostly free access apart from some explicit blacklisting). In this case users might download software which has added protection - like the built-in SSL-pinnings for critical domains in browsers like Chrome or Firefox. On the other hand paranoid users can also be tricked into downloading software which claims to protect their privacy but instead is a espionage trojan.

Answer 3

Yes. Check the certificate's issuing CA and its fingerprint and/or entire public key, which you can find by viewing the certificate details in your browser. Compare these against the values seen by another person or another computer outside of the domain of the relevant government's control. You could do this with a cheap vps hosted in another country using command line tools to make the TLS connection and dump the certificate info. You can also use Certificate Transparency logs to see if you're getting a different certificate from what's being presented to other users.

Answer 4

It is indeed a risk and if you're going to do something that requires "real" security, let's say something like exchanging nuclear bomb codes, it is a real issue. Then again it's not the greater issue. The actors the attack passes through are not the government directly but CAs. A government always has access to the simple rubber-hose attack so this is always going to be an issue as long as the CAs will be public entities subject to the rule of law (because that will make them subject to one or more governments and thus sensible to pressures or plain old violence). As long as this attack is viable the more refined certificate manipulations are pretty useless, they could force CAs to help them (and keep the silence about it) even if they would not be CAs themselves.

If you need a higher level of confidence I would suggest turning to different approaches to communication involving also (but not only) steganography and side channels to reduce the visibility of your communications and thus reduce the probability to suffer attacks.

To delve into the situation a bit more the idea that a CA can exhibit proof of correctness of its certificates is not yet very popular but it could maybe be possible in a blockchain system. It would probably require significantly more calculations and so I doubt it's viable without some adjustments from the current industry. And even then governments have a very big say in what cryptographic primitives are secure so they could taint the very methods used to issue certificates, for example, I would like to refer you to the NSA's Bullrun program and for a more detailed example to the Dual_EC_DRBG backdoor theorized by Bruce Schneier and Niels Ferguson and later confirmed by Edward Snowden (an argument that I had the occasion to face during my studies before it was confirmed, Dual_EC_DRBG is potentially secure but you've got to generate the curves used in the cryptographic primitive yourself, otherwise you're essentially trusting the NSA to give you good private keys notice that this is not always the case with other algorithms).