6 ms·

Why is it even possible for an application to install root certificates that other applications have to accept? An individual application accepting its own cert

by roxgib 4y ago

Why is it even possible for an application to install root certificates that other applications have to accept? An individual application accepting its own certificates is one thing (as Firefox does), but I can't think of a good reason why apps would need to modify the OS list of certs.

palant 4y ago
Note: I am the author of this article. There are semi-legitimate use cases. One is intranets where you might want to have HTTPS on non-public resources. More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic. And: yes, adding this certificate should normally be a user-initiated action. There is no way of preventing applications from automating it however. E.g. Firefox doesn’t have an API to install root CAs, so these applications package up NSS Tools in their installer, search for Firefox profiles during installation and add their root CA to any certificate database they can find.
- lb4r 4y ago
  On a somewhat (un)related note: What has been the reception, if any, from the Korean side in regards to your research? I've lived in Korea on and off for around ten years, and their online 'security' has always both bothered and worried me. It's nice to see someone actually opening up this horrendous and intrusive mess of software and investigating it.
  - palant 4y ago
    On the individual level, the reception is remarkably positive. I’ve had lots of people thank me for this research, including people working for government agencies. The news coverage is mixed. Some articles are positive about this and are asking about how to improve this sad state of affairs. Others are parroting statements from the affected companies: not actually bad, difficult to exploit, misunderstanding of the domestic market. And as to politics, it’s too early to tell I think. This definitely generated much attention. Whether all this attention will actually lead somewhere is impossible to tell at this point.
    - lb4r 4y ago
      That's great to hear. Hopefully your Korean colleagues will help bring awareness to this issue as well. I imagine it would probably be hard for politicians to ignore or argue against the consensus of the top minds of the country.
- flangola7 4y ago
  >More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic. How does this work with HSTS? There's a growing number of websites that will not load unless their legitimate certificate is present.
  - zinekeller 4y ago
    You're confusing HSTS with HPKP (key pinning). HSTS only mandates HTTPS but it never address what certificate is the server's. HPKP is the standard detailing certificate pinning (ensuring that the only certs are the correct one), but browsers ultimately decided against its implementation because of the difficulties associated with a hacked site effectivey ransomed by sending a HPKP with attacker-controlled certs. Edit: since that you might get confused on why HPKP can ransom a site, consider this case: 0. The owner of the website doesn't know about HPKP or decides against implementing HPKP due to its burden. 1. Either the web server, DNS service or BGP corresponding to the IP address of the server is hacked. The attacker can now control the site. 2. The attacker then issues a new certificate. Since that they control the keys, they can send an HPKP header that only locks the key that attackers controlled. 3. Unknowing users visit the site. The site can either be still active (web server hack) or proxied back to the legitimate site (DNS or BGP hijack). HPKP keys are remembered. 4. The owner now realises that their site is hacked and tries to restore it. Let's assume that they have revoked their old cert and issues a new and shiny one which is never in the HPKP header in the first place. 5. Users visit the supposedly now-restored site, but instead of succesfully connecting back it errors out with an HPKP error. The owner can't do anything but to migrate to a new domain name.
    - dtgriscom 4y ago
      We humans are a devious lot, aren't we?
    - flangola7 4y ago
      Thank you for the clarification. As a site operator, how should we assure that a visitor's connection cannot be MitM'd? Is this why some apps only use their own internal trusted certificate list, in lieu of offering a webpage? Can't they inform the HKPK list provider to revoke the old key after they regain control of the domain?
- fulafel 4y ago
  HTTPS on non-public resources isn't doesn't need to use DIY certs, normal certs work fine. If you are afraid of hostnames showing up in CT logs, you can use wildcard certs. Also TLS traffic inspection and antivirus can be done at endpoints.
  - palant 4y ago
    Sure, antivirus software does inspection at the endpoints. Guess what: they usually employ their MITM CA for that. :-) It’s not like I haven’t written about that before. Here is a particularly disastrous implementation: https://palant.info/2019/08/19/kaspersky-in-the-middle--what-could-possibly-go-wrong/ https://palant.info/2019/08/19/kaspersky-in-the-middle--what...
    - fulafel 4y ago
      Yep, I think there are ways to do it without a MITM CA but they are more fragile. There's also this post https://www.securityweek.com/antivirus-software-has-negative-impact-https-security-researcher/ https://www.securityweek.com/antivirus-software-has-negative... Both are bad but network level is worse.
1vuio0pswjnm7 4y ago
What about all the people who get their root certificates from Mozilla. The system root certificates should not be tied to any single application and yet how many people get their system root certificates from a single application developer. A browser developer. Go figure.
- woodruffw 4y ago
  > The system root certificates should not be tied to any single application and yet how many people get their system root certificates from a single application developer. What alternative do you propose? The most common alternative is OS vendors, who don't always respect the CA/B guidelines (which, overall, have been a positive force for CA ecosystem change). As far as points of failure/dependency go, Mozilla is not an unreasonable one.
  - 1vuio0pswjnm7 4y ago
    Why not obtain certificates from their sources instead of a third party. Maybe intermediaries ("middlemen") are trustworthy, and using third party is not single point of failure. Maybe people love the convenience. Maybe it is just laziness. Who knows. (I suspect the OS vendors may in some cases use the Mozilla bundle.) Personally I find that many of the certificates in the Mozilla bundle or in browsers are ones I never use. I certainly do not need them all. Sometimes when experimenting with TLS I download root certificates from the companies that provide them. It's certainly possible to get them from their source instead of Mozilla. At least with system certificates, the user can remove the ones she does not want. With certificates included in browsers, the user would have to edit the source code and re-compile. The so-called "modern" browsers are extremely cumbersome in that regard. Huge size and slow, resource-intensive compilation. And for some of the popular "modern" browsers modification and re-compilation is not even possible because the source code is unavailable.
    - woodruffw 4y ago
      > Why not obtain certificates from their sources instead of a third party. You can't do this sustainably. We're talking about hundreds of certificates that get cross-signed and rotated on varying bases. Nothing about this boils down to laziness: CA and bundle management is very difficult. Mozilla does a good job given the complexity, and arguably do a better job (including perceived conflicts of interest) than anybody else who could be tasked with the responsibility.
ilyt 4y ago
Application doesn't even need to use root CAs from system, it can ship its own; the problem starts when you try to make system browser part of your app
- tsimionescu 4y ago
  That quickly breaks in the presence of MITM traffic analyzers, such as most companies use for their internal networks.
  - ilyt 4y ago
    "Breaks" as in "app is secure when faced by hostile actors"
    - tsimionescu 4y ago
      I'm talking about secure networks, where all traffic has to be monitored to ensure nothing is accidentally leaked, that malware doesn't easily spread, or that proxies aren't used to circumvent filtering. MITM devices configured by the user are very much friendly actors, and an important component of defense in depth. To be clear, the way these normally work is that they have their own root CA that devices participating on the network add to their trust stores voluntarily.
tyingq 4y ago
It is frustrating that the ecosystem remains the way it is. I suppose mostly to support internal self-signed certificates where you don't want all your internal hostnames being exposed via certificate transparency. And, also, the crappy corporate monitoring MITM industry that desperately feels the need to spy on employees. It is a complex mess, where platforms (android, iphone, windows, linux, etc), languages (python, java, node, etc), browsers, web servers, and other pieces all handle client and server certificates in completely different ways.

by roxgib 4y ago

palant 4y ago

Note: I am the author of this article. There are semi-legitimate use cases. One is intranets where you might want to have HTTPS on non-public resources. More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic. And: yes, adding this certificate should normally be a user-initiated action. There is no way of preventing applications from automating it however. E.g. Firefox doesn’t have an API to install root CAs, so these applications package up NSS Tools in their installer, search for Firefox profiles during installation and add their root CA to any certificate database they can find.

lb4r 4y ago
On a somewhat (un)related note: What has been the reception, if any, from the Korean side in regards to your research? I've lived in Korea on and off for around ten years, and their online 'security' has always both bothered and worried me. It's nice to see someone actually opening up this horrendous and intrusive mess of software and investigating it.
- palant 4y ago
  On the individual level, the reception is remarkably positive. I’ve had lots of people thank me for this research, including people working for government agencies. The news coverage is mixed. Some articles are positive about this and are asking about how to improve this sad state of affairs. Others are parroting statements from the affected companies: not actually bad, difficult to exploit, misunderstanding of the domestic market. And as to politics, it’s too early to tell I think. This definitely generated much attention. Whether all this attention will actually lead somewhere is impossible to tell at this point.
  - lb4r 4y ago
    That's great to hear. Hopefully your Korean colleagues will help bring awareness to this issue as well. I imagine it would probably be hard for politicians to ignore or argue against the consensus of the top minds of the country.
flangola7 4y ago
>More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic. How does this work with HSTS? There's a growing number of websites that will not load unless their legitimate certificate is present.
- zinekeller 4y ago
  You're confusing HSTS with HPKP (key pinning). HSTS only mandates HTTPS but it never address what certificate is the server's. HPKP is the standard detailing certificate pinning (ensuring that the only certs are the correct one), but browsers ultimately decided against its implementation because of the difficulties associated with a hacked site effectivey ransomed by sending a HPKP with attacker-controlled certs. Edit: since that you might get confused on why HPKP can ransom a site, consider this case: 0. The owner of the website doesn't know about HPKP or decides against implementing HPKP due to its burden. 1. Either the web server, DNS service or BGP corresponding to the IP address of the server is hacked. The attacker can now control the site. 2. The attacker then issues a new certificate. Since that they control the keys, they can send an HPKP header that only locks the key that attackers controlled. 3. Unknowing users visit the site. The site can either be still active (web server hack) or proxied back to the legitimate site (DNS or BGP hijack). HPKP keys are remembered. 4. The owner now realises that their site is hacked and tries to restore it. Let's assume that they have revoked their old cert and issues a new and shiny one which is never in the HPKP header in the first place. 5. Users visit the supposedly now-restored site, but instead of succesfully connecting back it errors out with an HPKP error. The owner can't do anything but to migrate to a new domain name.
  - dtgriscom 4y ago
    We humans are a devious lot, aren't we?
  - flangola7 4y ago
    Thank you for the clarification. As a site operator, how should we assure that a visitor's connection cannot be MitM'd? Is this why some apps only use their own internal trusted certificate list, in lieu of offering a webpage? Can't they inform the HKPK list provider to revoke the old key after they regain control of the domain?
fulafel 4y ago
HTTPS on non-public resources isn't doesn't need to use DIY certs, normal certs work fine. If you are afraid of hostnames showing up in CT logs, you can use wildcard certs. Also TLS traffic inspection and antivirus can be done at endpoints.
- palant 4y ago
  Sure, antivirus software does inspection at the endpoints. Guess what: they usually employ their MITM CA for that. :-) It’s not like I haven’t written about that before. Here is a particularly disastrous implementation: https://palant.info/2019/08/19/kaspersky-in-the-middle--what-could-possibly-go-wrong/ https://palant.info/2019/08/19/kaspersky-in-the-middle--what...
  - fulafel 4y ago
    Yep, I think there are ways to do it without a MITM CA but they are more fragile. There's also this post https://www.securityweek.com/antivirus-software-has-negative-impact-https-security-researcher/ https://www.securityweek.com/antivirus-software-has-negative... Both are bad but network level is worse.

1vuio0pswjnm7 4y ago

What about all the people who get their root certificates from Mozilla. The system root certificates should not be tied to any single application and yet how many people get their system root certificates from a single application developer. A browser developer. Go figure.

woodruffw 4y ago
> The system root certificates should not be tied to any single application and yet how many people get their system root certificates from a single application developer. What alternative do you propose? The most common alternative is OS vendors, who don't always respect the CA/B guidelines (which, overall, have been a positive force for CA ecosystem change). As far as points of failure/dependency go, Mozilla is not an unreasonable one.
- 1vuio0pswjnm7 4y ago
  Why not obtain certificates from their sources instead of a third party. Maybe intermediaries ("middlemen") are trustworthy, and using third party is not single point of failure. Maybe people love the convenience. Maybe it is just laziness. Who knows. (I suspect the OS vendors may in some cases use the Mozilla bundle.) Personally I find that many of the certificates in the Mozilla bundle or in browsers are ones I never use. I certainly do not need them all. Sometimes when experimenting with TLS I download root certificates from the companies that provide them. It's certainly possible to get them from their source instead of Mozilla. At least with system certificates, the user can remove the ones she does not want. With certificates included in browsers, the user would have to edit the source code and re-compile. The so-called "modern" browsers are extremely cumbersome in that regard. Huge size and slow, resource-intensive compilation. And for some of the popular "modern" browsers modification and re-compilation is not even possible because the source code is unavailable.
  - woodruffw 4y ago
    > Why not obtain certificates from their sources instead of a third party. You can't do this sustainably. We're talking about hundreds of certificates that get cross-signed and rotated on varying bases. Nothing about this boils down to laziness: CA and bundle management is very difficult. Mozilla does a good job given the complexity, and arguably do a better job (including perceived conflicts of interest) than anybody else who could be tasked with the responsibility.

ilyt 4y ago

Application doesn't even need to use root CAs from system, it can ship its own; the problem starts when you try to make system browser part of your app

tsimionescu 4y ago
That quickly breaks in the presence of MITM traffic analyzers, such as most companies use for their internal networks.
- ilyt 4y ago
  "Breaks" as in "app is secure when faced by hostile actors"
  - tsimionescu 4y ago
    I'm talking about secure networks, where all traffic has to be monitored to ensure nothing is accidentally leaked, that malware doesn't easily spread, or that proxies aren't used to circumvent filtering. MITM devices configured by the user are very much friendly actors, and an important component of defense in depth. To be clear, the way these normally work is that they have their own root CA that devices participating on the network add to their trust stores voluntarily.

tyingq 4y ago

It is frustrating that the ecosystem remains the way it is. I suppose mostly to support internal self-signed certificates where you don't want all your internal hostnames being exposed via certificate transparency. And, also, the crappy corporate monitoring MITM industry that desperately feels the need to spy on employees. It is a complex mess, where platforms (android, iphone, windows, linux, etc), languages (python, java, node, etc), browsers, web servers, and other pieces all handle client and server certificates in completely different ways.