My state has made a statement that in case my country will be disconnected from the world's CAs, it is necessary to install its own state certificates. In many forums, information has flashed that in this case, having its own certificate, the state will be able to decrypt all HTTPS traffic. Is it true or not?
CAs are a centerpiece of a trust system. Once your browser trusts a CA, in this case a state controlled CA, it trusts all the certificates signed by it. Now, your state-controlled ISP could use fake but trusted certificates to intercept traffic to any website, like the BBC or Bellingcat for example, and your browser would not stop it because it would look legitimate. HTTPS is meant to prevent such attacks. Trusting a rogue CA completely breaks HTTPS. This more recent answer by jcaron details this process.
Note that technically, it's not the rogue CA that decrypts the traffic. It provides the means for interception by other networks actors to remain undetected by the browsers.
To illustrate in more detail what A. Hersean explains:
In normal usage, when you visit
security.stackexchange.comserver presents a certificate which is signed by a CA your browser trusts (ISRG Root X1 in this case).
security.stackexchange.comis (normally) the only one having the private key
security.stackexchange.comis the only site which can decrypt the traffic you exchange with it.
- You know you are talking with the real
If someone manages to intercept the (encrypted) traffic between you and
security.stackexchange.com(by placing a device somewhere on the route between you and the server, or by manipulating DNS so your computer sends the traffic to a different server), as long as you don't trust rogue CAs, either:
- they just access the encrypted traffic and they can't do anything with it
- or they pretend they are
security.stackexchange.com, so they need a certificate for
security.stackexchange.com, and they normally can't get one signed by a CA your browser trusts. If they generate a certificate signed by somebody else (or a certificate signed by a CA you trust, but for a different site), you get a big error message in your browser.
If you trust a "rogue" CA like the one they tell you to, then suddenly that CA can start generating certificates for any site without checking ownership, and they will be trusted by your browser (no error).
- The people who intercept your traffic to
security.stackexchange.com(as above) get a certificate for
security.stackexchange.comfrom that CA even though they are not
- This allows them to act as a proxy (they receive the traffic to
security.stackexchange.com, decrypt it, maybe filter or analyse it, and then connect to
security.stackexchange.comas if they were a regular client).
- Or they can present you something completely different. Your browser thinks it's talking to
security.stackexchange.com, so you think you are visiting that site, but they serve you a page talking about denazification instead.
- The people who intercept your traffic to
So it's not the CA which decrypts the traffic, but they can enable others to do so by giving them certificates you trust even though they shouldn't (because they are not really
This is the way most countries trying to control everything which is exchanged act. They just ask you (or force you) to trust their CA, which allows them to eavesdrop, filter, censor, block or modify anything they want.
This is also the way many corporate proxies/firewalls work.
If you have a choice, do not trust that CA. If it were trustworthy they would follow the standard procedure to be approved by the OS/browser vendors, following the rules of the CA/Browser forum. If they are not approved, that most likely means they are not trustworthy.
There are two ways for decrypting HTTPS traffic:
- By getting access to the private key
- By generating a new key pair and issuing a new certificate for a specific domain you want to get access to the HTTPS traffic. However that requires an active man-in-the-middle attack and users may be able to detect such an attack assuming that the CA does not have access to the private keys of all the generated certificates. In such a case they have to generate a new key pair which can be detected by the client if you know the real public key of a certain domain.
For the first case if the CA works as designed issuing a new certificate then no, they can not decrypt your HTTPS traffic.
The designed work flow is that the you generate a private key and a certificate signing request, send that to the CA and get back the CA signed certificate. As the private key is only known to you the HTTPS traffic is safe.
However a number of CA provide a "service" where you just say "I want a certificate" and they generate the private key for you, generate and sign the certificate and send everything to you. In such a case the CA might get access to your HTTPS traffic (depends on the used TLS version and cipher suite if for doing so a passive attack is sufficient or an active attack is required).
For example if the HTTPS connection uses a cipher that has the Perfect Forward Secrecy property even someone in possession of your private key can not decrypt the traffic if only a passive attack (network sniffing) is performed.
There are 3 threat models that are relevant here. Keep in mind that when I say "the state" I am including groups the state can force to obey them.
- The state is just a CA and can't see or modify your internet traffic: You are totally safe (in this scenario even plain HTTP is safe)
- The state can see but not modify your internet traffic: You are safe as long as the website keeps their private key private OR you are using a protocol with at least weak forward secrecy (ex: TLS 1.3)
- The state can intercept and modify your internet traffic: If the website keeps its private key private AND you are using a browser that requires certificate transparency AND your browser doesn't make exceptions for the state owned CA (see Chrome's policy about not enforcing certificate transparency for manually added CAs) then depending on the attack strategy the state chooses, EITHER your browser will warn you of the attempt to intercept traffic (
net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED) OR the fraudulent certificate will be publicly logged and the website owner will be alerted after the fact (if they have a CT-log monitoring tool/service configured).
This is routinely done by commercial antimalware filters, mainly in the big corporate networks:
The anti-malware software instantiates its own CA.
The root CA certificate of the software in question is distributed over the internal network.
The network traffic is routed through the anti-malware software.
- the software plays "man-in-the-middle" attack for every connection.
- It represents a created on-the-fly certificates signed by its own CA to the clients. Clients track these certificates to the software's own CA (installed in their trust stores) and trust them.
- The traffic is decrypted on the anti-malware scanner and then reencrypted when sent to the server or to the client.
- Other things, like content-scanning, activity logging or changing the content on the fly can also be performed.
In the better case, you get less ads in the pages you browse (and, hopefully, less viruses).
In some cases, your friendly sysadmin looks at your social network activities.
In worse cases, they report your personal mail password to your boss.
The government, in general, can do all of the above. You only need to have their root CA installed.
What is distinct from your corporate network is that you will not have the option to use your personal computer/smartphone for your private communications and there is no legal limits on how the government can abuse these abilities.
Well, there probably will be legal limits, they will just not be enforceable.
p.s. the real solution is to either emigrate or fix your government. ... or wait until the world fixes your government for you, just like Germans did until 1945.
The short answer to your question is No, or Yes, or Maybe. But I think you need to understand what’s happening.
Let’s say A wants to communicate with B securely, using https. Maybe A is my iPhone, and B is Amazon.
Each side has a private/public keypair, and the start negotiating. They exchange data, derived from their keys and from what the other side sends, except they don’t exchange the private keys.
They use a very clever algorithm that lets you decrypt B’s messages if you have all the data exchanged during the negotiation plus A’s private key, and to decrypt A’s messages if you have all the data exchanged plus B’s private key. But if you have all the data exchanged without one of the private keys, you have absolutely nothing. To decrypt anything, you must be part of the key exchange.
So to decrypt, a hacker (or your ISP) must redirect your key negotiation from Amazon to someone else. But there’s a problem: My iPhone will insist that the other side (which is supposed to be Amazon) provides a genuine Amazon certificate. A normal hacker or your ISP don’t have that certificate.
Your CA also has no chance to get Amazon’s certificate. But anyone can create a certificate that claims to be Amazon’s certificate, except nobody will be tricked into believing it’s genuine. Here’s where the CA comes in: If the CA signs the certificate, and my iPhone believes the CA is genuine, then the certificate will be accepted.
So if you have a CA that signs fake Amazon certificates, and an ISP willing to redirect my Amazon traffic, AND my iPhone believes the CA is genuine, then they can read all my Amazon-related traffic.
Now this wouldn’t last long because Apple (and Google, and Microsoft, and everyone else) would figure that out and the next software update would remove that CA. None of the certificates they ever signed would work. So a rogue CA together wit a rogue ISP could do this for a very short time, then the CA will be effectively shut down.
Here is where the power of the state comes in: If Russian police can stop you in the street, and demand you let them install their CAs root certificate or your phone gets destroyed (or you go to jail), yes, then they can read all your internet traffic. Apple will protect you from some hacker doing this, but they can’t protect you if armed police force you.
CA's do not receive the encrypted traffic sent between third parties, and would not be able to decrypt it, even if they did.
But, if the State can force you to accept their State CA certificates for web sites you may be accessing and they have the private keys for those certificates (and they would since that's why they would do it), the State would be able to decrypt your traffic through a Proxy somewhere in the traffic flow between you and your web site.
This is known as a 'man in the middle' attack on the privacy of your communication.