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?
7
-
3"disconnected from the world's CAs" What does this mean? That internet communication with the world's CAs will be blocked? That it will no longer be lawful for local entities to be able to obtain certificates from the world's CAs?– Reinstate MonicaMar 10, 2022 at 15:43
-
2@ReinstateMonica I'm not exactly sure what this means, you can read the news in the attached link– RoyalGooseMar 10, 2022 at 17:10
-
2Not an answer but start looking into tails.boum.org, if it can help.– Vanity Slug - codidact.comMar 10, 2022 at 17:41
-
2You can't meaningfully "disconnect from the world's CAs". Non-Russian CAs might refuse to issue certificates for Russian businesses, but anyone who can get a copy of the root certificate for a CA can validate any certificates issued by that CA.– MarkMar 11, 2022 at 0:38
-
11As a bit of a bonus: Exactly this was attempted in 2015 by Kazakh authorities for exactly this reason: en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack– HobbamokMar 11, 2022 at 16:32
|
Show 2 more comments
7 Answers
Yes, this could enable your state to spy on HTTPS traffic. That's not just an imaginary threat, it happened in the past in a private company and it was attempted by a state.
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.
answered Mar 10, 2022 at 8:59
-
31It's worth pointing out that a rogue CA that can hand out illegitimate certificates to bad actors (which appears to be what the OP is alleging to) only enables MITM attacks using those illegitimate certificates. In absence of a MITM attack, a HTTPS connection set up using a genuine certificate would still be safe; illegitimate certificates (or their keys) can't be used to decrypt traffic encrypted with another certificate. So the answer to the exact question asked ("decrypt all HTTPS traffic") would be no, strictly speaking. It might be worth addressing that in your answer.– marcelmMar 10, 2022 at 15:59
-
11@marcelm Since HTTPS is negotiated in the clear, and this communication happens over the state-owned ISP, the state would be able to MITM all HTTPS traffic if they so wish. Mar 10, 2022 at 16:17
-
4You shouldn't say "Trusting a rogue CA completely breaks HTTPS" because that implies that you lose all your security and might as well use HTTP. HTTPS with a malicious trusted CA still protects you from passive eavesdropping and from active attacks by anyone not colluding with the CA. Moreover, it just takes a few people checking certificates (e.g. via pinning) to publicly expose the rogue CA. So either the attacks will be narrowly targeted (probably at someone other than you) or they won't last long.– benrgMar 11, 2022 at 0:05
-
1@benrg: True, but that doesn't really help a lot here. We already know Russia went rogue. There's nothing left to expose.– MSaltersMar 11, 2022 at 11:58
-
2@benrg Thank you. This is one of my pet peeves. People like to say things like "the main purpose of HTTPS is to prove who you're talking to is who they claim to be." That is important, but I would argue that the main purpose of HTTPS is to encrypt traffic. Mar 11, 2022 at 15:15
To illustrate in more detail what A. Hersean explains:
In normal usage, when you visit
https://security.stackexchange.com, thesecurity.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 keysecurity.stackexchange.comis the only site which can decrypt the traffic you exchange with it.- You know you are talking with the real
security.stackexchange.com.
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 forsecurity.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 forsecurity.stackexchange.comfrom that CA even though they are notsecurity.stackexchange.com - 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 tosecurity.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 security.stackexchange.com).
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.
-
In your third case (the dangerous case where I "trust a rogue CA"), shouldn't the browser tell/warn me that there are two different trusted security.stackexchange.com certificates available (the rogue one and the correct one)? I am using Google Chrome, so let us suppose that Google makes just the mistake of including a government-issued rogue CA in their trusted list in the next Chrome release. Of course, if I mistype "security.tackexchange.com", I won't get this warning and am therefore in greater danger.– bobuhitoMar 10, 2022 at 18:25
-
2@bobuhito, no, your browser doesn’t know or care about of the existence of any other certificates. The only certificates involved in validating a cert are: the end entity cert provided over the connection; and the cert(s) that signed it. The signing cert must be one in your browser’s Trusted Root CA store. Mar 10, 2022 at 18:53
-
1If you trust the wrong CA you are pretty much hosed until you stop trusting that bad CA. That's one of the biggest flaws in the whole SSL setup, who to trust?. Unfortunately, this is one of the really hard problems with afaik no good technical solutions. Arguably it's not a technical problem, so we shouldn't expect to get a technical solution– LelielMar 10, 2022 at 21:39
-
2
-
1And an actual attack is much easier if a state controls your CA, and the same state controls your ISP. (Because your CA must create a fake security.stackexchange.com certificate, and your ISP is in the best position to redirect you to a fake security.stackexchange.com website). Mar 12, 2022 at 10:19
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.
-
2The question is about adding a potentially-untrusted CA as a trust anchor. Once that happens, said CA can issue a
*.comcertificate or something similar to facilitate MITM attacks against third party servers. It has nothing to do with private key escrow.– TooTeaMar 10, 2022 at 16:22
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).
-
1You forgot to include the case where a browser not using certificate transparency is used. Mar 10, 2022 at 16:22
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.
-
3This just seems to repeat the top voted answer. Were you hoping to add something new?– schroeder ♦Mar 12, 2022 at 0:20