57

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?

RoyalGoose
  • 1,005
  • 6
  • 9
  • 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 Monica Mar 10 '22 at 15:43
  • 2
    @ReinstateMonica I'm not exactly sure what this means, you can read the news in the attached link – RoyalGoose Mar 10 '22 at 17:10
  • 2
    Not an answer but start looking into https://tails.boum.org/, if it can help. – wha7ever Mar 10 '22 at 17:41
  • Note that the two links are to `.ru` domains. In light of all the sanctions against Russia for their actions in the Ukraine, my guess is that the government is preparing for any and everything. Whether they would or could cut off access to CAs outside Russia is a debate for a whole different forum. – FreeMan Mar 10 '22 at 17:58
  • 2
    You 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. – Mark Mar 11 '22 at 00:38
  • 1
    @Mark: Moreover, I would expect Let's Encrypy to continue attempting to provide ACME service to the best of their capability (which might be limited by blocking, but hard to block fully). – R.. GitHub STOP HELPING ICE Mar 11 '22 at 15:26
  • 10
    As a bit of a bonus: Exactly this was attempted in 2015 by Kazakh authorities for exactly this reason: https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack – Hobbamok Mar 11 '22 at 16:32

7 Answers7

69

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.

A. Hersean
  • 10,173
  • 3
  • 29
  • 42
  • 31
    It'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. – marcelm Mar 10 '22 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. – Birjolaxew Mar 10 '22 at 16:17
  • 4
    You 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. – benrg Mar 11 '22 at 00: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. – MSalters Mar 11 '22 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. – user1172763 Mar 11 '22 at 15:15
  • A good friend of Russia tried EXACTLY this a bit back: https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack – Hobbamok Mar 11 '22 at 16:31
  • 1
    Thanks @Hobbamok, I added your link into my answer. – A. Hersean Mar 11 '22 at 16:42
52

To illustrate in more detail what A. Hersean explains:

  • In normal usage, when you visit https://security.stackexchange.com, the security.stackexchange.com server presents a certificate which is signed by a CA your browser trusts (ISRG Root X1 in this case).

    • security.stackexchange.com is (normally) the only one having the private key
    • security.stackexchange.com is 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 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.com from that CA even though they are not security.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 to security.stackexchange.com as 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.

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.

Fabio says Reinstate Monica
  • 558
  • 1
  • 8
  • 16
jcaron
  • 3,565
  • 2
  • 16
  • 23
  • 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. – bobuhito Mar 10 '22 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. – John Deters Mar 10 '22 at 18:53
  • @bobuhito The certificate used for a connection is (almost always) provided by the server when you connect. IOW, you get what you get, and have no way to know that other certificates exist. You could in theory compare to a previous certificate, but warning about a mismatch there s generally not done because certificates get renewed all the time, and while it’s uncommon it’s not unusual for a site to change which CA is issuing it’s certificates. – Austin Hemmelgarn Mar 10 '22 at 19:03
  • This is perhaps a different question, but what can OP do in this case? Are they doomed? – Blueriver Mar 10 '22 at 21:17
  • 1
    If 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 – Leliel Mar 10 '22 at 21:39
  • 2
    Relevant mitigation: https://en.wikipedia.org/wiki/Certificate_Transparency – throx Mar 10 '22 at 22:21
  • @throx Too bad that CT is typically ignored for manually installed trust anchors. (It simply has to be as otherwise various "internal company CAs" would be entirely useless as there's no way to get certificates from them into the CT logs.) – TooTea Mar 11 '22 at 08:55
  • @TooTea: Doesn't have to be. If it resolves to a public IP address, lookup the host on all in-box certificates. If you get a match, you know somebody's hijacking. If you can't get through to too many transparency servers you know shenanigans are afoot. Also, publish the cert to some sensor server; if the cert's being abused it can be hardbanned. – Joshua Mar 12 '22 at 03:26
  • 1
    And 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). – gnasher729 Mar 12 '22 at 10:19
  • One point about: "If it were trustworthy" line: Some western CAs are revoking already existing Russian certificates, which leads to fears, that the Russian CAs would automatically be excluded from the "standard procedure" of OS/Browser vendors, which would leave the end-users of Russian websites with no trusted party which would vouch for the proper functioning of Russian CAs. Quite an unfortunate situation. – AndrejaKo Mar 12 '22 at 13:10
6

There are two ways for decrypting HTTPS traffic:

  1. By getting access to the private key
  2. 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.

Robert
  • 1,403
  • 2
  • 14
  • 14
  • 2
    The question is about adding a potentially-untrusted CA as a trust anchor. Once that happens, said CA can issue a `*.com` certificate or something similar to facilitate MITM attacks against third party servers. It has nothing to do with private key escrow. – TooTea Mar 10 '22 at 16:22
5

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).
Toby Speight
  • 1,226
  • 9
  • 17
9072997
  • 233
  • 1
  • 8
3

This is routinely done by commercial antimalware filters, mainly in the big corporate networks:

  1. The anti-malware software instantiates its own CA.

  2. The root CA certificate of the software in question is distributed over the internal network.

  3. 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.

fraxinus
  • 3,458
  • 6
  • 20
1

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.

gnasher729
  • 2,107
  • 11
  • 16
0

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.

xxxx0xxxx
  • 1