27

I was reading an article which said that if you install custom root cert from a third party then they can decipher all communication between you and others.

But that doesn't make sense. What I understand is that root cert allows SSL mechanism to verify if a certificate provided by connecting party is legit or not.

So unless someone(company, work, hacker, etc) really tries to impersonate by doing mitm. Only then the compromised root cert will come in play as that would be used to pass fake cert as valid cert.

otherwise just simply having a custom root cert isn't like decrypting all your ssl traffic. Unless the same org has also installed a software that acts as a proxy for all internet traffic. It requires active intercepting, decrypting, and re-encryption of all traffic. So either by installing malware on the computer or monitoring internet traffic.

correct?

Muhammad Umer
  • 715
  • 7
  • 10
  • Previously: https://security.stackexchange.com/a/67534/144146 – user3067860 Feb 10 '21 at 21:15
  • 28
    *So unless someone(company, work, hacker, etc) really tries to impersonate by doing mitm* your confusion isn't due to a misunderstanding of the mechanics involved, but a lack of cynicism. Employers, schools, etc... are completely willing to MITM your web traffic, but they will use euphemisms like "SSL inspection" to make it sound a little nicer. It's a major component of BlueCoat and ZScaler product lines, for example. – Z4-tier Feb 11 '21 at 05:48
  • 5
    If you don't have a MITM then there is no reason to install a custom root cert. If a third party is asking you to install a custom root cert then they are a MITM, otherwise they would have no reason to bother asking you! – user253751 Feb 11 '21 at 18:34
  • 2
    @user253751 MITM is not the only reason why trusting a private CA may be required. Organizations commonly have an internal PKI and internal-only systems are issued certificates by the organization's private CA (or a private intermediate). Any machine interoperating with those internal targets needs the private CA's root cert installed and trusted. – Michael - sqlbot Feb 15 '21 at 16:31

5 Answers5

35

I was reading an article which said that if you install custom root cert from a third party then they can decipher all communication between you and others.

I have no idea what you were reading (citations would be helpful). But you are right in that it is not sufficient to just have a custom root CA certificate installed as trusted - the school/work also has to be an active man in the middle in the traffic and use this CA certificate for SSL interception.

So either by installing malware on the computer or monitoring internet traffic.

Not only malware installed on the computer can monitor the traffic. It is actually common that trusted programs like antivirus or parental control software do this.

And when being directly inside the company (or school) network the path to the internet is usually through the companies firewalls and proxies anyway. Even when connecting from remote with a VPN or other access software the traffic is routed and inspected through company controlled firewalls/proxies, either in the company directly but more often also somewhere in the cloud.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 2
    Follow up question, if this is being done to you, can you tell by looking at the certificate details from the lock icon in the browser? What would you being looking for or how to check it? – Segfault Feb 10 '21 at 16:24
  • 8
    @Segfault: This is not a discussion forum with follow-up's. These should be asked as new questions instead. But this specific one was already answered in [Is it possible for Firefox to detect MITM attacks by the enterprise?](https://security.stackexchange.com/questions/166754/is-it-possible-for-firefox-to-detect-mitm-attacks-by-the-enterprise). – Steffen Ullrich Feb 10 '21 at 16:53
  • 2
    @Segfault: One way to check is to have someone outside of your possible MiTM path obtain a certificate fingerprint for comparison. [Gibson Research] (https://www.grc.com/fingerprints.htm) has such a service. Just plug the suspect URL into **GRC** and compare it to what you see directly. – user10216038 Feb 10 '21 at 17:42
  • 6
    @user10216038 Thanks; added GRC to the list of websites to spoof… – wizzwizz4 Feb 10 '21 at 18:59
  • @SteffenUllrich I meant that I thought this information would make a good addition to your answer, since it's the next natural thing someone needs to know. – Segfault Feb 10 '21 at 20:21
  • @Segfault: I understand now. I don't see it in the current scope of the question though, which is about understanding how it works and not how it can be detected (or prevented or ... - there are more interesting follow-up's). And like I said - this aspect is already covered in other questions on this site. So I leave the answer like it is. But the comments here will be helpful for others who want to look further. – Steffen Ullrich Feb 10 '21 at 21:10
  • I think it would be helpful to clarify that MitM requires the root CA or something similar... Just going from an internal network through firewall, proxy, etc., otherwise would not be sufficient to read encrypted traffic. – user3067860 Feb 10 '21 at 21:15
  • @user3067860: I'm not sure about your comment: *"custom root certificate"* is the actual topic of the question and it is also mentioned in my answer. Am I wrong in expecting that somebody understands the question before reading the answer? – Steffen Ullrich Feb 10 '21 at 21:17
  • @SteffenUllrich The last paragraph of your answer seems a little disconnected from that, though--someone reading might misunderstand it as being "you're going through their network, so they can see everything you do regardless". I think it could be improved by making it clear that it specifically ties back to root CA. – user3067860 Feb 10 '21 at 21:20
  • @user3067860: I've now made it more clear in the first part that one actually has to use the CA certificate for SSL interception when being man in the middle. I hope this provides a better context for the following paragraph which are only about how to be in the path of the traffic in order to analyze it - and about the specific analysis done there. – Steffen Ullrich Feb 10 '21 at 21:26
  • I'm dissatisfied with your (OP's too) use of the word **active** in *the school/work also has to be an active man in the middle...*. What actions exactly are required once the MITM-box and the backdoor certs are set up? There're none. To humans, the ultimate inspection/interception process is **completely passive**. It's only "active" in a sense from PoV of robots/computers/software. – ulidtko Feb 11 '21 at 11:06
  • 2
    @ulidtko: Active man in the middle means that modifications on the traffic are done - which is needed when doing SSL interception. Passive would be instead only sniffing the traffic, not modifying it. This is sufficient with plain HTTP but not with HTTPS. Active man in the middle can be noticed since the traffic is modified, passive sniffing can not be noticed. – Steffen Ullrich Feb 11 '21 at 11:31
  • So you might indeed noticing modification that is expected by consensual MITM (and a whole country can do this). If it is their hardware and their endpoint for your ultimate destination they can see everything that does not have nested encryption. Nowadays your browser may even be hosted. Check for the difference between IP adresses with curl. – mckenzm Feb 11 '21 at 20:35
14

If you use https for example to buy stuff from Amazon, Amazon will send you a certificate to prove it’s them, and that works because nobody other than Amazon can get an “Amazon” certificate from one of the companies whose root certificates your device trust.

But if you let me install a root certificate on your device that I created, then I can create an “Amazon” certificate signed by this root certificate, and since your computer installed my root certificate, it would trust this certificate. With a little bit of hacking I can redirect all request intended for Amazon to my site, and because of the root certificate on your device your computer would trust it. Without the root certificate your computer would refuse to touch the fake Amazon site.

And of course that applies to any website. The root certificate makes your computer trust any site I redirect you to.

gnasher729
  • 2,107
  • 11
  • 16
  • Wouldn't this "only" apply to sites accessed via HTTPS? I realize most popular websites use HTTPS, but if the point of installing a root certificate was to inspect **all internet traffic**, would this approach work for HTTP requests as well? – Lars Kristensen Feb 10 '21 at 15:45
  • 8
    @LarsKristensen plain HTTP is not encrypted, which means that anyone with access to some connection point between your computer and the site you are visiting can see all the traffic anyway, even without you installing a custom root certificate. – JustAnotherCoder Feb 10 '21 at 16:01
  • 7
    Note that the man-in-the-middle (easy on http, requires root cert + some more hacking on https) can not only see, but also alter the traffic. So they can insert ads/malware (some ISPs used to do that on http), alter the data in order to steal stuff from you, etc. – Jonathan Feb 10 '21 at 16:04
  • @TomRevell I realize HTTP is not encrypted, and that anone transporting the packets can read and manipulate them. But would the root certificate **alone** be enough to be able to inspect all internet traffic, even when the PC is not on the school/work network? – Lars Kristensen Feb 11 '21 at 08:27
  • 3
    @LarsKristensen It is not. HTTPS normally protects you from MITM and a root cert from the attacker disables that protection, so now they can be a MITM if they want. Analogy: You give the attacker a key to your house, but they still have to actually drive to your house if they want to steal your TV. They don't automatically get the TV. – user253751 Feb 11 '21 at 18:36
  • Don't you need that more than CA installation? Why does the PC/phone need to use your certificate when reaching Amazon, etc? – kelalaka Feb 11 '21 at 18:42
  • 1
    @kelalaka: It's not the browser that chooses which certificate to use, but the server.\* Or whoever's pretending to be the server. As long as I can intercept your browser's request to connect to amazon.com and reply to it with a certificate that says "yes, I'm amazon.com, and this CA that you trust will vouch for that", then as far as your browser is concerned I'm amazon.com. Of course, the interception part is essential too. But anyone who operates your WiFi access point can do that (any many schools etc. do, using off-the-shelf "security" products). – Ilmari Karonen Feb 12 '21 at 07:11
  • 1
    *) Ignoring stuff like [certificate pinning](https://security.stackexchange.com/questions/29988/what-is-certificate-pinning), which can partly defeat impersonation attacks like this — assuming that it's enabled, which in modern browsers it generally no longer is. [Certificate transparency](https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency) is a partial replacement, but it has a [deliberate hole](https://security.stackexchange.com/q/218588) in its design (or at least implementation) that allows custom root certificates to still be used for SSL interception. – Ilmari Karonen Feb 12 '21 at 07:22
  • @IlmariKaronen yes, that is the point, that should be in the answer to clarify the OP. – kelalaka Feb 12 '21 at 08:50
9

Unless the same org is also install software that acts as a proxy for all internet traffic. It requires active intercepting, decrypting, and re-encryption of all traffic.

Why else do you think they want you to install their root cert? If it was for a legitimate purpose (securing their own properties), they could obtain certificates from a trusted third-party CA. If they want to become a root, with the ability to sign anything, it's because they want to operate outside of the rules of a legitimate CA — that is, they want to impersonate other sites on the internet in order to monitor your traffic. Software to do so is readily available to all kinds of businesses and organizations. In short, someone who asks you to install their root cert is MITMing you, at least some of the time, and probably at all times when you are connected to their network.

hobbs
  • 640
  • 4
  • 8
  • 7
    They could be motivated to do it because having certificates issued by third-parties CA costs *money*. Having your own CA is more cost-efficient at some point, and that does not imply it is for illegitimate uses. We have our own on our company network. Connecting to internal sites requires our root CA to be installed, reading signed emails too. – dim Feb 10 '21 at 17:25
  • 1
    @dim: Long time ago, one of our products shipped a root certificate that it put into the certificate store. It had nothing to do with money. We issued a cert for https:/ /ip-address/ which you can't buy for any price. The private root key was destroyed after signing the cert leaving nothing to compromise. Still wasn't brilliant. – Joshua Feb 10 '21 at 23:21
  • https://1.1.1.1/ You can purchase a publicly signed TLS cert for an IP just fine. – Brando__ Feb 11 '21 at 02:11
  • 2
    @Joshua. You can buy certificates for IP addresses as long as they are in the public range. You just can't do it for private networks (e.g. 192.168.x.x). In this case, you need you own CA. This is just standard procedure and that doesn't mean your PC is compromised. But obviously, if you install a root certificate, you have to trust the issuing entity. Now, if you want to make sure that this entity isn't spying on your Amazon connexion, that's easy: just check the website's cert full chain. If the root is an official DigiCert root: fine. If it's the entity's root: you're being spied on. – dim Feb 11 '21 at 08:59
  • 1
    @dim: We tried to buy a cert for the IP address and were unable to. – Joshua Feb 11 '21 at 16:15
  • 1
    @dim: *"having certificates issued by third-parties CA costs money"*, that used to be true, but free certificates have been available for some years, have a look at letsencrypt and certbot. – user000001 Feb 12 '21 at 07:31
  • @user000001 That is right for websites HTTPS certificates, but as far as I know this does not exist for other usages (e.g. mail certificates). Free certificates also have a very short expiration date which forces you to have an automated renewal process, and this can be a pain to setup when you have a complex infrastructure with e.g. load balancing, reverse proxies, etc... So it may not be suitable for all environments. – dim Feb 12 '21 at 08:09
  • @dim: In practice you need to be able to answer HTTP requests for the requesting domain, and then you can use it for any services that use that domain. Renewal is indeed more frequent (3 months), but certbot is usually good at doing it all automatically, so you don't really need to do anything after the initial installation. The main limitation is that it doesn't allow IP based certificates (only DNS). – user000001 Feb 12 '21 at 08:17
1

I was reading an article which said that if you install custom root cert from a third party then they can decipher all communication between you and others.

Its common practice for organisations to use internal certificate authorities to decrypt traffic as most internet communication is encrypted now. Although it's theoretically possible to decypher all traffic send and received by you, in practice storing this information would require a huge amount of storage. Usually, packets are inspected using the CA for SSL decryption then if the packet is allowed to pass through the firewall, the decrypted traffic is discarded.

The image below demonstrates the process well:

Forward Proxy Decryption

Without using the internal root CA the companies firewall, IDS/IPS, etc., can only scan a packet's headers to determine if it should be permitted or blocked.

With SSL decryption, the firewall decrypts the entire packet to scan its full contents, known as DPI (Deep Packet Inspection). DPI allows for better protection from malware and can also be used to detect applications that should be blocked using non-standard ports to bypass firewall rules, for example, FTP using port 80 vs 21.

So unless someone(company, work, hacker, etc) really tries to impersonate by doing mitm. Only then the compromised root cert will come in play as that would be used to pass fake cert as valid cert.

That's correct; the process of SSL decryption is a MITM attack.

otherwise just simply having a custom root cert isn't like decrypting all your ssl traffic. Unless the same org has also installed a software that acts as a proxy for all internet traffic. It requires active intercepting, decrypting, and re-encryption of all traffic. So either by installing malware on the computer or monitoring internet traffic.

That's also correct; the certificate alone is just a certificate that's trusted within your machine. The organisation will need to pass your traffic through them somehow to perform the MITM. This is usually through a VPN, proxy or by default if you're connected to the internal network.

If you wish to learn more about how SSL decryption works the following white-paper is good: https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/decryption-why-where-and-how

Jake M
  • 39
  • 3
0

The true answer depends on the fact who possesses the private key corresponding to the certificate, and how much do you trust them?:

  • "Normal" trusted CAs don't have the private key they are certifying (their own CA key excepted), so someone having or installing a normal certificate can do no harm. And CAs take great care to keep their private key secret.

  • "Normal" private keys are created in a trusted environment and they are protected, so only the owner ("subject") possesses the private key.

  • "Normally" policies make sure that the CAs certify only subjects they trust (i.e. the identity had been checked), and clients (server too) will check whether a certificate offered actually matches the subject.

So to be in danger, an adversary has to present a certificate that your client trusts. In turn this means the subject of the certificate has to match, and the certificate has to be signed (issued) by a trusted CA. Here is where your CA comes into play: The owner of a CA can certify anything. If you trust that CA, you trust any certificate issued by that CA.

Even without a bogus CA, a stolen private key of a "normal server certificate" can bring you into trouble (the "man in the middle" attack).

Amazingly my mobile phone complains "your network might be monitored" because of the CA certificate of "Deutsche Telekom Root CA 2"; I'd guess most certificates that are pre-installed are much less trustworthy, but you get the idea...

U. Windl
  • 137
  • 7